From owner-freebsd-current Sun Sep 24 0:25:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from maulwurf.franken.de (maulwurf.franken.de [193.141.110.9]) by hub.freebsd.org (Postfix) with ESMTP id 3392A37B422 for ; Sun, 24 Sep 2000 00:25:46 -0700 (PDT) Received: by maulwurf.franken.de via rmail with stdio id for freebsd-current@FreeBSD.ORG; Sun, 24 Sep 2000 09:25:44 +0200 (MET DST) (Smail-3.2 1996-Jul-4 #1 built DST-May-30) Received: (from tanis@localhost) by gaspode.franken.de (8.11.0/8.9.3) id e8O7PFr01271; Sun, 24 Sep 2000 09:25:15 +0200 (CEST) (envelope-from tanis) Date: Sun, 24 Sep 2000 09:25:15 +0200 From: German Tischler To: "Kenneth D. Merry" Cc: freebsd-current@FreeBSD.ORG Subject: Re: ahc and SMP Message-ID: <20000924092515.A887@gaspode.franken.de> References: <20000924000438.A460@gaspode.franken.de> <20000923213612.A44671@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000923213612.A44671@panzer.kdm.org>; from ken@kdm.org on Sun, Sep 24, 2000 at 05:36:43AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Sep 24, 2000 at 05:36:43AM +0200, Kenneth D. Merry wrote: > On Sun, Sep 24, 2000 at 00:04:38 +0200, German Tischler wrote: > So if you don't have enough pass(4) devices in /dev, you may not see some > of the devices that are there. > > So make sure you have /dev/pass{0-4}. > > Another way to make sure you have a pass device for cd1 is to do: > > camcontrol tur cd1 -v Thank you, that lets cdrecord find all devices. What got me confused is that MAKEDEV pass4 does not create pass4 but 0-3, but that is clear from reading MAKEDEV. --gt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 1:37:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E988937B422; Sun, 24 Sep 2000 01:37:41 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id BAA95427; Sun, 24 Sep 2000 01:37:41 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 24 Sep 2000 01:37:41 -0700 (PDT) From: Kris Kennaway To: Adrian Chadd Cc: Boris Popov , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Fsck wrappers, revisited In-Reply-To: <20001223114150.A38052@roaming.cacheboy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 23 Dec 2000, Adrian Chadd wrote: > On Fri, Sep 22, 2000, Boris Popov wrote: > > On Sat, 23 Dec 2000, Adrian Chadd wrote: > > > > > So now is a problem which I'm sure the NetBSD people came up against. > > > The fstypenames are names like 4.2BSD, vinum, ISO9660, etc. NetBSD fixed > > > this by creating a new list 'mountnames[]', which maps the fs type to > > > a string. > > > > Probably a hard link to fsck_ffs will do the job fine and makes it > > clear to see which fs'es are supported: > > > > # ls -ail fsck* > > 6338 -r-xr-xr-x 1 root wheel 66032 22 sen 16:24 fsck > > 6334 -r-xr-xr-x 3 root wheel 290896 22 sen 15:41 fsck_4.2BSD > > 6334 -r-xr-xr-x 3 root wheel 290896 22 sen 15:41 fsck_ffs > > 6334 -r-xr-xr-x 3 root wheel 290896 22 sen 15:41 fsck_ufs > > The trouble is that some of the FS strings have spaces in their filenames. > This might confuse a few people. How about mapping spaces to '_' characters - I doubt it would cause any namespace collisions. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 2: 8:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id 7228137B424; Sun, 24 Sep 2000 02:08:38 -0700 (PDT) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id e8O8ukS07598; Sun, 24 Sep 2000 10:56:46 +0200 (CEST) (envelope-from adrian) Date: Sun, 24 Sep 2000 10:56:45 +0200 From: Adrian Chadd To: Kris Kennaway Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Fsck wrappers, revisited Message-ID: <20000924105645.A7573@roaming.cacheboy.net> References: <20001223114150.A38052@roaming.cacheboy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from kris@FreeBSD.org on Sun, Sep 24, 2000 at 01:37:41AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Sep 24, 2000, Kris Kennaway wrote: > > The trouble is that some of the FS strings have spaces in their filenames. > > This might confuse a few people. > > How about mapping spaces to '_' characters - I doubt it would cause any > namespace collisions. Yes, as bp mentioned to me before, so I'm thinking about passing the fsname through a tolower() and a s/ /_/g before using it as a filename. Any problems with this? Adrian -- Adrian Chadd "The main reason Santa is so jolly is because he knows where all the bad girls live." -- Random IRC quote To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 6:15:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 9A78B37B422 for ; Sun, 24 Sep 2000 06:15:37 -0700 (PDT) Received: (qmail 26754 invoked by uid 0); 24 Sep 2000 13:15:36 -0000 Received: from p3ee21603.dip.t-dialin.net (HELO speedy.gsinet) (62.226.22.3) by mail.gmx.net with SMTP; 24 Sep 2000 13:15:36 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id KAA15600 for current@freebsd.org; Sun, 24 Sep 2000 10:29:07 +0200 Date: Sun, 24 Sep 2000 10:29:07 +0200 From: Gerhard Sittig To: current@freebsd.org Subject: Re: mtree again Message-ID: <20000924102907.J5065@speedy.gsinet> Mail-Followup-To: current@freebsd.org References: <20000915033837.A564@nagual.pp.ru> <200009142341.RAA00700@harmony.village.org> <20000915043925.A83698@nagual.pp.ru> <39CD3698.D2EF0663@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <39CD3698.D2EF0663@cup.hp.com>; from marcel@cup.hp.com on Sat, Sep 23, 2000 at 04:02:48PM -0700 Organization: System Defenestrators Inc. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Sep 23, 2000 at 16:02 -0700, Marcel Moolenaar wrote: > "Andrey A. Chernov" wrote: > > > > [ ... mtree getopts switch code ... ] > > > > Is their any harm in just keeping the -P flag as a no-op and > optionally remove it at some later time (for backward > compatibility)? That's where I jumped in in an earlier stage of this thread. :) It should not be removed without substitute. It could be renamed to -H and should reverse the effect of -L. See symlink(7) on why command lines like "cmd -H -L -H ..." can sum up and why switching to both directions is desirable. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 7:43:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 31CC137B422 for ; Sun, 24 Sep 2000 07:43:26 -0700 (PDT) Received: (from uucp@localhost) by rina.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W-rina.r-0.1-11.01.2000) with UUCP id XAA17981; Sun, 24 Sep 2000 23:43:15 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W) with ESMTP/IPv4 id XAA34571; Sun, 24 Sep 2000 23:43:02 +0900 (JST) Date: Sun, 24 Sep 2000 23:43:01 +0900 Message-ID: <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> From: Seigo Tanimura To: n@nectar.com Cc: current@freebsd.org Subject: pw_class in _pw_passwd is null if __hashpw() is not called in prior In-Reply-To: In your message of "Wed, 6 Sep 2000 15:14:31 -0500" <20000906151431.A26152@hamlet.nectar.com> References: <20000906151431.A26152@hamlet.nectar.com> Cc: Seigo Tanimura User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) Organization: Carrots MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG pw_class in _pw_passwd of src/lib/libc/gen/getpwdent.c is initialized to null. Thus if a user other than root looks up nis by getpwuid(3) or getpwnam(3) in prior to calling __hashpw, pw_class is null as well. This breaks some applications including ssh(1) because they believe that no members of struct passwd are null. The following sample code shows the problem. --- v --- sample --- v --- #include #include #include #include int main(void) { struct passwd *pw; if ((pw = getpwuid(getuid())) != NULL) printf("name:\t\%s\nclass:\t\%p\n", pw->pw_name, pw->pw_class); } --- ^ --- sample --- ^ --- If you have your passwd entry in nis, you see something like this: silver% ./getpwent name: tanimura class: 0x0 If your passwd entry is in /etc/master.passwd, the result looks like this: silver# ./getpwent name: root class: 0x804cc28 where 0x804cc28 points to an empty string, which is the expected result. As we are supposed to fill in all of the members in struct passwd (like Solaris), _pw_passwd should have its initial value other than zero. static struct passwd _pw_passwd = { "", "", (uid_t)0, /* XXX Is zero appropriate? */ (gid_t)0, (time_t)0, "", "", "", "", (time_t)0, 0, }; In addition, we should also reinitialize _pw_passwd by this initial value before rewriting _pw_passwd, because pw_class filled in by previous call to __hashpw might grant unauthorized use of resource or account. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 8: 8:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 3009A37B424 for ; Sun, 24 Sep 2000 08:08:13 -0700 (PDT) Received: by gw.nectar.com (Postfix, from userid 1001) id 8048F1925D; Sun, 24 Sep 2000 10:08:12 -0500 (CDT) Date: Sun, 24 Sep 2000 10:08:12 -0500 From: "Jacques A. Vidrine" To: Seigo Tanimura Cc: current@freebsd.org Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior Message-ID: <20000924100812.A23848@spawn.nectar.com> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Sun, Sep 24, 2000 at 11:43:01PM +0900 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Sep 24, 2000 at 11:43:01PM +0900, Seigo Tanimura wrote: > As we are supposed to fill in all of the members in struct passwd > (like Solaris), _pw_passwd should have its initial value other than > zero. > > static struct passwd _pw_passwd = > { > "", > "", > (uid_t)0, /* XXX Is zero appropriate? */ > (gid_t)0, > (time_t)0, > "", > "", > "", > "", > (time_t)0, > 0, > }; I agree -- it bit me while working on some additional nsswitch backends. Using a pointer to an empty string would be more safe. As to the XXX comment, those fields have been 0 forever, no point in changing them now. Unless objections come up, I'll commit this change or something similar with the next nsswitch commit. Thanks for the suggestion! -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 10:24: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from volatile.chemicals.tacorp.com (ci391991-a.grnvle1.sc.home.com [24.9.31.75]) by hub.freebsd.org (Postfix) with ESMTP id 36F5F37B43C for ; Sun, 24 Sep 2000 10:23:59 -0700 (PDT) Received: (from morganw@localhost) by volatile.chemicals.tacorp.com (8.11.0/8.11.0) id e8OHNwH13437; Sun, 24 Sep 2000 13:23:58 -0400 (EDT)?g (envelope-from morganw)œ Date: Sun, 24 Sep 2000 13:23:58 -0400 (EDT) From: Wesley Morgan To: current@freebsd.org Subject: sound breakage Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Something committed in the last 16 hours or so (seems to have) hosed mp3 playback on my laptop (OPL-SA3)... It stutters on the first 1/2 second of the mp3 over and over. The cvs-all archives for last week look like they are in limbo right now or else I would look for a specific commit. Is anyone else seeing this breakage? -- _ __ ___ ____ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ wesleymorgan@home.com _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 11:24:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from piranha.amis.net (piranha.amis.net [212.18.32.3]) by hub.freebsd.org (Postfix) with ESMTP id B35F537B42C for ; Sun, 24 Sep 2000 11:24:45 -0700 (PDT) Received: from titanic.medinet.si (titanic.medinet.si [212.18.32.66]) by piranha.amis.net (Postfix) with ESMTP id 8A7035D29 for ; Sun, 24 Sep 2000 20:24:44 +0200 (CEST) Date: Sun, 24 Sep 2000 20:24:44 +0200 (CEST) From: Blaz Zupan X-Sender: blaz@titanic.medinet.si To: freebsd-current@freebsd.org Subject: .indent.pro for KNF? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anybody have a .indent.pro file for indent(1) that enforces KNF style as specified in style(9)? I have newbusified Initio's driver for their INIC-941, INIC-951 and INI-9XXXU/UW SCSI adapters (just testing it with a make world) and now I'm trying to bring it into form for inclusion in the FreeBSD sources. The original style of the sources as supplied by Initio is simply horrible. Fixing it all up by hand will take days if not weeks so I'm trying to find an easier way. By the way, if anybody is interested in testing the driver, send me an e-mail. I'm testing under -current with a INI-9100UW. I'll send a separate call for review to freebsd-scsi when the sources are cleaned up. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: blaz@amis.net, Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 11:27:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7E66137B42C; Sun, 24 Sep 2000 11:27:07 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id UAA49313; Sun, 24 Sep 2000 20:26:59 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Warner Losh Cc: The Hermit Hacker , Bruce Evans , freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: 'interrupt-level buffer overflows' for sio device? References: <200009080314.VAA50701@harmony.village.org> From: Dag-Erling Smorgrav Date: 24 Sep 2000 20:26:58 +0200 In-Reply-To: Warner Losh's message of "Thu, 07 Sep 2000 21:14:58 -0600" Message-ID: Lines: 26 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > In message The Hermit Hacker writes: > : Okay, I'm a little confused here ... from what I'm reading/following, this > : isn't a new problem ... or is it? If not, why has it suddenly manifested > : itself with the new SMP code? > It seems to be new with the SMP code. At least that's what my reading > of the original message is. I'm seeing the same thing as Marc, but I have a little more info: 1) it started after the SMPng commit. 2) it's not just sio, it's everything: - interactive response is markedly slower. - the keyboard autorepeats slower than it used to (even with kbdcontrol -r fast). - I/O bound processes such as mpg123 or cvsup will pause briefly when there is other I/O going on (moving the mouse, typing fast, holding down a key on the keyboard), which they didn't use to. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 11:30:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8A73E37B422; Sun, 24 Sep 2000 11:30:20 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8OIU8e29105; Sun, 24 Sep 2000 11:30:08 -0700 (PDT) Date: Sun, 24 Sep 2000 11:30:08 -0700 From: Alfred Perlstein To: Dag-Erling Smorgrav Cc: Warner Losh , The Hermit Hacker , Bruce Evans , freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: 'interrupt-level buffer overflows' for sio device? Message-ID: <20000924113008.N9141@fw.wintelcom.net> References: <200009080314.VAA50701@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from des@ofug.org on Sun, Sep 24, 2000 at 08:26:58PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dag-Erling Smorgrav [000924 11:27] wrote: > Warner Losh writes: > > In message The Hermit Hacker writes: > > : Okay, I'm a little confused here ... from what I'm reading/following, this > > : isn't a new problem ... or is it? If not, why has it suddenly manifested > > : itself with the new SMP code? > > It seems to be new with the SMP code. At least that's what my reading > > of the original message is. > > I'm seeing the same thing as Marc, but I have a little more info: > > 1) it started after the SMPng commit. > > 2) it's not just sio, it's everything: > > - interactive response is markedly slower. > > - the keyboard autorepeats slower than it used to (even with > kbdcontrol -r fast). > > - I/O bound processes such as mpg123 or cvsup will pause briefly > when there is other I/O going on (moving the mouse, typing fast, > holding down a key on the keyboard), which they didn't use to. This is basically a result of the entire kernel running at the equivelant of splhigh, all interrupts are blocked until a context switch in kernel land. There's work in progress to mpsafe the drivers (at least for ethernet, more will arrive later). -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 11:39:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id EEC1937B422; Sun, 24 Sep 2000 11:39:18 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id UAA49387; Sun, 24 Sep 2000 20:39:14 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Alfred Perlstein Cc: Warner Losh , The Hermit Hacker , Bruce Evans , freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: 'interrupt-level buffer overflows' for sio device? References: <200009080314.VAA50701@harmony.village.org> <20000924113008.N9141@fw.wintelcom.net> From: Dag-Erling Smorgrav Date: 24 Sep 2000 20:39:14 +0200 In-Reply-To: Alfred Perlstein's message of "Sun, 24 Sep 2000 11:30:08 -0700" Message-ID: Lines: 14 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: > This is basically a result of the entire kernel running at the > equivelant of splhigh, all interrupts are blocked until a context > switch in kernel land. > > There's work in progress to mpsafe the drivers (at least for > ethernet, more will arrive later). OK. Assuming I wanted to try and help with this work, where would be a good place to start finding out what needs to be done? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 12:28: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from hun.org (hun.org [216.190.28.252]) by hub.freebsd.org (Postfix) with ESMTP id 8717E37B424 for ; Sun, 24 Sep 2000 12:28:03 -0700 (PDT) Received: (from attila@localhost) by hun.org (8.11.0/8.11.0) id e8OJRul21281; Sun, 24 Sep 2000 19:27:56 GMT (envelope-from attila) Date: Sun, 24 Sep 2000 19:27:56 GMT Message-Id: <200009241927.e8OJRul21281@hun.org> From: attila! Content-Type: text/plain; charset=ISO-8859-1 ; format=flowed Content-Transfer-Encoding: 8bit; Content-Disposition: Inline X-Organization: hun.org, over 40 years beyond the fringe home for unpenitent hackers and anarcho-cryptophreaks X-Die-Spammers: Spammers cheerfully broiled and served with Stubbs's Wicked Chicken Wing Sauce --Inferno X-Mailer: FreeBSD 5.0-20000924 with XEmacs V21.1.10 (see alt.religion.emacs) Ballistic: N 37.218497 W 113.614979 To: freebsd-current@freebsd.org Subject: 'device random' required in conf file? Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG buildkernel based on cvs pulled 2000 09 24 1420 UCT: linking kernel if_spppsubr.o: in function `sppp_chap_scr': if_spppsubr.o(.text+0x3f54): undefined reference to `read_random' *** error code 1 stop in /usr/src/obj/usr/src/sys/hun. adding (pseudo)device random to conf file made link. I had planned to load random with loader.conf.local ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 17:11:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 2568A37B424 for ; Sun, 24 Sep 2000 17:11:08 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id RAA18206; Sun, 24 Sep 2000 17:10:48 -0700 (PDT) (envelope-from obrien) Date: Sun, 24 Sep 2000 17:10:48 -0700 From: "David O'Brien" To: Blaz Zupan Cc: freebsd-current@freebsd.org Subject: Re: .indent.pro for KNF? Message-ID: <20000924171048.A18141@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from blaz@amis.net on Sun, Sep 24, 2000 at 08:24:44PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Sep 24, 2000 at 08:24:44PM +0200, Blaz Zupan wrote: > Does anybody have a .indent.pro file for indent(1) that enforces KNF style as > specified in style(9)? From Bruce Evans, this is " a wrapper around indent(1) to print the percentage changes that indent with the best (least bad) approximation to KNF parameters that I know of would do." --- #!/bin/sh TMP=`mktemp /tmp/_knfom.XXXXXX` TMPBAK=`mktemp /tmp/_knfom.XXXXXX` trap 'rm -f $TMP $TMPBAK; exit 1' 1 2 3 13 15 trap 'rm -f $TMP $TMPBAK' 0 for i do cp "$i" $TMP # XXX the typedef list hasn't been updated since 1993, except for the last # two entries. indent -npro \ -TBitSetTmp \ -TDBM \ -TDIR \ -TFix16_peh \ -TFix24_peh \ -TFix32_peh \ -TFix48_peh \ -TFix_peh \ -TGPT \ -TIntTmp \ -TLLattrib \ -TLLtoken \ -TPix \ -TProtoHook \ -TRatTmp \ -TSGTTY \ -TSeqNum \ -TStrTmp \ -TXCHAR \ -T_Fix \ -T__sFILE \ -T__sighandler_4_3_t \ -T__sighandler_t \ -T_code \ -T_dirdesc \ -T_ftsent \ -T_physadr \ -T_quad \ -T_uquad \ -T_vsIoAddr \ -T_vsStats \ -T_vs_box \ -T_vs_cursor \ -T_vs_event \ -Tbitstr_t \ -Tboolean_t \ -Tcaddr_t \ -Tcbool \ -Tcc_t \ -Tclock_t \ -Tclockframe \ -Tcomp_t \ -Tcomplex \ -Tdaddr_t \ -Tdb \ -Tdb_addr_t \ -Tdb_expr_t \ -Tdb_regs_t \ -Tdes_block \ -Tdev_pager_t \ -Tdev_t \ -Tfd_mask \ -Tfd_set \ -Tfhandle_t \ -Tfixpt_t \ -Tfpos_t \ -Tfsid_t \ -Tgid_t \ -Tino_t \ -Tint16 \ -Tint32 \ -Tjmp_buf \ -Tkey_t \ -Tlabel_t \ -Tllinsert \ -Tlock_data_t \ -Tlock_t \ -Tmode_t \ -Tn_long \ -Tn_short \ -Tn_time \ -Tnetobj \ -Tnew_handler_t \ -Tnfstype \ -Tnfsv2fh_t \ -Tnlink_t \ -Toff_t \ -Tone_arg_error_handler_t \ -Tpd_entry_t \ -Tpid_t \ -Tpmap_statistics_t \ -Tpmap_t \ -Tpt_entry_t \ -Tptrdiff_t \ -Tpv_entry \ -Tqaddr_t \ -Tqhdr \ -Tqueue_chain_t \ -Tqueue_entry_t \ -Tqueue_head_t \ -Tqueue_t \ -Tregexp \ -Tsegsz_t \ -TRefNum \ -Tsig_t \ -Tsigjmp_buf \ -Tsigset_t \ -Tsimple_lock_data_t \ -Tsimple_lock_t \ -Tsize_t \ -Tspeed_t \ -Tssize_t \ -Tsw_blk_t \ -Tsw_bm_t \ -Tsw_pager_t \ -Tswblk_t \ -Ttcflag_t \ -Ttcp_seq \ -Ttime_t \ -Ttimeout_func_t \ -Ttpr_t \ -Ttwo_arg_error_handler_t \ -Tu_char \ -Tu_int \ -Tu_int32 \ -Tu_long \ -Tu_short \ -Tuid_t \ -Tuint16 \ -Tuint32 \ -Tushort \ -Tva_list \ -Tvm_inherit_t \ -Tvm_map_entry_t \ -Tvm_map_object_t \ -Tvm_map_t \ -Tvm_object_hash_entry_t \ -Tvm_object_t \ -Tvm_offset_t \ -Tvm_page_t \ -Tvm_pager_t \ -Tvm_prot_t \ -Tvm_size_t \ -Tvm_statistics_data_t \ -Tvm_statistics_t \ -Tvn_pager_t \ -TvsIoAddrAddr \ -Twchar_t \ -Txdrproc_t \ -Tsy_call_t \ -Tvop_t \ -bad -bap -nbbb -nbc -br -nbs -c33 -cd33 -cdb -ce -ci4 -cli0 -d0 -di0 -ndj \ -ei -nfc1 -nfcb -i8 -ip -l79 -lc77 -nlp -npcs -psl -sc -nsob -nv \ $TMP $TMPBAK (wc -l "$i" | tr '\012' ' '; diff $TMPBAK $TMP | grep -cv '^[1-9]') | awk '{printf("%7.3f%% %s\n", 100 - 100 * $3 / 2 / ($1 + .1), $2)}' done --- -di0 is wrong for global declarations but right for local declarations. indent -di8 would get the tabs for global declarations wrong anyway. -nfcb is an extension to prevent formatting of big comments - otherwise there is too much comment reformatting compared with code reformatting (there still is). These diffs implement -[n]fcb and attempt to implement no-space=after-sizeof (not optional) and no-space-after 'struct foo *' (not optional). Without these, indent unKNFizes even more perfectly KNF code. The most serious bugs in indent are that it doesn't understand ANSI function headers, and -lp doesn't actually work. I think these are both fixed in gnu indent. diff -c2 args.c~ args.c *** args.c~ Sun Aug 29 11:15:27 1999 --- args.c Sun Aug 29 11:15:32 1999 *************** *** 111,114 **** --- 111,115 ---- "fb", PRO_FONT, 0, 0, (int *) &bodyf, "fc1", PRO_BOOL, true, ON, &format_col1_comments, + "fcb", PRO_BOOL, true, ON, &format_block_comments, "fc", PRO_FONT, 0, 0, (int *) &scomf, "fk", PRO_FONT, 0, 0, (int *) &keywordf, *************** *** 132,135 **** --- 133,137 ---- "nei", PRO_BOOL, true, OFF, &ps.else_if, "nfc1", PRO_BOOL, true, OFF, &format_col1_comments, + "nfcb", PRO_BOOL, true, OFF, &format_block_comments, "nip", PRO_BOOL, true, OFF, &ps.indent_parameters, "nlp", PRO_BOOL, true, OFF, &lineup_to_parens, diff -c2 indent.1~ indent.1 *** indent.1~ Sun Aug 29 11:45:30 1999 --- indent.1 Sun Aug 29 11:46:03 1999 *************** *** 64,67 **** --- 64,68 ---- .Bk -words .Op Fl fc1 | Fl nfc1 + .Op Fl fcb | Fl nfcb .Ek .Op Fl i Ns Ar n *************** *** 249,252 **** --- 250,262 ---- used. The default is .Fl fc1 . + .It Fl fcb , nfcb + Enables (disables) the formatting of block comments (ones that begin + with `/*\\n'). Often, block comments have been not so carefully hand + formatted by the programmer, but reformatting that would just change + the line breaks is not wanted. In such cases, + .Fl nfcb + should be used. Block comments are then handled like box comments. + The default is + .Fl fcb . .It Fl i Ns Ar n The number of spaces for one indentation level. The default is 8. diff -c2 indent.c~ indent.c *** indent.c~ Sun Aug 29 11:15:27 1999 --- indent.c Sun Aug 29 11:15:32 1999 *************** *** 166,169 **** --- 166,170 ---- ps.unindent_displace = 0; /* -d0 */ ps.case_indent = 0; /* -cli0 */ + format_block_comments = 1; /* -fcb */ format_col1_comments = 1; /* -fc1 */ procnames_start_line = 1; /* -psl */ *************** *** 534,538 **** ps.last_u_d = true; ps.cast_mask &= (1 << ps.p_l_follow) - 1; ! } ps.sizeof_mask &= (1 << ps.p_l_follow) - 1; if (--ps.p_l_follow < 0) { --- 535,541 ---- ps.last_u_d = true; ps.cast_mask &= (1 << ps.p_l_follow) - 1; ! ps.want_blank = false; ! } else ! ps.want_blank = true; ps.sizeof_mask &= (1 << ps.p_l_follow) - 1; if (--ps.p_l_follow < 0) { *************** *** 544,548 **** *e_code++ = token[0]; - ps.want_blank = true; if (sp_sw && (ps.p_l_follow == 0)) { /* check for end of if --- 547,550 ---- diff -c2 indent_globs.h~ indent_globs.h *** indent_globs.h~ Wed Sep 8 17:15:09 1999 --- indent_globs.h Wed Sep 8 17:15:11 1999 *************** *** 156,159 **** --- 156,161 ---- int proc_calls_space; /* If true, procedure calls look like: * foo(bar) rather than foo (bar) */ + int format_block_comments; /* true if comments beginning with + * `/*\n' are to be reformatted */ int format_col1_comments; /* If comments which start in column 1 * are to be magically reformatted diff -c2 lexi.c~ lexi.c *** lexi.c~ Sun Aug 29 11:15:27 1999 --- lexi.c Sun Aug 29 11:15:32 1999 *************** *** 59,63 **** }; ! struct templ specials[100] = { "switch", 1, --- 59,63 ---- }; ! struct templ specials[1000] = { "switch", 1, *************** *** 89,92 **** --- 89,94 ---- "do", 6, "sizeof", 7, + "const", 9, + "volatile", 9, 0, 0 }; *************** *** 258,273 **** case 3: /* a "struct" */ ! if (ps.p_l_follow) ! break; /* inside parens: cast */ l_struct = true; /* ! * Next time around, we will want to know that we have had a ! * 'struct' */ case 4: /* one of the declaration keywords */ if (ps.p_l_follow) { ps.cast_mask |= 1 << ps.p_l_follow; ! break; /* inside parens: cast */ } last_code = decl; --- 260,284 ---- case 3: /* a "struct" */ ! /* ! * Next time around, we may want to know that we have had a ! * 'struct' ! */ l_struct = true; /* ! * Fall through to test for a cast, function prototype or ! * sizeof(). */ case 4: /* one of the declaration keywords */ if (ps.p_l_follow) { ps.cast_mask |= 1 << ps.p_l_follow; ! ! /* ! * Forget that we saw `struct' if we're in a sizeof(). ! */ ! if (ps.sizeof_mask) ! l_struct = false; ! ! break; /* inside parens: cast, prototype or sizeof() */ } last_code = decl; diff -c2 pr_comment.c~ pr_comment.c *** pr_comment.c~ Sun Aug 29 11:15:27 1999 --- pr_comment.c Sun Aug 29 11:15:32 1999 *************** *** 112,119 **** } else { ! if (*buf_ptr == '-' || *buf_ptr == '*') { ! ps.box_com = true; /* a comment with a '-' or '*' immediately * after the /* is assumed to be a boxed ! * comment */ break_delim = 0; } --- 112,124 ---- } else { ! if (*buf_ptr == '-' || *buf_ptr == '*' || ! (*buf_ptr == '\n' && !format_block_comments)) { ! ps.box_com = true; /* A comment with a '-' or '*' immediately * after the /* is assumed to be a boxed ! * comment. A comment with a newline ! * immediately after the /* is assumed to ! * be a block comment and is treated as a ! * box comment unless format_block_comments ! * is nonzero (the default). */ break_delim = 0; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 17:25:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 3DC7137B424; Sun, 24 Sep 2000 17:25:13 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8P0IMC18760; Mon, 25 Sep 2000 01:18:22 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8P0DGx52883; Mon, 25 Sep 2000 01:13:17 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200009250013.e8P0DGx52883@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: kris@FreeBSD.ORG Cc: "Jacques A. Vidrine" , Seigo Tanimura , current@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior In-Reply-To: Message from "Jacques A. Vidrine" of "Sun, 24 Sep 2000 10:08:12 CDT." <20000924100812.A23848@spawn.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Sep 2000 01:13:14 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris, I guess once this is committed, the patch I sent you for ssh will no longer be necessary. To the cc list: My patch just told ssh to xstrdup(pw_class ? pw_class : "") > On Sun, Sep 24, 2000 at 11:43:01PM +0900, Seigo Tanimura wrote: > > As we are supposed to fill in all of the members in struct passwd > > (like Solaris), _pw_passwd should have its initial value other than > > zero. > > > > static struct passwd _pw_passwd = > > { > > "", > > "", > > (uid_t)0, /* XXX Is zero appropriate? */ > > (gid_t)0, > > (time_t)0, > > "", > > "", > > "", > > "", > > (time_t)0, > > 0, > > }; > > I agree -- it bit me while working on some additional nsswitch > backends. Using a pointer to an empty string would be more safe. As > to the XXX comment, those fields have been 0 forever, no point in > changing them now. Unless objections come up, I'll commit this change > or something similar with the next nsswitch commit. > > Thanks for the suggestion! > -- > Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 17:34: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 3D48A37B422 for ; Sun, 24 Sep 2000 17:34:01 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA42928; Sun, 24 Sep 2000 20:33:42 -0400 (EDT) (envelope-from wollman) Date: Sun, 24 Sep 2000 20:33:42 -0400 (EDT) From: Garrett Wollman Message-Id: <200009250033.UAA42928@khavrinen.lcs.mit.edu> To: "Andrey A. Chernov" Cc: current@FreeBSD.ORG Subject: Re: mtree again In-Reply-To: <20000924083440.A49999@nagual.pp.ru> References: <20000915033837.A564@nagual.pp.ru> <200009142341.RAA00700@harmony.village.org> <20000915043925.A83698@nagual.pp.ru> <39CD3698.D2EF0663@cup.hp.com> <200009240144.VAA34295@khavrinen.lcs.mit.edu> <20000924083440.A49999@nagual.pp.ru> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > What POSIX.1-200x says about this thing? I don't have this book in hand. The rationale includes a table of options used to controlling symlink following in various programs, and suggests that `-H', `-L', and `-P' be used in new programs which implement filesystem traversal. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 18: 7:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A778837B422 for ; Sun, 24 Sep 2000 18:07:36 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id TAA00796; Sun, 24 Sep 2000 19:07:34 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA01401; Sun, 24 Sep 2000 19:07:33 -0600 (MDT) Message-Id: <200009250107.TAA01401@harmony.village.org> To: Blaz Zupan Subject: Re: .indent.pro for KNF? Cc: freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Sun, 24 Sep 2000 20:24:44 +0200." References: Date: Sun, 24 Sep 2000 19:07:33 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Blaz Zupan writes: : original style of the sources as supplied by Initio is simply : horrible. Fixing it all up by hand will take days if not weeks so : I'm trying to find an easier way. I believe that indent cannot create style(9) output. You can get real close with emacs + cc-mode + 'bsd coding style. (c-set-style "bsd") (setq c-basic-offset 8 c-conditional-key c-C++-conditional-key indent-tabs-mode t c-tab-always-indent nil) (setq c-cleanup-list (append c-cleanup-list (list 'brace-else-brace))) (c-set-offset 'arglist-close 0) (c-set-offset 'arglist-cont-nonempty 4) (c-set-offset 'inline-open 0) (c-set-offset 'case-label 0) (c-set-offset 'statement-cont 4) (c-toggle-auto-state 1) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 19: 9:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 1F5F237B422 for ; Sun, 24 Sep 2000 19:09:48 -0700 (PDT) Received: (from uucp@localhost) by ns.internet.dk (8.9.3/8.9.3) with UUCP id EAA25748 for freebsd-current@freebsd.org; Mon, 25 Sep 2000 04:09:45 +0200 (CEST) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.11.0/8.11.0) with ESMTP id e8P1nDN06136 for ; Mon, 25 Sep 2000 03:49:15 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Mon, 25 Sep 2000 03:49:13 +0200 (CEST) From: Leif Neland To: freebsd-current@freebsd.org Subject: Breakage in make world: pam_ssh Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After trouble making world for some days, I blew the entire /usr/src away (and lost my kernel-config's :-( ) On a freshly cvsupped current, this has been broken for a few days. ===> libpam/modules/pam_ssh cc -O -pipe -Wall -I/usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/log-client.c -o log-client.o cc -O -pipe -Wall -I/usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c -o pam_ssh.o /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c: In function `pam_sm_open_session': /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c:446: warning: passing arg 2 of `ssh_add_identity' from incompatible pointer type building standard pam_ssh library ranlib libpam_ssh.a cc -fpic -DPIC -O -pipe -Wall -I/usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/log-client.c -o log-client.So cc -fpic -DPIC -O -pipe -Wall -I/usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c -o pam_ssh.So /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c: In function `pam_sm_open_session': /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c:446: warning: passing arg 2 of `ssh_add_identity' from incompatible pointer type make: don't know how to make /usr/obj/usr/src/i386/usr/lib/libcrypto.a. Stop *** Error code 2 Stop in /usr/src/lib/libpam/modules. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 19:17:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id EF39937B422; Sun, 24 Sep 2000 19:17:45 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id TAA99599; Sun, 24 Sep 2000 19:17:45 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 24 Sep 2000 19:17:45 -0700 (PDT) From: Kris Kennaway To: Leif Neland Cc: freebsd-current@freebsd.org Subject: Re: Breakage in make world: pam_ssh In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 25 Sep 2000, Leif Neland wrote: > After trouble making world for some days, I blew the entire /usr/src away > (and lost my kernel-config's :-( ) > > On a freshly cvsupped current, this has been broken for a few days. I think you're not cvsupping all of the source. In particular the crypto source. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 22:15:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 0BA2C37B424; Sun, 24 Sep 2000 22:15:18 -0700 (PDT) Received: (from uucp@localhost) by ns.internet.dk (8.9.3/8.9.3) with UUCP id HAA82552; Mon, 25 Sep 2000 07:15:16 +0200 (CEST) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.11.0/8.11.0) with ESMTP id e8P51aN43913; Mon, 25 Sep 2000 07:01:41 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Mon, 25 Sep 2000 07:01:36 +0200 (CEST) From: Leif Neland To: Kris Kennaway Cc: freebsd-current@FreeBSD.ORG Subject: Re: Breakage in make world: pam_ssh In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 24 Sep 2000, Kris Kennaway wrote: > On Mon, 25 Sep 2000, Leif Neland wrote: > > > After trouble making world for some days, I blew the entire /usr/src away > > (and lost my kernel-config's :-( ) > > > > On a freshly cvsupped current, this has been broken for a few days. > > I think you're not cvsupping all of the source. In particular the crypto > source. > crypto was in my cvsup-file. However, I'm now trying with src/all instead. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 22:41:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 5A89E37B424 for ; Sun, 24 Sep 2000 22:41:44 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id BAA96978; Mon, 25 Sep 2000 01:41:31 -0400 (EDT) Date: Mon, 25 Sep 2000 01:41:30 -0400 (EDT) From: "Matthew N. Dodd" To: attila! Cc: freebsd-current@FreeBSD.ORG Subject: Re: 'device random' required in conf file? In-Reply-To: <200009241927.e8OJRul21281@hun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 24 Sep 2000, attila! wrote: > linking kernel > if_spppsubr.o: in function `sppp_chap_scr': > if_spppsubr.o(.text+0x3f54): undefined reference to `read_random' > *** error code 1 > stop in /usr/src/obj/usr/src/sys/hun. > > adding (pseudo)device random to conf file made link. I had planned to > load random with loader.conf.local ... Same with the IPX code. A 'read_random' stub should be supplied to allow kernels without 'device random' to compile and run. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 23: 5:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 9462737B424 for ; Sun, 24 Sep 2000 23:05:26 -0700 (PDT) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.11.0/8.9.3) id e8P65Ju66121; Mon, 25 Sep 2000 08:05:19 +0200 (CEST) (envelope-from asmodai) Date: Mon, 25 Sep 2000 08:05:19 +0200 From: Jeroen Ruigrok van der Werven To: Blaz Zupan Cc: freebsd-current@FreeBSD.ORG Subject: Re: .indent.pro for KNF? Message-ID: <20000925080519.B60278@lucifer.bart.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from blaz@amis.net on Sun, Sep 24, 2000 at 08:24:44PM +0200 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000924 20:25], Blaz Zupan (blaz@amis.net) wrote: >Does anybody have a .indent.pro file for indent(1) that enforces KNF style as >specified in style(9)? Try this if you use vim: augroup cprog " Remove all cprog autocommands autocmd! autocmd BufNewFile,BufRead *.c,*.h set formatoptions=croql autocmd BufNewFile,BufRead *.c,*.h set cindent autocmd BufNewFile,BufRead *.c,*.h set comments=sr:/*,mb:*,el:*/,:// autocmd BufNewFile,BufRead *.c,*.h set cinoptions=t0(0 autocmd BufNewFile,BufRead *.c,*.h hi PreProc ctermfg=DarkCyan guifg =DarkCyan augroup END -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 23:52:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from unix.jdthomas.net (c755117-a.eugene1.or.home.com [24.16.233.151]) by hub.freebsd.org (Postfix) with ESMTP id 07FA137B424 for ; Sun, 24 Sep 2000 23:52:07 -0700 (PDT) Received: from Debug (c755117-a.eugene1.or.home.com [24.16.233.151]) by unix.jdthomas.net (8.11.0/8.9.3) with SMTP id e8P789G01054 for ; Mon, 25 Sep 2000 00:08:09 -0700 (PDT) (envelope-from cvs@mezzoforte.org) Message-Id: <200009250708.e8P789G01054@unix.jdthomas.net> To: freebsd-current@freebsd.org From: cvs@mezzoforte.org Subject: PNP Devices? Date: Mon, 25 Sep 2000 07:08:09 GMT X-Mailer: Endymion MailMan Standard Edition v3.0.24 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I recently CVSup'ed the latest Current sources, made world and rebuilt the kernel. I notice now that when I start the computer, I get several messages about not being able to assign resources to PNP devices. I have never seen these messages before. Can someone enlighten me as to a possible solution? Here is the pertinent output of dmesg: ppi0: on ppbus0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, unlimited logging Thanks for any advice, Justin --------------------------------------------- This message was sent through JT's Webmail. http://webmail.jdthomas.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Sep 24 23:58: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.iafrica.com (smtp02.iafrica.com [196.7.0.140]) by hub.freebsd.org (Postfix) with ESMTP id E8FBA37B422 for ; Sun, 24 Sep 2000 23:57:56 -0700 (PDT) Received: from [196.7.18.138] (helo=grimreaper.grondar.za ident=root) by smtp02.iafrica.com with esmtp (Exim 1.92 #1) id 13dSCw-0003O8-00; Mon, 25 Sep 2000 08:57:47 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e8P6vFn13720; Mon, 25 Sep 2000 08:57:18 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200009250657.e8P6vFn13720@grimreaper.grondar.za> To: "Matthew N. Dodd" Cc: attila! , freebsd-current@FreeBSD.ORG Subject: Re: 'device random' required in conf file? References: In-Reply-To: ; from "Matthew N. Dodd" "Mon, 25 Sep 2000 01:41:30 -0400." Date: Mon, 25 Sep 2000 08:57:15 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Same with the IPX code. A 'read_random' stub should be supplied to allow > kernels without 'device random' to compile and run. I'll fix this. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 1:22:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id C67D537B42C for ; Mon, 25 Sep 2000 01:22:52 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA51968; Mon, 25 Sep 2000 10:22:40 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Mark Murray Cc: "Matthew N. Dodd" , attila! , freebsd-current@FreeBSD.ORG Subject: Re: 'device random' required in conf file? References: <200009250657.e8P6vFn13720@grimreaper.grondar.za> From: Dag-Erling Smorgrav Date: 25 Sep 2000 10:22:39 +0200 In-Reply-To: Mark Murray's message of "Mon, 25 Sep 2000 08:57:15 +0200" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray writes: > > Same with the IPX code. A 'read_random' stub should be supplied to allow > > kernels without 'device random' to compile and run. > I'll fix this. For the record, it affects i4b as well. Thanks for fixing :) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 1:41:20 2000 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 072FC37B424 for ; Mon, 25 Sep 2000 01:41:18 -0700 (PDT) Received: from hcswork.hcs.de (hcswork.hcs.de [192.76.124.5]) by hcshh.hcs.de (Postfix) with ESMTP id AE69E5D78; Mon, 25 Sep 2000 10:41:16 +0200 (CEST) Received: by hcswork.hcs.de (Postfix, from userid 200) id 5D4C31D5; Mon, 25 Sep 2000 10:41:16 +0200 (METDST) Subject: Re: 'device random' required in conf file? In-Reply-To: from Dag-Erling Smorgrav at "Sep 25, 0 10:22:39 am" To: des@ofug.org (Dag-Erling Smorgrav) Date: Mon, 25 Sep 2000 10:41:16 +0200 (METDST) Cc: mark@grondar.za, winter@jurai.net, attila@hun.org, freebsd-current@FreeBSD.ORG Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 701 Message-Id: <20000925084116.5D4C31D5@hcswork.hcs.de> From: hm@hcs.de (Hellmuth Michaelis) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From the keyboard of Dag-Erling Smorgrav: > Mark Murray writes: > > > Same with the IPX code. A 'read_random' stub should be supplied to allow > > > kernels without 'device random' to compile and run. > > I'll fix this. > > For the record, it affects i4b as well. It does. I corrected this in my development tree which will be committed to current asap. 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 Mon Sep 25 4:18:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from thing.orbitel.bg (thing.orbitel.bg [195.24.32.46]) by hub.freebsd.org (Postfix) with SMTP id A4FF137B42C for ; Mon, 25 Sep 2000 04:18:05 -0700 (PDT) Received: (qmail 59190 invoked by uid 1001); 25 Sep 2000 11:18:12 -0000 Date: Mon, 25 Sep 2000 14:18:11 +0300 From: Stanislav Grozev To: Kenneth Wayne Culver Cc: freebsd-current@freebsd.org Subject: Re: -CURRENT crashes under heavy disk activity Message-ID: <20000925141811.A56557@thing.orbitel.bg> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from culverk@wam.umd.edu on Fri, Sep 22, 2000 at 03:37:32PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 22, 2000 at 03:37:32PM -0400, Kenneth Wayne Culver wrote: > I will try to build a debug kernel, and get a backtrace of what's > happening to send to the list, but basically what happened is that I was > running a cvsup of the cvs source repository and the ports repository and > it just crashed and rebooted (I'm doing this remotely, so I can't really > catch any messeges that get sent to the screen right now, not until I go > home from work). The second time it happened was doing the cvs update of > my source tree and ports tree, and it just crashed and rebooted.. I will > make a debug kernel and do a backtrace and send it as soon as I possibly > can. i've experienced the same things: -CURRENT crashes on heavy disk activity, such as rm -rf /usr/ports or cvsup/anoncvs. it crashesh hard - no panic, just freezes... downgrading to PRE_SMPNG fixes it. -tacho -- [i don't follow] | [http://daemonz.org/ || tacho@daemonz.org] [everything should be made as simple as possible, but no simpler] 0x44FC3339 || [02B5 798B 4BD1 97FB F8DB 72E4 DCA4 BE03 44FC 3339] --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE5zzRz3KS+A0T8MzkRAikoAJ9SY9rmxepHlFToINO071u2siGiOgCeLj9L C0VysmKabLvlKH5cqkTQ9Oc= =t+Pv -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 5:31:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 5C35637B50D; Mon, 25 Sep 2000 05:30:58 -0700 (PDT) Received: (from uucp@localhost) by ns.internet.dk (8.9.3/8.9.3) with UUCP id OAA25840; Mon, 25 Sep 2000 14:30:56 +0200 (CEST) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.11.0/8.11.0) with ESMTP id e8PCIjN28522; Mon, 25 Sep 2000 14:18:46 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Mon, 25 Sep 2000 14:18:45 +0200 (CEST) From: Leif Neland To: Kris Kennaway Cc: freebsd-current@FreeBSD.ORG Subject: Re: Breakage in make world: pam_ssh In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 24 Sep 2000, Kris Kennaway wrote: > On Mon, 25 Sep 2000, Leif Neland wrote: > > > After trouble making world for some days, I blew the entire /usr/src away > > (and lost my kernel-config's :-( ) > > > > On a freshly cvsupped current, this has been broken for a few days. > > I think you're not cvsupping all of the source. In particular the crypto > source. > I changed from the individual parts to src/all, and besides getting kerberos and secure, I also got these files from crypto, which I should have gotten already with src/crypto: Checkout src/sys/crypto/blowfish/bf_cbc.c Checkout src/sys/crypto/blowfish/bf_cbc_m.c Checkout src/sys/crypto/blowfish/bf_enc.c Checkout src/sys/crypto/blowfish/bf_locl.h Checkout src/sys/crypto/blowfish/bf_pi.h Checkout src/sys/crypto/blowfish/bf_skey.c Checkout src/sys/crypto/blowfish/blowfish.h Checkout src/sys/crypto/cast128/cast128.c Checkout src/sys/crypto/cast128/cast128.h Checkout src/sys/crypto/cast128/cast128_cbc.c Checkout src/sys/crypto/cast128/cast128_subkey.h Checkout src/sys/crypto/des/des.h Checkout src/sys/crypto/des/des_3cbc.c Checkout src/sys/crypto/des/des_cbc.c Checkout src/sys/crypto/des/des_ecb.c Checkout src/sys/crypto/des/des_locl.h Checkout src/sys/crypto/des/des_setkey.c Checkout src/sys/crypto/des/podd.h Checkout src/sys/crypto/des/sk.h Checkout src/sys/crypto/des/spr.h Checkout src/sys/crypto/md5.c Checkout src/sys/crypto/md5.h Checkout src/sys/crypto/rc4/rc4.c Checkout src/sys/crypto/rc4/rc4.h Checkout src/sys/crypto/rc5/rc5.c Checkout src/sys/crypto/rc5/rc5.h Checkout src/sys/crypto/rc5/rc5_cbc.c Checkout src/sys/crypto/sha1.c Checkout src/sys/crypto/sha1.h I don't know if it is because of the extra crypto-files or the secure-files, but at least the compile now doesn't stop there, but because of a missing m4-file for sendmail, which i lost when I got a new /usr/src Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 7:49: 5 2000 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 A23DA37B42C for ; Mon, 25 Sep 2000 07:48:39 -0700 (PDT) Received: from rac4.wam.umd.edu (IDENT:root@rac4.wam.umd.edu [128.8.10.144]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA11898; Mon, 25 Sep 2000 10:48:35 -0400 (EDT) Received: from rac4.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac4.wam.umd.edu (8.9.3/8.9.3) with SMTP id KAA13497; Mon, 25 Sep 2000 10:48:35 -0400 (EDT) Received: from localhost (culverk@localhost) by rac4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA13493; Mon, 25 Sep 2000 10:48:35 -0400 (EDT) X-Authentication-Warning: rac4.wam.umd.edu: culverk owned process doing -bs Date: Mon, 25 Sep 2000 10:48:34 -0400 (EDT) From: Kenneth Wayne Culver To: Stanislav Grozev Cc: freebsd-current@freebsd.org Subject: Re: -CURRENT crashes under heavy disk activity In-Reply-To: <20000925141811.A56557@thing.orbitel.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, I downgraded to PRE_SMPNG and it still crashes on heavy disk activity. ================================================================= | Kenneth Culver | FreeBSD: The best NT upgrade | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Mon, 25 Sep 2000, Stanislav Grozev wrote: > On Fri, Sep 22, 2000 at 03:37:32PM -0400, Kenneth Wayne Culver wrote: > > I will try to build a debug kernel, and get a backtrace of what's > > happening to send to the list, but basically what happened is that I was > > running a cvsup of the cvs source repository and the ports repository and > > it just crashed and rebooted (I'm doing this remotely, so I can't really > > catch any messeges that get sent to the screen right now, not until I go > > home from work). The second time it happened was doing the cvs update of > > my source tree and ports tree, and it just crashed and rebooted.. I will > > make a debug kernel and do a backtrace and send it as soon as I possibly > > can. > > i've experienced the same things: -CURRENT crashes on heavy disk activity, > such as rm -rf /usr/ports or cvsup/anoncvs. it crashesh hard - no panic, > just freezes... downgrading to PRE_SMPNG fixes it. > > -tacho > > -- > [i don't follow] | [http://daemonz.org/ || tacho@daemonz.org] > [everything should be made as simple as possible, but no simpler] > 0x44FC3339 || [02B5 798B 4BD1 97FB F8DB 72E4 DCA4 BE03 44FC 3339] > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 7:52:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from thing.orbitel.bg (thing.orbitel.bg [195.24.32.46]) by hub.freebsd.org (Postfix) with SMTP id 9F76B37B42C for ; Mon, 25 Sep 2000 07:52:33 -0700 (PDT) Received: (qmail 28399 invoked by uid 1001); 25 Sep 2000 14:52:31 -0000 Date: Mon, 25 Sep 2000 17:52:31 +0300 From: Stanislav Grozev To: Kenneth Wayne Culver Cc: freebsd-current@freebsd.org Subject: Re: -CURRENT crashes under heavy disk activity Message-ID: <20000925175231.A10255@thing.orbitel.bg> References: <20000925141811.A56557@thing.orbitel.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from culverk@wam.umd.edu on Mon, Sep 25, 2000 at 10:48:34AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 25, 2000 at 10:48:34AM -0400, Kenneth Wayne Culver wrote: > Well, I downgraded to PRE_SMPNG and it still crashes on heavy disk > activity. >=20 the funny thing is that the same kernel that crashed on my desktop pc (with SMPng, but UP kernel) works like a charm on my laptop;-)) the only difference I see, is that the desktop pc has an HighPoint ATA66 controler, but it is unused - i have no disks attached to it -tacho -- [i don't follow] | [http://daemonz.org/ || tacho@daemonz.org] [everything should be made as simple as possible, but no simpler] 0x44FC3339 || [02B5 798B 4BD1 97FB F8DB 72E4 DCA4 BE03 44FC 3339] --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE5z2av3KS+A0T8MzkRAig0AJ0QgZnJNt0w59gBYgScTc0KP/AlpACbBs4m OIf6s4bDVAa2TZd8npEQyCQ= =plCF -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 8:57:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from bsd.rrze.uni-erlangen.de (bsd.rrze.uni-erlangen.de [131.188.3.40]) by hub.freebsd.org (Postfix) with ESMTP id D977B37B422 for ; Mon, 25 Sep 2000 08:57:49 -0700 (PDT) Received: from localhost (fd@localhost) by bsd.rrze.uni-erlangen.de (8.9.3/8.9.0/FD) with ESMTP id RAA96423 for ; Mon, 25 Sep 2000 17:57:45 +0200 (CEST) Date: Mon, 25 Sep 2000 17:57:44 +0200 (CEST) From: Falko Dressler To: freebsd-current@freebsd.org Subject: bug in ccard.c (pccardd code) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I discovered a little bug in ccard.c which is part of the pccardd: *** cardd.c.orig Mon Sep 25 17:52:03 2000 --- cardd.c Mon Sep 25 17:52:12 2000 *************** *** 546,552 **** sp->config->index = cisconf->id; break; default: /* normal, use index value */ ! for (cisconf = cis->conf; cisconf; cisconf = cisconf->next) if (cisconf->id == sp->config->index) break; } --- 546,552 ---- sp->config->index = cisconf->id; break; default: /* normal, use index value */ ! for (cisconf = cis->conf; cisconf->next; cisconf = cisconf->next) if (cisconf->id == sp->config->index) break; } Someone forgot to place the right pointer into the for-loop. Could you correct this for the next version! Best regards, Falko. -- Falko Dressler Am Tiefen Weg 13, 91077 Dormitz, Germany EMail: fd@fd42.de / Phone: +49 700 DRESSLER Phone: +49 9134 993311 / Fax: +49 9134 997267 WWW: http://bsd.rrze.uni-erlangen.de/~fd/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 9:17:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 373E137B422 for ; Mon, 25 Sep 2000 09:17:39 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id JAA15692; Mon, 25 Sep 2000 09:17:30 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA02038; Mon, 25 Sep 2000 09:17:29 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Mon, 25 Sep 2000 09:17:29 -0700 (PDT) Message-Id: <200009251617.JAA02038@vashon.polstra.com> To: current@freebsd.org Reply-To: current@freebsd.org Cc: leifn@neland.dk Subject: Re: Breakage in make world: pam_ssh In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Leif Neland wrote: > > I think you're not cvsupping all of the source. In particular the crypto > > source. > > > > I changed from the individual parts to src/all, and besides getting > kerberos and secure, I also got these files from crypto, which I should > have gotten already with src/crypto: > > Checkout src/sys/crypto/blowfish/bf_cbc.c > Checkout src/sys/crypto/blowfish/bf_cbc_m.c > Checkout src/sys/crypto/blowfish/bf_enc.c [...] No, those files are in the src-sys-crypto collection, not src-crypto. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 9:42: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BCC1237B422; Mon, 25 Sep 2000 09:41:56 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id JAA83466; Mon, 25 Sep 2000 09:41:56 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 25 Sep 2000 09:41:56 -0700 (PDT) From: Kris Kennaway To: Leif Neland Cc: freebsd-current@FreeBSD.ORG Subject: Re: Breakage in make world: pam_ssh In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 25 Sep 2000, Leif Neland wrote: > I changed from the individual parts to src/all, and besides getting > kerberos and secure, I also got these files from crypto, which I should > have gotten already with src/crypto: Nope, these are in the src-sys-crypto collection. > Checkout src/sys/crypto/blowfish/bf_cbc.c [...] The fact that you checked out kerberos and secure directories means you were also missing these from your previous cvsup file - the missing secure/ is what killed you. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 9:52:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 27E4537B42C; Mon, 25 Sep 2000 09:52:01 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id DAA02156; Tue, 26 Sep 2000 03:51:56 +1100 Date: Tue, 26 Sep 2000 03:51:51 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Adrian Chadd Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Fsck wrappers, revisited In-Reply-To: <20000923114434.A4419@roaming.cacheboy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 23 Sep 2000, Adrian Chadd wrote: > On Sat, Sep 23, 2000, Bruce Evans wrote: > > On Sat, 23 Dec 2000, Adrian Chadd wrote: > > > > > Here's the patch: > > > > > > --- fsck.c.orig Sat Dec 23 11:13:30 2000 > > > +++ fsck.c Sat Dec 23 11:13:34 2000 > > > @@ -501,7 +501,7 @@ > > > errx(1, "partition `%s' is not of a legal vfstype", > > > str); > > > - if ((vfstype = dktypenames[t]) == NULL) > > > + if ((vfstype = fstypenames[t]) == NULL) > > > errx(1, "vfstype `%s' on partition `%s' is not supported", > > > fstypenames[t], str); > > > > > > > > > So now is a problem which I'm sure the NetBSD people came up against. > > > The fstypenames are names like 4.2BSD, vinum, ISO9660, etc. NetBSD fixed > > > this by creating a new list 'mountnames[]', which maps the fs type to > > > a string. > > > > fs typenames are already strings in FreeBSD (the kernel's vfc_index is an > > implementation detail which should not be visible in applications). > > Oh, wait. I understand what you're talking about now. There isn't any mapping > to partition type (p_fstype) to fs typename string. > > > > http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/sys/disklabel.h.diff?r1=1.60&r2=1.61 > > > > > > What do people think about doing this as well? It would certainly make things > > > a little tidier, but every time a new fs comes in the magic autodetection code > > > will need to be updated (if appropriate, of course.) > > > > This would be a bug. > > Well, if you have any suggestions, I'm all for it. :-) I don't understand the problem. You get the filesystem type name (fstypename) from fs_vfstype in struct fstab or from f_fstypename in struct statfs. You attempt to execute strcat("/sbin/fsck_", fstypename) to see if fsck is supported on filesystems of type fstypename. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 10: 8:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1628B37B42C; Mon, 25 Sep 2000 10:08:10 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id EAA02688; Tue, 26 Sep 2000 04:08:06 +1100 Date: Tue, 26 Sep 2000 04:08:01 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Adrian Chadd Cc: Kris Kennaway , freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Fsck wrappers, revisited In-Reply-To: <20000924105645.A7573@roaming.cacheboy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 24 Sep 2000, Adrian Chadd wrote: > On Sun, Sep 24, 2000, Kris Kennaway wrote: > > > > The trouble is that some of the FS strings have spaces in their filenames. > > > This might confuse a few people. > > > > How about mapping spaces to '_' characters - I doubt it would cause any > > namespace collisions. > > Yes, as bp mentioned to me before, so I'm thinking about passing the fsname > through a tolower() and a s/ /_/g before using it as a filename. > > Any problems with this? This shouldn't be necessary. All fstypenames for currently supported filesystems are in lower case with no underscores, and new ones should follow this convention. Spaces in the names would probably break /etc/fstab. Fstypenames for currently supported filesystems as found by grepping for VFS_SET in /sys: cd9660 coda devfs ext2fs fdesc hpfs kernfs linprocfs mfs msdos nfs ntfs ntfs nullfs nwfs portal procfs ufs umap union Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 10:33:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A60937B424 for ; Mon, 25 Sep 2000 10:33:29 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 582F26E2D02 for ; Mon, 25 Sep 2000 10:33:13 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA02943; Mon, 25 Sep 2000 11:31:56 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA05027; Mon, 25 Sep 2000 11:31:52 -0600 (MDT) Message-Id: <200009251731.LAA05027@harmony.village.org> To: cvs@mezzoforte.org Subject: Re: PNP Devices? Cc: freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Mon, 25 Sep 2000 07:08:09 GMT." <200009250708.e8P789G01054@unix.jdthomas.net> References: <200009250708.e8P789G01054@unix.jdthomas.net> Date: Mon, 25 Sep 2000 11:31:52 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200009250708.e8P789G01054@unix.jdthomas.net> cvs@mezzoforte.org writes: : these messages before. Can someone enlighten me as to a possible solution? Sure. You'll need to hack the pnp code to have the pnpbios device probed before the normal isa device. Then you'll need to hack those legacy devices that don't currently support these PnP ids. After you do that, you'll need to hack together device driver holders for some of the devices that we use in the kernel behind the device configuration system's back. Or you could just ignore them. They are harmless. Warner : Here is the pertinent output of dmesg: : : ppi0: on ppbus0 : unknown: can't assign resources : unknown: can't assign resources : unknown: can't assign resources : unknown: can't assign resources : unknown: can't assign resources : unknown: can't assign resources : IP packet filtering initialized, divert enabled, rule-based forwarding disabled, : default to deny, unlimited logging : : Thanks for any advice, : Justin : : --------------------------------------------- : This message was sent through JT's Webmail. : http://webmail.jdthomas.net/ : : : : : 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 Sep 25 10:37:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 42EF937B42C for ; Mon, 25 Sep 2000 10:37:53 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA02975; Mon, 25 Sep 2000 11:37: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.9.3/8.8.3) with ESMTP id LAA05096; Mon, 25 Sep 2000 11:37:50 -0600 (MDT) Message-Id: <200009251737.LAA05096@harmony.village.org> To: Falko Dressler Subject: Re: bug in ccard.c (pccardd code) Cc: freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Mon, 25 Sep 2000 17:57:44 +0200." References: Date: Mon, 25 Sep 2000 11:37:50 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Falko Dressler writes: : : I discovered a little bug in ccard.c which is part of the pccardd: : : *** cardd.c.orig Mon Sep 25 17:52:03 2000 : --- cardd.c Mon Sep 25 17:52:12 2000 : *************** : *** 546,552 **** : sp->config->index = cisconf->id; : break; : default: /* normal, use index value */ : ! for (cisconf = cis->conf; cisconf; cisconf = cisconf->next) : if (cisconf->id == sp->config->index) : break; : } : --- 546,552 ---- : sp->config->index = cisconf->id; : break; : default: /* normal, use index value */ : ! for (cisconf = cis->conf; cisconf->next; cisconf = cisconf->next) : if (cisconf->id == sp->config->index) : break; : } : : : Someone forgot to place the right pointer into the for-loop. Why does the change need to be made to cisconf->next. The old code looks good to me. Is the last item in the list wrong for some reason? The last item on the for loop will be evaluated, and then the middle test is done, so I don't see how this helps. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 12: 0:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 423B337B42C for ; Mon, 25 Sep 2000 12:00:45 -0700 (PDT) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id MAA06751 for ; Mon, 25 Sep 2000 12:00:41 -0700 (PDT) (envelope-from DougB@gorean.org) Date: Mon, 25 Sep 2000 12:00:40 -0700 (PDT) From: Doug Barton X-Sender: doug@dt051n37.san.rr.com To: current@freebsd.org Subject: linuxulator files with invalid ownership Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just for grins I turned on the periodic/weekly option to check for files with unknown owner/groups. It found the following: drwxrwxr-x 3 root 14 512 Jul 24 08:23 /usr/compat/linux/var/lock/ drwxrwxr-x 2 root 12 512 Feb 6 1996 /usr/compat/linux/var/spool/mail/ -r--r--r-- 1 root 15 18122 Mar 21 1999 /usr/compat/linux/usr/man/man8/setserial.8 Not an earth-shattering issue, but I thought someone would want to know. Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 12:12:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from sol.cc.u-szeged.hu (sol.cc.u-szeged.hu [160.114.8.24]) by hub.freebsd.org (Postfix) with ESMTP id 71E3037B424 for ; Mon, 25 Sep 2000 12:12:27 -0700 (PDT) Received: from petra.hos.u-szeged.hu by sol.cc.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id VAA19355; Mon, 25 Sep 2000 21:13:00 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 13ddfu-0004PA-00 for ; Mon, 25 Sep 2000 21:12:26 +0200 Date: Mon, 25 Sep 2000 21:12:26 +0200 From: Szilveszter Adam To: current@FreeBSD.ORG Subject: Mount ATAPI CD: panic [Re: fdc0 and ata1 issues] Message-ID: <20000925211226.A16558@petra.hos.u-szeged.hu> Mail-Followup-To: current@FreeBSD.ORG References: <200009231131.e8NBVGI01531@acs-24-154-25-35.zoominternet.net> <200009231201.OAA40391@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <200009231201.OAA40391@freebsd.dk>; from sos@freebsd.dk on Sat, Sep 23, 2000 at 02:01:49PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Sep 23, 2000 at 02:01:49PM +0200, Soren Schmidt wrote: > It seems Donn Miller wrote: > > In article <200009221448.JAA20935@freebsd.netcom.com> you wrote: > > > > > > > I am also seeing the fdc0 problem "fdc0: cannot reserve I/O port range". OK, just to follow up on things. After a make world and a kernel upgrade today, the floppy works again. (Thaks, Soren!) But, there is a new fun spot: this time on ata1. If I attempt to mount a CD (the CD-ROM is on ata1 as master) then it produces an instant panic (page fault.) (Up till now it just "simply" did not work, saying cd9660: Invalid argument when I attempted a mount.) Is this problem known? If not, I can supply info as needed... (CD-ROM is a Sony CDU-621, for that matter) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 12:31:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 9983637B424 for ; Mon, 25 Sep 2000 12:31:24 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id VAA43737; Mon, 25 Sep 2000 21:36:14 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200009251936.VAA43737@freebsd.dk> Subject: Re: -CURRENT crashes under heavy disk activity In-Reply-To: <20000925175231.A10255@thing.orbitel.bg> from Stanislav Grozev at "Sep 25, 2000 05:52:31 pm" To: tacho@orbitel.bg (Stanislav Grozev) Date: Mon, 25 Sep 2000 21:36:13 +0200 (CEST) Cc: culverk@wam.umd.edu (Kenneth Wayne Culver), freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Stanislav Grozev wrote: > On Mon, Sep 25, 2000 at 10:48:34AM -0400, Kenneth Wayne Culver wrote: > > Well, I downgraded to PRE_SMPNG and it still crashes on heavy disk > > activity. > > > > the funny thing is that the same kernel that crashed on my desktop pc > (with SMPng, but UP kernel) works like a charm on my laptop;-)) > > the only difference I see, is that the desktop pc has an HighPoint ATA66 > controler, but it is unused - i have no disks attached to it There is a known problem with fast disks (so far only the IBM DTLA series) and some old controllers fx the HPT366... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Sep 25 12:42:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 9315D37B422 for ; Mon, 25 Sep 2000 12:42:33 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id MAA81780; Mon, 25 Sep 2000 12:42:26 -0700 (PDT) (envelope-from obrien) Date: Mon, 25 Sep 2000 12:42:26 -0700 From: "David O'Brien" To: Mike Meyer Cc: current@freebsd.org Subject: Re: Kernel builds to wrong location? Message-ID: <20000925124226.A54795@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <14788.16494.26893.660078@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14788.16494.26893.660078@guru.mired.org>; from mwm@mired.org on Sat, Sep 16, 2000 at 10:54:22PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Sep 16, 2000 at 10:54:22PM -0500, Mike Meyer wrote: > I cvsupped and rebuilt earlier to today, only to find that the kernel > was installed as /boot/kernel/kernel instead of > /boot/kernel/kernel.ko. While fixing this was trivial, it was a bit of > a surprise. > > Is this a bug, or did I happen to catch the world in a state of change It is not a bug. I was beaten to death to change "kernel.ko" back to "kernel". -- -- David (obrien@FreeBSD.org) Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Sep 26 4:46:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp2.mail.yahoo.com (smtp2.mail.yahoo.com [128.11.68.32]) by hub.freebsd.org (Postfix) with SMTP id D378437B43E for ; Tue, 26 Sep 2000 04:46:37 -0700 (PDT) Received: from 151ppp.infohighway.proline.at (HELO wsjk02) (212.236.19.5) by smtp.mail.vip.suc.yahoo.com with SMTP; 26 Sep 2000 11:46:36 -0000 X-Apparently-From: Message-ID: <00ee01c027af$6f68e7c0$4800a8c0@wsjk02.kmjeuro.com> From: "Karl M. Joch" To: Subject: new buildworld brings most of the notebook back to work Date: Tue, 26 Sep 2000 13:46:28 +0200 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG after doing the make buldworld/buildkernel/installkernel/installworld again today CEST 10:00 most of my notebook works again: i got the floppy back i recompiled rtc/vmware2 after downloading the ports again and rtc/vmware loads and works fine now sbc recognices my ESS1879 (kde2 still doesnt play sound, but it is recogniced) the edimax 4000 pcmcia adapter works fine (needed to remove irq 5 in pccard.conf and set io to 280 instead of 240) now the open problems are only a few: rebooting doesnt work. not with shutdown -r now and not with reboot. i need to do a shutdown -h now, power off/on and the pc starts fine. to make sure the notebook works i used another disk and installed 4.1 on it from the cd set. with this rebooting works just fine. i compiled my kernel for the notebook, rebooting still works fine. as far as i remember till cvsup somewhere around the 17th i was able to reboot with 4.1. then 4.1 had the same problem as i have now with current too. pressing any key after shutdown -h now brings the same result. immediatly black screen (before any bios message) and hangs forever. the second problem cant be really verified at the moment. because suspend/resume works like the reboot. best regards, Karl __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Sep 26 8:28:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from bag-2.mail.digex.net (bag-2.mail.digex.net [204.91.99.101]) by hub.freebsd.org (Postfix) with ESMTP id BE5D337B424 for ; Tue, 26 Sep 2000 08:28:57 -0700 (PDT) Received: from mbakercorp.com (fireout.mbakercorp.com [216.3.251.135]) by bag-2.mail.digex.net (8.9.3/8.9.3) with SMTP id LAA07064 for ; Tue, 26 Sep 2000 11:28:32 -0400 (EDT) Received: from gatedom-Message_Server by mbakercorp.com with Novell_GroupWise; Tue, 26 Sep 2000 11:29:04 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 26 Sep 2000 11:27:26 -0400 From: "Joseph Wright" To: Subject: Majordomo Problem Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After installing the majordomo port I get the following message: May 31 04:04:26 n669 sendmail[66642]: EAA66641: SYSERR(root): hash=20 "Alias1": missing map file /usr/local/majordomo/aliases.majordomo.db: No = such file or directory a newaliases begets this: =20 freebsd:/etc# newaliases /etc/aliases: 41 aliases, longest 56 bytes, 784 bytes total hash map "Alias1": unsafe map file /usr/local/majordomo/aliases.majordomo.db: Permission denied WARNING: = cannot open alias database /usr/local/majordomo/aliases.majordomo Cannot = create database for alias file /usr/local/majordomo/aliases.majordomo =20 But, believe you me, the /usr/local/majordomo/aliases.majordomo *is* present, and I am running as root. thanks=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Sep 26 8:50: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [203.2.75.115]) by hub.freebsd.org (Postfix) with ESMTP id 2799737B42C for ; Tue, 26 Sep 2000 08:49:52 -0700 (PDT) Received: from echidna.stu.cowan.edu.au (perax4-081.dialup.optusnet.com.au [198.142.81.81]) by mail05.syd.optusnet.com.au (8.9.3/8.9.3) with ESMTP id CAA10008; Wed, 27 Sep 2000 02:48:47 +1100 Message-ID: <39C5C99D.5C43EB32@echidna.stu.cowan.edu.au> Date: Mon, 18 Sep 2000 15:51:57 +0800 From: Trent Nelson X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Weisgerber Cc: freebsd-current@FreeBSD.ORG Subject: Re: -Current + X 4.0.1 = mouse problems References: <8qi4d2$2c9q$1@ganerc.mips.inka.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christian Weisgerber wrote: > > Doug Barton wrote: > > > Previously I had X + moused working just fine, so I had the best > > of both worlds. With X 4.0.1 if I use moused I get no response from the > > mouse in X at all. > > Make sure you use > > Option "Protocol" "MouseSystems" > > Protocol "Auto" is not reliable. I had XFree86 4.0.1 lock my system up completely if the options "auto" & "/dev/sysmouse" were present - the screen would go blank, no keyboard or mouse response, and a hard reboot was required to get out of it. This is running a reasonably recent 5.0-CURRENT and I actually thought it may have something to do with resource locks as X worked fine if I used "auto" & "/dev/psm0" without `moused' present. Your suggestion has everything working fine now, though. Much appreciated. Regards, Trent. > > -- > Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Sep 26 9: 6: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id 1E27337B422 for ; Tue, 26 Sep 2000 09:06:02 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.1/8.11.1) id e8QG5pX21366; Tue, 26 Sep 2000 09:05:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14800.51551.519057.538499@horsey.gshapiro.net> Date: Tue, 26 Sep 2000 09:05:51 -0700 (PDT) From: Gregory Neil Shapiro To: "Joseph Wright" Cc: Subject: Re: Majordomo Problem In-Reply-To: References: X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG jwright> freebsd:/etc# newaliases jwright> /etc/aliases: 41 aliases, longest 56 bytes, 784 bytes total jwright> hash map "Alias1": unsafe map file jwright> /usr/local/majordomo/aliases.majordomo.db: Permission denied WARNING: cannot open alias database /usr/local/majordomo/aliases.majordomo Cannot create database for alias file /usr/local/majordomo/aliases.majordomo jwright> But, believe you me, the /usr/local/majordomo/aliases.majordomo *is* jwright> present, and I am running as root. This is covered in the FAQ: http://www.sendmail.org/faq/section3.html#3.32 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Sep 26 13:37:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from bag-2.mail.digex.net (bag-2.mail.digex.net [204.91.99.101]) by hub.freebsd.org (Postfix) with ESMTP id 71B5237B42C for ; Tue, 26 Sep 2000 13:37:48 -0700 (PDT) Received: from mbakercorp.com (fireout.mbakercorp.com [216.3.251.135]) by bag-2.mail.digex.net (8.9.3/8.9.3) with SMTP id QAA02869 for ; Tue, 26 Sep 2000 16:37:21 -0400 (EDT) Received: from gatedom-Message_Server by mbakercorp.com with Novell_GroupWise; Tue, 26 Sep 2000 16:37:55 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 26 Sep 2000 16:36:18 -0400 From: "Joseph Wright" To: Subject: MajorCool Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know the default password for majorcool if you install the = FreeBSD port? thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Sep 26 18: 5:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 4BF1737B422 for ; Tue, 26 Sep 2000 18:05:11 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e8R15AK10875 for ; Tue, 26 Sep 2000 18:05:10 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma010868; Tue, 26 Sep 2000 18:05:09 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id SAA21356 for freebsd-current@freebsd.org; Tue, 26 Sep 2000 18:05:08 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009270105.SAA21356@bubba.whistle.com> Subject: smbus PCI device? To: freebsd-current@freebsd.org Date: Tue, 26 Sep 2000 18:05:08 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm trying to understand this iic/smbus stuff in order to write a driver for some new hardware. The PCI bus shows this device: found-> vendor=0x8086, dev=0x2413, revid=0x02 class=0c-05-00, hdrtype=0x00, mfdev=0 ^^^^^^^^ subordinatebus=0 secondarybus=0 intpin=b, irq=10 map[20]: type 1, range 32, base 0000fe00, size 4 The class/sub-class/programming interface (highlighted above) indicates a SMBus device as specified by PCI 2.2. However, I'm not sure what that is. Adding the "smbus" device and friends to the kernel config doesn't cause this device to be detected. You'd think all I needed to do then would be to add the device ID to a list in the smbus driver somewhere, but I can't find that list. Does "smbus_pci.c" not exist yet? Of course, you can't download the PCI 2.2 spec without being a "member". Am I going down the right path trying to write a driver for this device? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Sep 26 19: 4:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from merc95.us.sas.com (merc95.us.sas.com [149.173.6.5]) by hub.freebsd.org (Postfix) with ESMTP id 55D4137B42C for ; Tue, 26 Sep 2000 19:04:41 -0700 (PDT) Received: from merc95.us.sas.com ([127.0.0.1]) by merc95.us.sas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id TA8F4K0G; Tue, 26 Sep 2000 22:04:35 -0400 Received: from 10.28.149.26 by merc95.us.sas.com (InterScan E-Mail VirusWall NT); Tue, 26 Sep 2000 22:04:34 -0400 (Eastern Daylight Time) Received: from bb01f39.unx.sas.com (bb01f39.unx.sas.com [10.16.2.246]) by mozart.unx.sas.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id WAA20369 for ; Tue, 26 Sep 2000 22:04:34 -0400 (EDT) Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.3/8.9.1) id WAA80399 for freebsd-current@freebsd.org; Tue, 26 Sep 2000 22:04:34 -0400 (EDT) (envelope-from jwd) Date: Tue, 26 Sep 2000 22:04:34 -0400 From: John DeBoskey To: freebsd-current@freebsd.org Subject: /modules vs. /boot/kernel Message-ID: <20000926220434.A80300@unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Just a heads up on a minor problem I ran into... I've had a system running 5.0-current from about 3 months ago... that system kept modules in /modules. After upgrading to -current as of today, vinum would nolonger load, complaining about: link_elf: symbol tsleep undefined Well, kldload -v vinum also complained... and sysctl reports: kern.module_path: /boot/modules/;/modules/;/boot/kernel/ To make a long story short, there was an old vinum module in /modules from the previous system/kernel. After rm'ing the /modules area everything works again. Question, is /modules still valid? I haven't seen any real discussion of it amoungst the kernel discussions... -John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Sep 26 19: 8:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id F2A8B37B422 for ; Tue, 26 Sep 2000 19:08:33 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id TAA08267; Tue, 26 Sep 2000 19:08:30 -0700 (PDT) (envelope-from obrien) Date: Tue, 26 Sep 2000 19:08:30 -0700 From: "David O'Brien" To: John DeBoskey Cc: freebsd-current@freebsd.org Subject: Re: /modules vs. /boot/kernel Message-ID: <20000926190830.B7807@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20000926220434.A80300@unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000926220434.A80300@unx.sas.com>; from jwd@unx.sas.com on Tue, Sep 26, 2000 at 10:04:34PM -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 X-Loop: FreeBSD.ORG On Tue, Sep 26, 2000 at 10:04:34PM -0400, John DeBoskey wrote: > Question, is /modules still valid? Yes. It should be used for 3rd party modules only. -- -- 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 Tue Sep 26 20:58:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id 22DBF37B423 for ; Tue, 26 Sep 2000 20:58:41 -0700 (PDT) Received: from castle2.jp.FreeBSD.org (castle2.jp.FreeBSD.org [210.226.20.120]) by updraft.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id MAA50561; Wed, 27 Sep 2000 12:58:39 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by castle2.jp.FreeBSD.org (8.11.0+3.3W/8.11.0) with ESMTP/inet id e8R3wbX84698; Wed, 27 Sep 2000 12:58:38 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: current@freebsd.org In-Reply-To: <18530.969610580@winston.osd.bsdi.com> References: <18530.969610580@winston.osd.bsdi.com> X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.2 (Molpe) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 20 From: Makoto MATSUSHITA To: jkh@winston.osd.bsdi.com Subject: Re: sysinstall: Avoiding version checking of CD-ROM (patch included) Date: Wed, 27 Sep 2000 12:57:19 +0900 Message-Id: <20000927125719J.matusita@jp.FreeBSD.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG jkh> Thanks for reminding me to go look at that code - you're right, jkh> the check is incorrectly done and insufficiently general. Fixed jkh> in -current and -stable! Very glad to hear that... thank you. Today is Wednesday and 3-stable build will run at current.jp.FreeBSD.org. If it goes successfully, I'll put cdrom.inf file to the triplex CD-ROM (yeah!). Speaking about sysinstall, would you please check my PR (bin/21423, ) ? Maybe there are few people who want to install -CURRENT to a fresh PC (too crasy ?:-), but when we want to release 5.0-RELEASE, it would be a big problem. It should be considered also that where is the best location for *GENERIC* kernel image (/boot/kernel/kernel.GENERIC is a good candidate). -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Sep 26 21:19:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id 9BC7737B422; Tue, 26 Sep 2000 21:19:17 -0700 (PDT) Received: from castle2.jp.FreeBSD.org (castle2.jp.FreeBSD.org [210.226.20.120]) by updraft.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id NAA51253; Wed, 27 Sep 2000 13:19:15 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by castle2.jp.FreeBSD.org (8.11.0+3.3W/8.11.0) with ESMTP/inet id e8R4JEX84777; Wed, 27 Sep 2000 13:19:14 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: current@FreeBSD.org In-Reply-To: <200009201720.KAA88832@freefall.freebsd.org> References: <20000921021717P.matusita@jp.FreeBSD.org> <200009201720.KAA88832@freefall.freebsd.org> X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.2 (Molpe) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 11 From: Makoto MATSUSHITA To: freebsd-gnats-submit@FreeBSD.org Subject: Re: bin/21423: Can't load kernel, after rebooting fresh-installed 5.0-CURRENT Date: Wed, 27 Sep 2000 13:17:57 +0900 Message-Id: <20000927131757T.matusita@jp.FreeBSD.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here is a status report of this PR. To announce more wider audiences, this mail is also sent to current@freebsd.org. * This PR keeps all committers away. No lucks. * If you want to install 5.0-CURRENT to a *fresh* PC, you'll be warned that your PC cannot find the kernel location. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 2:53:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id A560D37B423 for ; Wed, 27 Sep 2000 02:53:13 -0700 (PDT) Received: from zippy.pacbell.net ([207.214.149.81]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G1J00EW3I38T8@mta6.snfc21.pbi.net> for current@freebsd.org; Wed, 27 Sep 2000 02:52:22 -0700 (PDT) Received: by zippy.pacbell.net (Postfix, from userid 1000) id 826321821; Wed, 27 Sep 2000 02:53:03 -0700 (PDT) Date: Wed, 27 Sep 2000 02:53:03 -0700 From: Alex Zepeda Subject: Re: -CURRENT crashes under heavy disk activity In-reply-to: <200009251936.VAA43737@freebsd.dk>; from sos@freebsd.dk on Mon, Sep 25, 2000 at 09:36:13PM +0200 To: current@freebsd.org Message-id: <20000927025303.A367@zippy.pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20000925175231.A10255@thing.orbitel.bg> <200009251936.VAA43737@freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Sep 25, 2000 at 09:36:13PM +0200, Soren Schmidt wrote: > There is a known problem with fast disks (so far only the IBM DTLA series) > and some old controllers fx the HPT366... Hrm... since when? - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 5:54:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.sanda.gr.jp (ns.sanda.gr.jp [210.232.122.18]) by hub.freebsd.org (Postfix) with ESMTP id 478EF37B424; Wed, 27 Sep 2000 05:54:45 -0700 (PDT) Received: from ever.sanda.gr.jp (epoch [10.93.63.51]) by ns.sanda.gr.jp (8.9.3/3.7W) with ESMTP id VAA38122; Wed, 27 Sep 2000 21:54:38 +0900 (JST) From: non@ever.sanda.gr.jp Received: from localhost (localhost [127.0.0.1]) by ever.sanda.gr.jp (8.8.8/3.3W9) with ESMTP id VAA09785; Wed, 27 Sep 2000 21:54:37 +0900 (JST) To: freebsd-current@FreeBSD.org, freebsd-mobile@FreeBSD.org Cc: non@ever.sanda.gr.jp Subject: [CFR] ncv, nsp, stg SCSI drivers X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000927215437D.non@ever.sanda.gr.jp> Date: Wed, 27 Sep 2000 21:54:37 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Call for review, ncv, nsp, and stg SCSI drivers which are ported from NetBSD/pc98. I would like to merge to current and do MFC. ncv: NCR 53C500 based SCSI PC-CARDs nsp: Ninja SCSI-3 based SCSI PC-CARDs stg: TMC 18C30 based SCSI PC-Cards and ISA cards. They are tested and working on PAO3 and there are entries (totally 19) in /etc/pccard.conf, though commented out. I would like to have review especially on the changes in i386/isa/clock.c for counting delay loop numbers, and converts of SCSI layer from NetBSD one to CAM in cam/scsi/scsi_low.[ch] . They can be obtained from http://home.jp.freebsd.org/~non/scsi_low-20000926.tar.gz (added files) http://home.jp.freebsd.org/~non/scsi_low-20000926.diff.gz (diff to current) http://home.jp.freebsd.org/~non/scsi_low4-20000926.diff.gz (diff to stable) You will need the tar.gz file and one of diff.gz file. // Noriaki Mitsunaga To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 6: 1:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 7259C37B424; Wed, 27 Sep 2000 06:01:21 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.0/8.9.3) with ESMTP id e8RD1DN48128; Wed, 27 Sep 2000 15:01:13 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: non@ever.sanda.gr.jp Cc: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: [CFR] ncv, nsp, stg SCSI drivers In-Reply-To: Your message of "Wed, 27 Sep 2000 21:54:37 +0900." <20000927215437D.non@ever.sanda.gr.jp> Date: Wed, 27 Sep 2000 15:01:13 +0200 Message-ID: <48126.970059673@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000927215437D.non@ever.sanda.gr.jp>, non@ever.sanda.gr.jp writes: >I would like to have review especially on the changes in >i386/isa/clock.c for counting delay loop numbers, Could you explain the functionality you need here ? We already have a DELAY() macro/function in the kernel... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 6: 8:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.sanda.gr.jp (ns.sanda.gr.jp [210.232.122.18]) by hub.freebsd.org (Postfix) with ESMTP id 6378F37B422; Wed, 27 Sep 2000 06:08:40 -0700 (PDT) Received: from ever.sanda.gr.jp (epoch [10.93.63.51]) by ns.sanda.gr.jp (8.9.3/3.7W) with ESMTP id WAA38446; Wed, 27 Sep 2000 22:08:39 +0900 (JST) From: non@ever.sanda.gr.jp Received: from localhost (localhost [127.0.0.1]) by ever.sanda.gr.jp (8.8.8/3.3W9) with ESMTP id WAA10191; Wed, 27 Sep 2000 22:08:38 +0900 (JST) To: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: [CFR] ncv, nsp, stg SCSI drivers In-Reply-To: Your message of "Wed, 27 Sep 2000 15:01:13 +0200" <48126.970059673@critter> References: <48126.970059673@critter> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000927220838X.non@ever.sanda.gr.jp> Date: Wed, 27 Sep 2000 22:08:38 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 22 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Poul-Henning Kamp Date: Wed, 27 Sep 2000 15:01:13 +0200 > >I would like to have review especially on the changes in > >i386/isa/clock.c for counting delay loop numbers, > > Could you explain the functionality you need here ? We already > have a DELAY() macro/function in the kernel... There are codes like; int tout = sc->sc_wc; ; while (slp->sl_scp.scp_datalen > 0 && tout -- > 0) { ; } To calculate the tout we use; sc->sc_wc = delaycount * 2000; /* 2 sec */ And we initialize the delaycount in clock.c. // Noriaki Mitsunaga To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 6:13:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 19F0637B422; Wed, 27 Sep 2000 06:13:34 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.0/8.9.3) with ESMTP id e8RDDRN48278; Wed, 27 Sep 2000 15:13:27 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: non@ever.sanda.gr.jp Cc: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: [CFR] ncv, nsp, stg SCSI drivers In-Reply-To: Your message of "Wed, 27 Sep 2000 22:08:38 +0900." <20000927220838X.non@ever.sanda.gr.jp> Date: Wed, 27 Sep 2000 15:13:27 +0200 Message-ID: <48276.970060407@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000927220838X.non@ever.sanda.gr.jp>, non@ever.sanda.gr.jp writes: >From: Poul-Henning Kamp >Date: Wed, 27 Sep 2000 15:01:13 +0200 >> >I would like to have review especially on the changes in >> >i386/isa/clock.c for counting delay loop numbers, >> >> Could you explain the functionality you need here ? We already >> have a DELAY() macro/function in the kernel... > >There are codes like; > int tout = sc->sc_wc; > ; > while (slp->sl_scp.scp_datalen > 0 && tout -- > 0) > { > ; > } > >To calculate the tout we use; > sc->sc_wc = delaycount * 2000; /* 2 sec */ > >And we initialize the delaycount in clock.c. This is called "busy polling" and there must be a better way to do it. Has this code been profiled to examine typical actual delay lengths ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 6:19:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.sanda.gr.jp (ns.sanda.gr.jp [210.232.122.18]) by hub.freebsd.org (Postfix) with ESMTP id F0A0137B43E; Wed, 27 Sep 2000 06:19:35 -0700 (PDT) Received: from ever.sanda.gr.jp (epoch [10.93.63.51]) by ns.sanda.gr.jp (8.9.3/3.7W) with ESMTP id WAA38761; Wed, 27 Sep 2000 22:19:34 +0900 (JST) From: non@ever.sanda.gr.jp Received: from localhost (localhost [127.0.0.1]) by ever.sanda.gr.jp (8.8.8/3.3W9) with ESMTP id WAA10533; Wed, 27 Sep 2000 22:19:34 +0900 (JST) To: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: [CFR] ncv, nsp, stg SCSI drivers In-Reply-To: Your message of "Wed, 27 Sep 2000 15:13:27 +0200" <48276.970060407@critter> References: <48276.970060407@critter> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000927221933T.non@ever.sanda.gr.jp> Date: Wed, 27 Sep 2000 22:19:33 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 14 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Poul-Henning Kamp Date: Wed, 27 Sep 2000 15:13:27 +0200 > >And we initialize the delaycount in clock.c. > > This is called "busy polling" and there must be a better way to do it. Do you have any suggestions ? > Has this code been profiled to examine typical actual delay lengths ? I don't know. I obtained these codes from NetBSD/pc98 and I did not change here. // Noriaki Mitsunaga To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 6:25:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 8B29C37B422; Wed, 27 Sep 2000 06:25:47 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.0/8.9.3) with ESMTP id e8RDPgN48380; Wed, 27 Sep 2000 15:25:42 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: non@ever.sanda.gr.jp Cc: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: [CFR] ncv, nsp, stg SCSI drivers In-Reply-To: Your message of "Wed, 27 Sep 2000 22:19:33 +0900." <20000927221933T.non@ever.sanda.gr.jp> Date: Wed, 27 Sep 2000 15:25:42 +0200 Message-ID: <48378.970061142@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000927221933T.non@ever.sanda.gr.jp>, non@ever.sanda.gr.jp writes: >From: Poul-Henning Kamp >Date: Wed, 27 Sep 2000 15:13:27 +0200 >> >And we initialize the delaycount in clock.c. >> >> This is called "busy polling" and there must be a better way to do it. > >Do you have any suggestions ? Use a normal timeout ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 6:45:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 23E6F37B422 for ; Wed, 27 Sep 2000 06:45:32 -0700 (PDT) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.11.0/8.9.3) id e8RDjNk66524; Wed, 27 Sep 2000 15:45:23 +0200 (CEST) (envelope-from asmodai) Date: Wed, 27 Sep 2000 15:45:23 +0200 From: Jeroen Ruigrok van der Werven To: Archie Cobbs Cc: freebsd-current@FreeBSD.ORG Subject: Re: smbus PCI device? Message-ID: <20000927154523.P10657@lucifer.bart.nl> References: <200009270105.SAA21356@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200009270105.SAA21356@bubba.whistle.com>; from archie@whistle.com on Tue, Sep 26, 2000 at 06:05:08PM -0700 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000927 03:10], Archie Cobbs (archie@whistle.com) wrote: >I'm trying to understand this iic/smbus stuff in order to write >a driver for some new hardware. The PCI bus shows this device: > > found-> vendor=0x8086, dev=0x2413, revid=0x02 > class=0c-05-00, hdrtype=0x00, mfdev=0 > ^^^^^^^^ > subordinatebus=0 secondarybus=0 > intpin=b, irq=10 > map[20]: type 1, range 32, base 0000fe00, size 4 pciconf -l will probably show the class as 0x0c0500 I guess? >The class/sub-class/programming interface (highlighted above) >indicates a SMBus device as specified by PCI 2.2. > >However, I'm not sure what that is. Adding the "smbus" device and >friends to the kernel config doesn't cause this device to be >detected. You'd think all I needed to do then would be to add the >device ID to a list in the smbus driver somewhere, but I can't find >that list. Does "smbus_pci.c" not exist yet? Normally, that would be enough yes. I think you want: src/sys/dev/iicbus and src/sys/dev/smbus >Of course, you can't download the PCI 2.2 spec without being a >"member". Cute eh? >Am I going down the right path trying to write a driver for >this device? Normally adding the vid/rid combo should at least detect it yes. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 6:56:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp1.mail.yahoo.com (smtp1.mail.yahoo.com [128.11.69.60]) by hub.freebsd.org (Postfix) with SMTP id 977C137B423 for ; Wed, 27 Sep 2000 06:56:49 -0700 (PDT) Received: from 151ppp.infohighway.proline.at (HELO wsjk02) (212.236.19.5) by smtp.mail.vip.suc.yahoo.com with SMTP; 27 Sep 2000 13:56:44 -0000 X-Apparently-From: Message-ID: <016901c0288a$c7951cd0$4800a8c0@wsjk02.kmjeuro.com> From: "Karl M. Joch" To: , Subject: ESS1879 hwptr went backward? Date: Wed, 27 Sep 2000 15:56:45 +0200 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Notebook: KAPOK 8700 (sold under different brands) 233Mhz MMX, 128 MB, 4GB, ESS 1879 sound: the ESS 1879 is correctly detected when booting. also cat /dev/sndstat shows up ESS 1878 irq5 io 240 1:3 (1p:1r). also tried it with using only one DMA. but when trying to play ( cat somesound.au > /dev/audio) i get the message: hwptr went backwards 0->4092 and the system crashes hard. only power off possible. i havnt used sound for a longer time, but i am sure in 3.4 it has played with pcm. running Current of 26th Sep. -- my open problems: reboot & shutdown -r hangs the box. (shutdown works, after pressing a key i see rebooting, then screen is black and box hangs) staroffice 52 works fine under KDE2 except when having a network connection (mail, www) the statusline says making connection to somehost (netstat shows a connection) and it waits forever. vmware and serial: when i run the nokia pc suite for the communicator on NT/vmware and connect to the mobile i can see the data. small transfers works fine. when trying to do a backup it looks like there is a communication problem when sending more data. parts of the data are transfered but the it displays an error. as usual without any hints under windows. already slowed down to 9600. no success. browsing the gsm fones data works. there is one message when booting: isa0: too many dependant configs (8). ?????? -- thanks for any tips. Karl _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 7:16:22 2000 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 16C8A37B42C; Wed, 27 Sep 2000 07:16:07 -0700 (PDT) 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 KAA20916; Wed, 27 Sep 2000 10:16:04 -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 KAA04647; Wed, 27 Sep 2000 10:16:04 -0400 (EDT) Received: from localhost (culverk@localhost) by rac2.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA04636; Wed, 27 Sep 2000 10:16:04 -0400 (EDT) X-Authentication-Warning: rac2.wam.umd.edu: culverk owned process doing -bs Date: Wed, 27 Sep 2000 10:16:03 -0400 (EDT) From: Kenneth Wayne Culver To: "Karl M. Joch" Cc: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: ESS1879 hwptr went backward? In-Reply-To: <016901c0288a$c7951cd0$4800a8c0@wsjk02.kmjeuro.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -CURRENT as of the smpng commits is really unstable... it's even somewhat unstable before that (I was having crashes on heavy disk activity even at the smpng commit, which could've been just my lack of knowledge of cvs and screwing up my source tree, but that's what was happening.) ================================================================= | Kenneth Culver | FreeBSD: The best NT upgrade | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Wed, 27 Sep 2000, Karl M. Joch wrote: > Notebook: KAPOK 8700 (sold under different brands) 233Mhz MMX, 128 MB, 4GB, ESS 1879 sound: > > the ESS 1879 is correctly detected when booting. also cat /dev/sndstat shows up ESS 1878 irq5 io 240 > 1:3 (1p:1r). also tried it with using only one DMA. > > but when trying to play ( cat somesound.au > /dev/audio) i get the message: > > hwptr went backwards 0->4092 > > and the system crashes hard. only power off possible. i havnt used sound for a longer time, but i am > sure in 3.4 it has played with pcm. > > running Current of 26th Sep. > > -- > > my open problems: > > reboot & shutdown -r hangs the box. (shutdown works, after pressing a key i see rebooting, then > screen is black and box hangs) > > staroffice 52 works fine under KDE2 except when having a network connection (mail, www) the > statusline says making connection to somehost (netstat shows a connection) and it waits forever. > > vmware and serial: when i run the nokia pc suite for the communicator on NT/vmware and connect to > the mobile i can see the data. small transfers works fine. when trying to do a backup it looks like > there is a communication problem when sending more data. parts of the data are transfered but the it > displays an error. as usual without any hints under windows. already slowed down to 9600. no > success. browsing the gsm fones data works. > > there is one message when booting: isa0: too many dependant configs (8). ?????? > -- > > thanks for any tips. > > Karl > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > > 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 Sep 27 8:52:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp1.mail.yahoo.com (smtp1.mail.yahoo.com [128.11.69.60]) by hub.freebsd.org (Postfix) with SMTP id 578F937B423 for ; Wed, 27 Sep 2000 08:52:02 -0700 (PDT) Received: from 151ppp.infohighway.proline.at (HELO wsjk02) (212.236.19.5) by smtp.mail.vip.suc.yahoo.com with SMTP; 27 Sep 2000 15:51:59 -0000 X-Apparently-From: Message-ID: <01bd01c0289a$e17771b0$4800a8c0@wsjk02.kmjeuro.com> From: "Karl M. Joch" To: , Subject: Re: ESS1879 hwptr went backward? Date: Wed, 27 Sep 2000 17:51:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG the production servers are all on 4.1 at the moment. the notebook is more a game to get it to run with sound and all that stuff normally nobody really needs. as long as i can use ssh and vmware i dont really care about a crash. i am more curious to see what the future brings. and at least current brought me to start learn C. till now i only know BS2000 assembler, cobol and perl. btw, i am more or less new to this list. if my mails are placed wrong here please tell me. best regards, karl -----Ursprüngliche Nachricht----- Von: Kenneth Wayne Culver An: Karl M. Joch Cc: freebsd-current@FreeBSD.ORG ; freebsd-mobile@FreeBSD.ORG Datum: Mittwoch, 27. September 2000 16:27 Betreff: Re: ESS1879 hwptr went backward? >-CURRENT as of the smpng commits is really unstable... it's even somewhat >unstable before that (I was having crashes on heavy disk activity even at >the smpng commit, which could've been just my lack of knowledge of cvs and >screwing up my source tree, but that's what was happening.) > > >================================================================= >| Kenneth Culver | FreeBSD: The best NT upgrade | >| Unix Systems Administrator | ICQ #: 24767726 | >| and student at The | AIM: muythaibxr | >| The University of Maryland, | Website: (Under Construction) | >| College Park. | http://www.wam.umd.edu/~culverk/| >================================================================= > >On Wed, 27 Sep 2000, Karl M. Joch wrote: > >> Notebook: KAPOK 8700 (sold under different brands) 233Mhz MMX, 128 MB, 4GB, ESS 1879 sound: >> >> the ESS 1879 is correctly detected when booting. also cat /dev/sndstat shows up ESS 1878 irq5 io 240 >> 1:3 (1p:1r). also tried it with using only one DMA. >> >> but when trying to play ( cat somesound.au > /dev/audio) i get the message: >> >> hwptr went backwards 0->4092 >> >> and the system crashes hard. only power off possible. i havnt used sound for a longer time, but i am >> sure in 3.4 it has played with pcm. >> >> running Current of 26th Sep. >> >> -- >> >> my open problems: >> >> reboot & shutdown -r hangs the box. (shutdown works, after pressing a key i see rebooting, then >> screen is black and box hangs) >> >> staroffice 52 works fine under KDE2 except when having a network connection (mail, www) the >> statusline says making connection to somehost (netstat shows a connection) and it waits forever. >> >> vmware and serial: when i run the nokia pc suite for the communicator on NT/vmware and connect to >> the mobile i can see the data. small transfers works fine. when trying to do a backup it looks like >> there is a communication problem when sending more data. parts of the data are transfered but the it >> displays an error. as usual without any hints under windows. already slowed down to 9600. no >> success. browsing the gsm fones data works. >> >> there is one message when booting: isa0: too many dependant configs (8). ?????? >> -- >> >> thanks for any tips. >> >> Karl >> >> >> >> >> _________________________________________________________ >> Do You Yahoo!? >> Get your free @yahoo.com address at http://mail.yahoo.com >> >> >> >> 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 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 12:18:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id BA20337B422 for ; Wed, 27 Sep 2000 12:18:41 -0700 (PDT) Received: from ix.netcom.com (sil-wa17-10.ix.netcom.com [207.93.156.10]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA19291 for ; Wed, 27 Sep 2000 15:18:32 -0400 (EDT) Received: (from tomdean@localhost) by ix.netcom.com (8.11.0/8.9.3) id e8RJITv03988; Wed, 27 Sep 2000 12:18:29 -0700 (PDT) (envelope-from tomdean@ix.netcom.com) Date: Wed, 27 Sep 2000 12:18:29 -0700 (PDT) Message-Id: <200009271918.e8RJITv03988@ix.netcom.com> From: "Thomas D. Dean" To: freebsd-current@FreeBSD.ORG Subject: Unknown PCI chipsets Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am trying to identify some PCI chips on my Toshiba Satellite Pro 4340. Looking at sys/pci/pcisupport.c and dmesg, is it safe to assume these are matches? Looking at the spec of the system, it seems logical. pci0: (vendor=0x11c1, dev=0x0441) at 7.0 irq 3 return ("LUCENT K56Flex DSVD LTMODEM (winmodem, unsupported)"); pci0: (vendor=0x1179, dev=0x0d01) at 9.0 irq 11 return ("Toshiba Fast Infra Red controller"); What might this be? vendor? pci0: (vendor=0x1073, dev=0x0010) at 12.0 irq 11 Maybe a "Yahama YMF744B-R sound support, Windows Sound System and Sound Blaster Pro - compatible 16-bit stereo with MIDI, 3D Sound, Direct Sound andDirect 3D Sound support"? tomdean I am looking at -current # uname -a FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #0: \ Sun Sep 24 09:29:12 PDT 2000 \ tomdean@celebris:/usr/obj/usr/src/sys/CELEBRIS-SMP i386 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 12:30:24 2000 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 E9ED137B423 for ; Wed, 27 Sep 2000 12:30:10 -0700 (PDT) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id e8RJP9J17637; Wed, 27 Sep 2000 12:25:09 -0700 Date: Wed, 27 Sep 2000 12:25:09 -0700 From: Brooks Davis To: "Thomas D. Dean" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Unknown PCI chipsets Message-ID: <20000927122509.B16883@Odin.AC.HMC.Edu> References: <200009271918.e8RJITv03988@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200009271918.e8RJITv03988@ix.netcom.com>; from tomdean@ix.netcom.com on Wed, Sep 27, 2000 at 12:18:29PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Sep 27, 2000 at 12:18:29PM -0700, Thomas D. Dean wrote: > I am trying to identify some PCI chips on my Toshiba Satellite Pro > 4340. > > Looking at sys/pci/pcisupport.c and dmesg, is it safe to assume these > are matches? Looking at the spec of the system, it seems logical. These are thing for which there is no driver, but we know what they are. > pci0: (vendor=0x11c1, dev=0x0441) at 7.0 irq 3 > return ("LUCENT K56Flex DSVD LTMODEM (winmodem, unsupported)"); > > pci0: (vendor=0x1179, dev=0x0d01) at 9.0 irq 11 > return ("Toshiba Fast Infra Red controller"); > > What might this be? vendor? > pci0: (vendor=0x1073, dev=0x0010) at 12.0 irq 11 > Maybe a "Yahama YMF744B-R sound support, Windows Sound System > and Sound Blaster Pro - compatible 16-bit stereo with MIDI, > 3D Sound, Direct Sound andDirect 3D Sound support"? Chip Number: YMF744B Description: DS-1S PCI audio controller http://www.yourvote.com/pci/ is your friend. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 15:37:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 8F83837B422 for ; Wed, 27 Sep 2000 15:37:40 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id SAA60867; Wed, 27 Sep 2000 18:37:38 -0400 (EDT) Date: Wed, 27 Sep 2000 18:37:38 -0400 (EDT) From: "Matthew N. Dodd" To: "Thomas D. Dean" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Unknown PCI chipsets In-Reply-To: <200009271918.e8RJITv03988@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 27 Sep 2000, Thomas D. Dean wrote: > What might this be? vendor? > pci0: (vendor=0x1073, dev=0x0010) at 12.0 irq 11 > Maybe a "Yahama YMF744B-R sound support, Windows Sound System > and Sound Blaster Pro - compatible 16-bit stereo with MIDI, > 3D Sound, Direct Sound andDirect 3D Sound support"? My reference says: { 0x1073, 0x0010, "YMF744", "DS-1S PCI audio controller" } , (http://www.yourvote.com/pci/) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 15:55:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by hub.freebsd.org (Postfix) with ESMTP id 395D837B422 for ; Wed, 27 Sep 2000 15:55:53 -0700 (PDT) Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp (Exim 3.12 #7) id 13eQ79-0003t7-00 for freebsd-current@freebsd.org; Wed, 27 Sep 2000 22:55:47 +0000 Received: from [204.1.90.43] (helo=power) by dfw-mmp4.email.verio.net with smtp (Exim 3.15 #4) id 13eQ79-0007OL-00 for freebsd-current@FreeBSD.ORG; Wed, 27 Sep 2000 22:55:47 +0000 From: "Tony Johnson" To: Subject: interesting problem Date: Wed, 27 Sep 2000 17:55:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When I booted the 9/27/2000 (ie. today) I got a page fault 12 in kernel mode. The problem seems to be because I have all my IDE devices turned off in my bios. If this is the case, please undo this! That would be the silliest reason for a kernel to not boot because I want to save irq's. I got this from downloading the flp images and fdimage-ing them to disks! Please fix this To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 16:48:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E736337B422; Wed, 27 Sep 2000 16:48:29 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id QAA99602; Wed, 27 Sep 2000 16:48:29 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Wed, 27 Sep 2000 16:48:29 -0700 (PDT) From: Kris Kennaway To: Tony Johnson Cc: freebsd-current@FreeBSD.ORG Subject: Re: interesting problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 27 Sep 2000, Tony Johnson wrote: > When I booted the 9/27/2000 (ie. today) I got a page fault 12 in kernel > mode. The problem seems to be because I have all my IDE devices turned off > in my bios. If this is the case, please undo this! That would be the > silliest reason for a kernel to not boot because I want to save irq's. I > got this from downloading the flp images and fdimage-ing them to disks! > > Please fix this You havent given enough information to diagnose the problem. See the handbook about kernel debugging. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 17: 7:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by hub.freebsd.org (Postfix) with ESMTP id 66EB837B422; Wed, 27 Sep 2000 17:07:19 -0700 (PDT) Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp (Exim 3.12 #7) id 13eREM-0005QM-00; Thu, 28 Sep 2000 00:07:18 +0000 Received: from [204.1.90.43] (helo=power) by dfw-mmp2.email.verio.net with smtp (Exim 3.15 #4) id 13eREL-0002F7-00; Thu, 28 Sep 2000 00:07:18 +0000 From: "Tony Johnson" To: "Kris Kennaway" Cc: Subject: RE: interesting problem Date: Wed, 27 Sep 2000 19:07:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't believe the handbook covers "today's" 5.0-Current... Why would having no bustmastering DMA IDE disk contriollers on an all-scsi system cause a system to page fault from "today's" kern.flp && mfsroot.flp boot floppy. Try again... -----Original Message----- From: Kris Kennaway [mailto:kris@FreeBSD.org] Sent: Wednesday, September 27, 2000 6:48 PM To: Tony Johnson Cc: freebsd-current@FreeBSD.ORG Subject: Re: interesting problem On Wed, 27 Sep 2000, Tony Johnson wrote: > When I booted the 9/27/2000 (ie. today) I got a page fault 12 in kernel > mode. The problem seems to be because I have all my IDE devices turned off > in my bios. If this is the case, please undo this! That would be the > silliest reason for a kernel to not boot because I want to save irq's. I > got this from downloading the flp images and fdimage-ing them to disks! > > Please fix this You havent given enough information to diagnose the problem. See the handbook about kernel debugging. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 17:17:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 81DE637B422; Wed, 27 Sep 2000 17:17:52 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id RAA15087; Wed, 27 Sep 2000 17:17:52 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Wed, 27 Sep 2000 17:17:52 -0700 (PDT) From: Kris Kennaway To: Tony Johnson Cc: freebsd-current@FreeBSD.ORG Subject: RE: interesting problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 27 Sep 2000, Tony Johnson wrote: > I don't believe the handbook covers "today's" 5.0-Current... > Why would having no bustmastering DMA IDE disk contriollers on an all-scsi > system cause a system to page fault from "today's" kern.flp && mfsroot.flp > boot floppy. > > Try again... No, you try again: > You havent given enough information to diagnose the problem. See the > handbook about kernel debugging. Did you even look at the handbook section in question? Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 17:18:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2F5BB37B422; Wed, 27 Sep 2000 17:18:31 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8S0IUE06316; Wed, 27 Sep 2000 17:18:30 -0700 (PDT) Date: Wed, 27 Sep 2000 17:18:30 -0700 From: Alfred Perlstein To: Tony Johnson Cc: Kris Kennaway , freebsd-current@FreeBSD.ORG Subject: Re: interesting problem Message-ID: <20000927171829.J9141@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from gjohnson@gs.verio.net on Wed, Sep 27, 2000 at 07:07:17PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 27 Sep 2000, Tony Johnson wrote: > > > When I booted the 9/27/2000 (ie. today) I got a page fault 12 in kernel > > mode. The problem seems to be because I have all my IDE devices turned > off > > in my bios. If this is the case, please undo this! That would be the > > silliest reason for a kernel to not boot because I want to save irq's. I > > got this from downloading the flp images and fdimage-ing them to disks! > > > > Please fix this > > You havent given enough information to diagnose the problem. See the > handbook about kernel debugging. > > Kris * Tony Johnson [000927 17:07] wrote: > I don't believe the handbook covers "today's" 5.0-Current... > Why would having no bustmastering DMA IDE disk contriollers on an all-scsi > system cause a system to page fault from "today's" kern.flp && mfsroot.flp > boot floppy. > > Try again... > How about "go away"? Don't be rude to a developer offering good advice, if you're unable to follow his instructions on how to provide a crashdump you shouldn't be running -current or you should at least ask nicely. And -current is covered in the handbook: http://www.freebsd.org/handbook/current-stable.html later, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 18: 7: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from sydney.worldwide.lemis.com (asbestos.linuxcare.com.au [203.17.0.30]) by hub.freebsd.org (Postfix) with ESMTP id A5A1537B61A for ; Wed, 27 Sep 2000 18:05:53 -0700 (PDT) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.9.3/8.9.3) id LAA11432; Thu, 28 Sep 2000 11:34:44 +1100 (EST) (envelope-from grog) Date: Thu, 28 Sep 2000 11:34:44 +1100 From: Greg Lehey To: Tony Johnson Cc: Kris Kennaway , freebsd-current@FreeBSD.ORG Subject: Re: interesting problem Message-ID: <20000928113444.F11123@sydney.worldwide.lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from gjohnson@gs.verio.net on Wed, Sep 27, 2000 at 07:07:17PM -0500 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Format recovered--see http://www.lemis.com/email/email-format.html] On Wednesday, 27 September 2000 at 19:07:17 -0500, Tony Johnson wrote: > On Wednesday, September 27, 2000 6:48 PM, Kris Kennaway wrote: >> On Wed, 27 Sep 2000, Tony Johnson wrote: >>> When I booted the 9/27/2000 (ie. today) I got a page fault 12 in >>> kernel mode. The problem seems to be because I have all my IDE >>> devices turned off in my bios. This is a claim which you need to substantiate. >>> If this is the case, please undo this! How do we know if this is the case? >>> That would be the silliest reason for a kernel to not boot because >>> I want to save irq's. I got this from downloading the flp images >>> and fdimage-ing them to disks! Well, no, I can think of sillier reasons. But if it's the case, we should do something about it. >>> Please fix this Fix what? >> You havent given enough information to diagnose the problem. See the >> handbook about kernel debugging. > > I don't believe the handbook covers "today's" 5.0-Current... It contains information that you need to understand. > Why would having no bustmastering DMA IDE disk contriollers on an > all-scsi system cause a system to page fault from "today's" kern.flp > && mfsroot.flp boot floppy. Who knows? You haven't given any evidence for this opinion. > Try again... Your turn. If you run -CURRENT, you're expected to do some work yourself. Certainly it's inappropriate to make an unsubstantiated claim and then say "fix it". If you want help, do what people suggest and come back with sensible questions if you don't understand something. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 18:18:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from kbtfw.kubota.co.jp (kbtfw.kubota.co.jp [133.253.102.202]) by hub.freebsd.org (Postfix) with ESMTP id 9A42B37B424; Wed, 27 Sep 2000 18:18:36 -0700 (PDT) Received: by kbtfw.kubota.co.jp; id KAA27276; Thu, 28 Sep 2000 10:18:34 +0900 (JST) Received: from unknown(133.253.122.1) by kbtfw.kubota.co.jp via smap (V4.2) id xma027082; Thu, 28 Sep 00 10:18:18 +0900 Received: from jkpc15.tk.kubota.co.jp ([133.253.157.145]) by kbtmx.eto.kubota.co.jp (8.9.3+3.2W/3.7W) with ESMTP id KAA22980; Thu, 28 Sep 2000 10:18:17 +0900 (JST) Received: from localhost (localhost.tk.kubota.co.jp [127.0.0.1]) by jkpc15.tk.kubota.co.jp (8.11.0/3.7W-02/21/99) with ESMTP id e8S1HLY00475; Thu, 28 Sep 2000 10:17:21 +0900 (JST) To: takawata@FreeBSD.org Cc: freebsd-current@FreeBSD.org, acpi-jp@jp.FreeBSD.org Subject: My system hang with ACPI kernel thread In-Reply-To: <200009261209.FAA20201@freefall.freebsd.org> References: <200009261209.FAA20201@freefall.freebsd.org> 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: <20000928101721L.haro@tk.kubota.co.jp> Date: Thu, 28 Sep 2000 10:17:21 +0900 From: Munehiro Matsuda X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Takawata-san, With the addition of ACPI kernel thread, my system hangs in about 10 miniutes use after boot up. By disabling kernel thread, system runs just fine. Do you have any idea where to look at? I'll try and see what I can do myself. BTW, patch in [acpi-jp 576] also had the same symptom, but I forgot report back to you, Sorry. :-( Thanks, Haro =------------------------------------------------------------------------------ _ _ 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 Wed Sep 27 18:26:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by hub.freebsd.org (Postfix) with ESMTP id 8778D37B423; Wed, 27 Sep 2000 18:26:15 -0700 (PDT) Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp (Exim 3.12 #7) id 13eSSk-0003pg-00; Thu, 28 Sep 2000 01:26:14 +0000 Received: from [204.1.90.43] (helo=power) by dfw-mmp2.email.verio.net with smtp (Exim 3.15 #4) id 13eSSk-0004pg-00; Thu, 28 Sep 2000 01:26:14 +0000 From: "Tony Johnson" To: "Greg Lehey" Cc: "Kris Kennaway" , Subject: RE: interesting problem Date: Wed, 27 Sep 2000 20:26:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20000928113444.F11123@sydney.worldwide.lemis.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK Well Here is the issue. If I put in the 2 boot floppies I get a page fault 12 after I press Q for "quit" on the visual kernel config. If I can save a crash dump before any FS's are mounted or even before I tell FBSD where to put the crash dump, I'd really like to know this... I'd like to read a handbook page on thisb since some people think I just haven't read it. At this point in an install, if you could tell me (and the rest of the FreeBSD users) where I could get the boot floppies to save a crash dump (because I haven't even gotten this far) then I would appreciate this amd be more then happy to substantiate this by sending you a crash dump. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 18:39:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 16E2937B422; Wed, 27 Sep 2000 18:39:46 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8S1dep08890; Wed, 27 Sep 2000 18:39:40 -0700 (PDT) Date: Wed, 27 Sep 2000 18:39:39 -0700 From: Alfred Perlstein To: Tony Johnson Cc: Greg Lehey , Kris Kennaway , freebsd-current@FreeBSD.ORG Subject: Re: interesting problem Message-ID: <20000927183939.B7553@fw.wintelcom.net> References: <20000928113444.F11123@sydney.worldwide.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from gjohnson@gs.verio.net on Wed, Sep 27, 2000 at 08:26:13PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Tony Johnson [000927 18:26] wrote: > OK > Well Here is the issue. If I put in the 2 boot floppies I get a page fault > 12 after I press Q for "quit" on the visual kernel config. If I can save a > crash dump before any FS's are mounted or even before I tell FBSD where to > put the crash dump, I'd really like to know this... I'd like to read a > handbook page on thisb since some people think I just haven't read it. > > At this point in an install, if you could tell me (and the rest of the > FreeBSD users) where I could get the boot floppies to save a crash dump > (because I haven't even gotten this far) then I would appreciate this amd be > more then happy to substantiate this by sending you a crash dump. Do you realize how much developer time you're wasting by thrashing around cluelessly on the list demanding help? Here's a clue: Forget about your damn irq problem, boot with the disks installed, then read section of the handbook about crashdumps, compile a debug kernel and figure out what the problem is. Fix it and send us a patch. Or you could simply run -stable. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 21:22:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 9E40C37B423 for ; Wed, 27 Sep 2000 21:22:32 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e8S4MNm23567; Wed, 27 Sep 2000 21:22:23 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma023565; Wed, 27 Sep 2000 21:22:19 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id VAA30166; Wed, 27 Sep 2000 21:22:19 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009280422.VAA30166@bubba.whistle.com> Subject: Re: smbus PCI device? In-Reply-To: <20000927154523.P10657@lucifer.bart.nl> "from Jeroen Ruigrok van der Werven at Sep 27, 2000 03:45:23 pm" To: Jeroen Ruigrok van der Werven Date: Wed, 27 Sep 2000 21:22:19 -0700 (PDT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeroen Ruigrok van der Werven writes: > > found-> vendor=0x8086, dev=0x2413, revid=0x02 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > ^^^^^^^^ > > subordinatebus=0 secondarybus=0 > > intpin=b, irq=10 > > map[20]: type 1, range 32, base 0000fe00, size 4 > > pciconf -l will probably show the class as 0x0c0500 I guess? Yes. > >The class/sub-class/programming interface (highlighted above) > >indicates a SMBus device as specified by PCI 2.2. > > > >However, I'm not sure what that is. Adding the "smbus" device and > >friends to the kernel config doesn't cause this device to be > >detected. You'd think all I needed to do then would be to add the > >device ID to a list in the smbus driver somewhere, but I can't find > >that list. Does "smbus_pci.c" not exist yet? > > Normally, that would be enough yes. I think you want: > > src/sys/dev/iicbus and src/sys/dev/smbus Those are in, but there is no driver that recognizes the device and vendor ID above. Guess I'll have to write one as soon as I can get the PCI 2.2 spec. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 21:38:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200]) by hub.freebsd.org (Postfix) with ESMTP id 72FAF37B423 for ; Wed, 27 Sep 2000 21:38:41 -0700 (PDT) Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id NAA63726; Thu, 28 Sep 2000 13:38:57 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200009280438.NAA63726@shidahara1.planet.sci.kobe-u.ac.jp> To: Munehiro Matsuda Cc: current@freebsd.org, acpi-jp@jp.freebsd.org Subject: Re: My system hang with ACPI kernel thread In-reply-to: Your message of "Thu, 28 Sep 2000 10:17:21 JST." <20000928101721L.haro@tk.kubota.co.jp> Date: Thu, 28 Sep 2000 13:38:57 +0900 From: Takanori Watanabe Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000928101721L.haro@tk.kubota.co.jp>, Munehiro Matsuda wrote: >With the addition of ACPI kernel thread, my system hangs in about >10 miniutes use after boot up. By disabling kernel thread, system >runs just fine. > >Do you have any idea where to look at? >I'll try and see what I can do myself. Please set debug.aml_debug and debug.acpi_debug to 1 and see what will happen. Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Sep 27 23:33:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from simon.catburg.net (cust-92-32.customer.jump.net [207.8.92.32]) by hub.freebsd.org (Postfix) with ESMTP id 4BFE037B423 for ; Wed, 27 Sep 2000 23:33:21 -0700 (PDT) Received: (from faulkner@localhost) by simon.catburg.net (8.11.0/8.11.0) id e8S6ToV00731 for freebsd-current@freebsd.org; Thu, 28 Sep 2000 01:29:50 -0500 (CDT) (envelope-from faulkner) Date: Thu, 28 Sep 2000 01:29:50 -0500 From: "Boyd R. Faulkner" To: freebsd-current@freebsd.org Subject: Network bridge on current. Message-ID: <20000928012950.A715@simon.catburg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am wondering how to do network bridging on current. The description in the handbook seems to be out of date as the sysctl IODs are no longer in evidence. Does loading ng_bridge substitute for building the kernel with OPTIONS BRIDGE? Thanks, Boyd -- Boyd Faulkner "...but the chocolate at faulkner@asgard.hos.net Rumpelmayer's is great..." http://asgard.hos.net/~faulkner -- A. Crowley Book of Lies 1011101 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 0:11:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from cx281057-a.irvn1.occa.home.com (cx281057-a.irvn1.occa.home.com [24.1.175.22]) by hub.freebsd.org (Postfix) with ESMTP id 2D13A37B423 for ; Thu, 28 Sep 2000 00:11:44 -0700 (PDT) Received: from cx281057-a.irvn1.occa.home.com (localhost [127.0.0.1]) by cx281057-a.irvn1.occa.home.com (8.11.0/8.11.0) with ESMTP id e8S7Bs771200; Thu, 28 Sep 2000 00:11:55 -0700 (PDT) (envelope-from housel@acm.org) Date: Thu, 28 Sep 2000 00:11:54 -0700 Message-ID: From: housel@acm.org (Peter S. Housel) To: faulkner@asgard.hos.net Cc: freebsd-current@FreeBSD.ORG Subject: Re: Network bridge on current. In-Reply-To: In your message of "Thu, 28 Sep 2000 01:29:50 -0500" <20000928012950.A715@simon.catburg.net> References: <20000928012950.A715@simon.catburg.net> User-Agent: Wanderlust/1.1.1 (Purple Rain) WEMI/1.13.7 (Shimada) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am wondering how to do network bridging on current. The description > in the handbook seems to be out of date as the sysctl IODs are no longer > in evidence. Does loading ng_bridge substitute for building the kernel > with OPTIONS BRIDGE? Excuse my ignorance (and curiousity), but wouldn't it be cheaper to just buy a switch? Cheers, -Peter S. Housel- housel@acm.org http://members.home.com/housel/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 0:26:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from simon.catburg.net (cust-92-32.customer.jump.net [207.8.92.32]) by hub.freebsd.org (Postfix) with ESMTP id 0F77F37B422 for ; Thu, 28 Sep 2000 00:26:12 -0700 (PDT) Received: (from faulkner@localhost) by simon.catburg.net (8.11.0/8.11.0) id e8S7MW700986; Thu, 28 Sep 2000 02:22:32 -0500 (CDT) (envelope-from faulkner) Date: Thu, 28 Sep 2000 02:22:30 -0500 From: "Boyd R. Faulkner" To: "Peter S. Housel" Cc: faulkner@asgard.hos.net, freebsd-current@FreeBSD.ORG Subject: Re: Network bridge on current. Message-ID: <20000928022230.A967@simon.catburg.net> References: <20000928012950.A715@simon.catburg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from housel@acm.org on Thu, Sep 28, 2000 at 12:11:54AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Sep 28, 2000 at 12:11:54AM -0700, Peter S. Housel wrote: > > I am wondering how to do network bridging on current. The description > > in the handbook seems to be out of date as the sysctl IODs are no longer > > in evidence. Does loading ng_bridge substitute for building the kernel > > with OPTIONS BRIDGE? > > Excuse my ignorance (and curiousity), but wouldn't it be cheaper to > just buy a switch? > > Cheers, > -Peter S. Housel- housel@acm.org http://members.home.com/housel/ I intend to use it as a firewall. The switch will live behind it. Boyd -- Boyd Faulkner "...but the chocolate at faulkner@asgard.hos.net Rumpelmayer's is great..." http://asgard.hos.net/~faulkner -- A. Crowley Book of Lies 1011101 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 0:38:56 2000 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 71C7437B423 for ; Thu, 28 Sep 2000 00:38:48 -0700 (PDT) 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 AAA17924; Thu, 28 Sep 2000 00:38:40 -0700 (PDT) Date: Thu, 28 Sep 2000 00:38:40 -0700 (PDT) From: Julian Elischer To: "Boyd R. Faulkner" Cc: "Peter S. Housel" , freebsd-current@FreeBSD.ORG Subject: Re: Network bridge on current. In-Reply-To: <20000928022230.A967@simon.catburg.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hmmmm, netgraph's bridging code is more direct but it can not do IP filtering on the packets that are en-route. This is because it is a purely MAC-layer service. I am not sure about Luigi's bridging code. I know the dummynet stuff seems to connect with the ipfw code but I don't think that the bridge code does... (I may be wrong) So I don't know how you plan on filtering the bridged segments.. On Thu, 28 Sep 2000, Boyd R. Faulkner wrote: > On Thu, Sep 28, 2000 at 12:11:54AM -0700, Peter S. Housel wrote: > > > I am wondering how to do network bridging on current. The description > > > in the handbook seems to be out of date as the sysctl IODs are no longer > > > in evidence. Does loading ng_bridge substitute for building the kernel > > > with OPTIONS BRIDGE? > > > > Excuse my ignorance (and curiousity), but wouldn't it be cheaper to > > just buy a switch? > > > > Cheers, > > -Peter S. Housel- housel@acm.org http://members.home.com/housel/ > > I intend to use it as a firewall. The switch will live behind it. > > Boyd > > -- > Boyd Faulkner "...but the chocolate at > faulkner@asgard.hos.net Rumpelmayer's is great..." > http://asgard.hos.net/~faulkner -- A. Crowley Book of Lies > 1011101 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 0:50:16 2000 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 87AEF37B422 for ; Thu, 28 Sep 2000 00:50:10 -0700 (PDT) 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 AAA17978 for ; Thu, 28 Sep 2000 00:50:10 -0700 (PDT) Date: Thu, 28 Sep 2000 00:50:10 -0700 (PDT) From: Julian Elischer To: current@freebsd.org Subject: hwptr went backwards.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm presently holding at the "PRE_SMPNG" tag (It's looking stablish now so I may move on soon) however if Imove my (touchpad) mouse (ps2 driver) while the audio system is active, I get a lot of these messages pcm0: hwptr went backwards 708 -> 628 pcm0: hwptr went backwards 1644 -> 1428 pcm0: hwptr went backwards 3176 -> 2936 pcm0: hwptr went backwards 3696 -> 3488 pcm0: hwptr went backwards 3572 -> 3440 pcm0: hwptr went backwards 932 -> 852 etc. I've seen others mention this.. I didn't however see a resolution.. Will I pick up a fix for this when I upgrade? If it is well understood, is there a single file I can pre-patch while leaving the rest of the system at the PRE_SMPNG stage? julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 2:51:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id C2EDA37B422 for ; Thu, 28 Sep 2000 02:51:22 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8S9qcA00717; Thu, 28 Sep 2000 02:52:39 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009280952.e8S9qcA00717@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Takanori Watanabe Cc: Munehiro Matsuda , current@freebsd.org, acpi-jp@jp.freebsd.org Subject: Re: My system hang with ACPI kernel thread In-reply-to: Your message of "Thu, 28 Sep 2000 13:38:57 +0900." <200009280438.NAA63726@shidahara1.planet.sci.kobe-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 02:52:38 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >With the addition of ACPI kernel thread, my system hangs in about > >10 miniutes use after boot up. By disabling kernel thread, system > >runs just fine. > > > >Do you have any idea where to look at? > >I'll try and see what I can do myself. > > Please set debug.aml_debug and debug.acpi_debug to 1 and > see what will happen. It wouldn't surprise me if the system wasn't running out of kernel memory. Right now we just keep mallocing storage to queue ACPI events (bad idea). The entire event/Notify stuff needs to be somewhat rethought (eg. I think we need an event filter). -- ... 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 Sep 28 3:31: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 9E44737B43E for ; Thu, 28 Sep 2000 03:30:50 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8SAUmr80101; Thu, 28 Sep 2000 19:30:48 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: takawata@shidahara1.planet.sci.kobe-u.ac.jp Cc: haro@tk.kubota.co.jp, current@freebsd.org, acpi-jp@jp.freebsd.org Subject: Re: My system hang with ACPI kernel thread In-Reply-To: <200009280438.NAA63726@shidahara1.planet.sci.kobe-u.ac.jp> References: <20000928101721L.haro@tk.kubota.co.jp> <200009280438.NAA63726@shidahara1.planet.sci.kobe-u.ac.jp> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000928193031R.iwasaki@jp.FreeBSD.org> Date: Thu, 28 Sep 2000 19:30:31 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <20000928101721L.haro@tk.kubota.co.jp>, Munehiro Matsuda wrote: > > >With the addition of ACPI kernel thread, my system hangs in about > >10 miniutes use after boot up. By disabling kernel thread, system > >runs just fine. > > > >Do you have any idea where to look at? > >I'll try and see what I can do myself. > > Please set debug.aml_debug and debug.acpi_debug to 1 and > see what will happen. I could find a couple of possibilities from VersaProNX.asl; lack of SleepOp or EC I/O. If the former, I can try to write it as well as StallOp tonight, of course Intel ACPICA compatible one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 3:33:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by hub.freebsd.org (Postfix) with ESMTP id ED8BD37B422; Thu, 28 Sep 2000 03:33:17 -0700 (PDT) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp2.vnet.net (8.10.1/8.10.1) with ESMTP id e8SAX6B26740; Thu, 28 Sep 2000 06:33:06 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id GAA27546; Thu, 28 Sep 2000 06:33:04 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.3/8.6.9) id GAA42518; Thu, 28 Sep 2000 06:33:03 -0400 (EDT) Date: Thu, 28 Sep 2000 06:33:03 -0400 (EDT) From: Thomas David Rivers Message-Id: <200009281033.GAA42518@lakes.dignus.com> To: bright@wintelcom.net, gjohnson@gs.verio.net Subject: Re: interesting problem Cc: freebsd-current@FreeBSD.ORG, grog@lemis.com, kris@FreeBSD.ORG In-Reply-To: <20000927183939.B7553@fw.wintelcom.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > * Tony Johnson [000927 18:26] wrote: > > OK > > Well Here is the issue. If I put in the 2 boot floppies I get a page fault > > 12 after I press Q for "quit" on the visual kernel config. If I can save a > > crash dump before any FS's are mounted or even before I tell FBSD where to > > put the crash dump, I'd really like to know this... I'd like to read a > > handbook page on thisb since some people think I just haven't read it. > > > > At this point in an install, if you could tell me (and the rest of the > > FreeBSD users) where I could get the boot floppies to save a crash dump > > (because I haven't even gotten this far) then I would appreciate this amd be > > more then happy to substantiate this by sending you a crash dump. > > Do you realize how much developer time you're wasting by thrashing > around cluelessly on the list demanding help? > > Here's a clue: > > Forget about your damn irq problem, boot with the disks installed, > then read section of the handbook about crashdumps, compile a debug > kernel and figure out what the problem is. Fix it and send us a > patch. > > Or you could simply run -stable. Alfred, Just playing `devils advocate' here. But, in some initial install situations, exactly how is the user, even the most knowledgeable one, supposed to do much of anything if the install itself doesn't work? Not too much chance of building a kernel, getting a crashdump, etc... Although it may be something we want to put off for awhile, being able to gather debugging information during a failed install would be rather nice. I'm not sure how this could happen; perhaps a crashdump to an MSDOS file system (if available)? Or, straight to a partition with some recovery program that reads the dump? Or, over a serial line? [Just tossing out ideas.] Maybe ficl can get involved and manage this? I would keep this as one of those "maybe nice to have in the ideal future" ideas - but it's something to ponder... - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 7:36:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 30A9A37B423; Thu, 28 Sep 2000 07:36:09 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8SEZqr61033; Thu, 28 Sep 2000 23:35:54 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: msmith@freebsd.org Cc: takawata@shidahara1.planet.sci.kobe-u.ac.jp, haro@tk.kubota.co.jp, current@freebsd.org, acpi-jp@jp.freebsd.org Subject: Re: My system hang with ACPI kernel thread In-Reply-To: <200009280952.e8S9qcA00717@mass.osd.bsdi.com> References: <200009280438.NAA63726@shidahara1.planet.sci.kobe-u.ac.jp> <200009280952.e8S9qcA00717@mass.osd.bsdi.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000928233511G.iwasaki@jp.FreeBSD.org> Date: Thu, 28 Sep 2000 23:35:11 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 13 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Please set debug.aml_debug and debug.acpi_debug to 1 and > > see what will happen. > > It wouldn't surprise me if the system wasn't running out of kernel > memory. Right now we just keep mallocing storage to queue ACPI events > (bad idea). The entire event/Notify stuff needs to be somewhat rethought > (eg. I think we need an event filter). Currently kernel thread seems broken, so mallocing storage in acpi_queue_event() never be freed. I think number of events at a point of tme is limited and we can have static storage for the events. The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd) would be a good example. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 7:39:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 01F5C37B43F for ; Thu, 28 Sep 2000 07:39:26 -0700 (PDT) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id JAA01216; Thu, 28 Sep 2000 09:39:11 -0500 (CDT) (envelope-from dan) Date: Thu, 28 Sep 2000 09:39:11 -0500 From: Dan Nelson To: Julian Elischer Cc: "Boyd R. Faulkner" , "Peter S. Housel" , freebsd-current@FreeBSD.ORG Subject: Re: Network bridge on current. Message-ID: <20000928093910.A24037@dan.emsphone.com> References: <20000928022230.A967@simon.catburg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: ; from "Julian Elischer" on Thu Sep 28 00:38:40 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Sep 28), Julian Elischer said: > On Thu, 28 Sep 2000, Boyd R. Faulkner wrote: > > On Thu, Sep 28, 2000 at 12:11:54AM -0700, Peter S. Housel wrote: > > > On Thu, 28 Sep 2000, Boyd R. Faulkner wrote: > > > > I am wondering how to do network bridging on current. The > > > > description in the handbook seems to be out of date as the > > > > sysctl IODs are no longer in evidence. Does loading ng_bridge > > > > substitute for building the kernel with OPTIONS BRIDGE? > > > > > > Excuse my ignorance (and curiousity), but wouldn't it be cheaper > > > to just buy a switch? > > > > I intend to use it as a firewall. The switch will live behind it. > > I am not sure about Luigi's bridging code. I know the dummynet stuff > seems to connect with the ipfw code but I don't think that the bridge > code does... (I may be wrong) So I don't know how you plan on > filtering the bridged segments.. ipfw definitely supports filtering bridged packets; there's even a "bridge" keyword to match them explicitly. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 7:40:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id E46D737B422 for ; Thu, 28 Sep 2000 07:40:15 -0700 (PDT) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id C81CD1C5C; Thu, 28 Sep 2000 10:40:14 -0400 (EDT) Date: Thu, 28 Sep 2000 10:40:14 -0400 From: Bill Fumerola To: Julian Elischer Cc: "Boyd R. Faulkner" , "Peter S. Housel" , freebsd-current@FreeBSD.ORG Subject: Re: Network bridge on current. Message-ID: <20000928104014.W34501@jade.chc-chimes.com> References: <20000928022230.A967@simon.catburg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from julian@elischer.org on Thu, Sep 28, 2000 at 12:38:40AM -0700 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Sep 28, 2000 at 12:38:40AM -0700, Julian Elischer wrote: > I am not sure about Luigi's bridging code. I know the dummynet stuff > seems to connect with the ipfw code but I don't think that the > bridge code does... (I may be wrong) So I don't know how you plan on > filtering the bridged segments.. You are wrong, but we'll forgive you. :-> from bridge(4): net.link.ether.bridge_ipfw Set to 1 to enable ipfw filtering on bridged packets. Note that ipfw rules only apply to IP packets. from ipfw(8): Each incoming or outgoing packet is passed through the ipfw rules. If host is acting as a gateway, packets forwarded by the gateway are pro- cessed by ipfw twice. In case a host is acting as a bridge, packets for- warded by the bridge are processed by ipfw once. the 'bridged' keyword can be used to match only bridged packets, so: ipfw add allow tcp from any to any 22 setup bridged ipfw add allow tcp from any 22 to any established bridged would allow ssh over a bridge, but in the absence of other rules, wouldn't allow it to the actual machine (or if the machine is also a router(?!) it wouldn't route ssh sessions either.) -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf@chimesnet.com / billf@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 Sep 28 7:42:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 6B65E37B422 for ; Thu, 28 Sep 2000 07:42:21 -0700 (PDT) Received: (from uucp@localhost) by rina.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W-rina.r-0.1-11.01.2000) with UUCP id XAA04553; Thu, 28 Sep 2000 23:42:18 +0900 (JST) Received: (from uucp@localhost) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W) with UUCP id XAA42034; Thu, 28 Sep 2000 23:41:51 +0900 (JST) Received: from bunko.r.dl.itc.u-tokyo.ac.jp.nkth.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by bunko (8.9.3+3.2W/3.7W) with ESMTP/IPv4 id WAA23538; Thu, 28 Sep 2000 22:50:54 +0900 (JST) Message-Id: <200009281350.WAA23538@bunko> Date: Thu, 28 Sep 2000 22:50:53 +0900 From: Seigo Tanimura To: n@nectar.com Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, current@freebsd.org Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior In-Reply-To: In your message of "Sun, 24 Sep 2000 10:08:12 -0500" <20000924100812.A23848@spawn.nectar.com> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20000924100812.A23848@spawn.nectar.com> User-Agent: Wanderlust/1.1.0 (Overjoyed) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 10) (Capitol Reef) (i386--freebsd) Organization: Carrots MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 24 Sep 2000 10:08:12 -0500, "Jacques A. Vidrine" said: n> changing them now. Unless objections come up, I'll commit this change n> or something similar with the next nsswitch commit. Here is another possible trouble. While libc.so.4 with nsswitch no longer requires the magic '+' entry, libc.so.3 and earlier still require '+'. What we need before 5.0-RELEASE meets the world is a tool to find binaries linked against libc.so.3 and earlier, and give a warning. It would also be helpful for us to (semi-)automatically update old binaries installed by ports. (I have been trying this for a couple of days) -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 8: 4:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from adetel.net (mercurio.adetel.net.mx [148.245.223.225]) by hub.freebsd.org (Postfix) with ESMTP id 680DB37B422 for ; Thu, 28 Sep 2000 08:04:40 -0700 (PDT) Received: from sabrina (adetel242-6.adetel.net [200.56.242.6]) by adetel.net (8.9.2/8.9.2) with SMTP id KAA45690 for ; Thu, 28 Sep 2000 10:04:25 -0500 (CDT) (envelope-from alcachofo@demv.net) Message-ID: <000901c0295d$7f4b1be0$06f238c8@sabrina> Reply-To: "Alcachofo Demv" From: "Alcachofo Demv" To: Subject: Date: Thu, 28 Sep 2000 10:05:08 -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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe freebsd-current To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 8:14: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 5794F37B423 for ; Thu, 28 Sep 2000 08:14:00 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA82640; Thu, 28 Sep 2000 11:13:47 -0400 (EDT) (envelope-from wollman) Date: Thu, 28 Sep 2000 11:13:47 -0400 (EDT) From: Garrett Wollman Message-Id: <200009281513.LAA82640@khavrinen.lcs.mit.edu> To: Seigo Tanimura Cc: n@nectar.com, current@FreeBSD.ORG Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior In-Reply-To: <200009281350.WAA23538@bunko> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20000924100812.A23848@spawn.nectar.com> <200009281350.WAA23538@bunko> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > Here is another possible trouble. While libc.so.4 with nsswitch no > longer requires the magic '+' entry, libc.so.3 and earlier still > require '+'. IMHO, This Is A Bug. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 8:27:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from simon.catburg.net (cust-92-32.customer.jump.net [207.8.92.32]) by hub.freebsd.org (Postfix) with ESMTP id 592F637B53A for ; Thu, 28 Sep 2000 08:21:40 -0700 (PDT) Received: (from faulkner@localhost) by simon.catburg.net (8.11.0/8.11.0) id e8SFHnv01849; Thu, 28 Sep 2000 10:17:49 -0500 (CDT) (envelope-from faulkner) Date: Thu, 28 Sep 2000 10:17:49 -0500 From: "Boyd R. Faulkner" To: Bill Fumerola Cc: Julian Elischer , "Boyd R. Faulkner" , "Peter S. Housel" , freebsd-current@FreeBSD.ORG Subject: Re: Network bridge on current. Message-ID: <20000928101749.A1798@simon.catburg.net> References: <20000928022230.A967@simon.catburg.net> <20000928104014.W34501@jade.chc-chimes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20000928104014.W34501@jade.chc-chimes.com>; from billf@chimesnet.com on Thu, Sep 28, 2000 at 10:40:14AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alas, net.link.ether.bridge(_ipfw) are no longer settable via sysctl. That is my main problem. I cannot do what the documentation says. Unfortunately, I cannot even test what I have until tonight as the machine for the other side of the bridge has no video. I stole it, AGP, to replace the PCI card so I would have room for another network card. Thanks again, Boyd On Thu, Sep 28, 2000 at 10:40:14AM -0400, Bill Fumerola wrote: > On Thu, Sep 28, 2000 at 12:38:40AM -0700, Julian Elischer wrote: > > > I am not sure about Luigi's bridging code. I know the dummynet stuff > > seems to connect with the ipfw code but I don't think that the > > bridge code does... (I may be wrong) So I don't know how you plan on > > filtering the bridged segments.. > > You are wrong, but we'll forgive you. :-> > > from bridge(4): > > net.link.ether.bridge_ipfw > > Set to 1 to enable ipfw filtering on bridged packets. Note that ipfw > rules only apply to IP packets. > > from ipfw(8): > > Each incoming or outgoing packet is passed through the ipfw rules. If > host is acting as a gateway, packets forwarded by the gateway are pro- > cessed by ipfw twice. In case a host is acting as a bridge, packets for- > warded by the bridge are processed by ipfw once. > > the 'bridged' keyword can be used to match only bridged packets, so: > > ipfw add allow tcp from any to any 22 setup bridged > ipfw add allow tcp from any 22 to any established bridged > > would allow ssh over a bridge, but in the absence of other rules, wouldn't > allow it to the actual machine (or if the machine is also a router(?!) it > wouldn't route ssh sessions either.) > > -- > Bill Fumerola - Network Architect, BOFH / Chimes, Inc. > billf@chimesnet.com / billf@FreeBSD.org > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message Boyd -- Boyd Faulkner "...but the chocolate at faulkner@asgard.hos.net Rumpelmayer's is great..." http://asgard.hos.net/~faulkner -- A. Crowley Book of Lies 1011101 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 8:29:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 5188137B423 for ; Thu, 28 Sep 2000 08:29:20 -0700 (PDT) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id KAA19502; Thu, 28 Sep 2000 10:24:01 -0500 (CDT) (envelope-from dan) Date: Thu, 28 Sep 2000 10:24:01 -0500 From: Dan Nelson To: Garrett Wollman Cc: Seigo Tanimura , n@nectar.com, current@FreeBSD.ORG Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior Message-ID: <20000928102400.A17446@dan.emsphone.com> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20000924100812.A23848@spawn.nectar.com> <200009281350.WAA23538@bunko> <200009281513.LAA82640@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <200009281513.LAA82640@khavrinen.lcs.mit.edu>; from "Garrett Wollman" on Thu Sep 28 11:13:47 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Sep 28), Garrett Wollman said: > < said: > > Here is another possible trouble. While libc.so.4 with nsswitch no > > longer requires the magic '+' entry, libc.so.3 and earlier still > > require '+'. > > IMHO, This Is A Bug. Depends on what Seigo meant. If he meant that libc.so.4 and no /etc/nsswitch.conf implicitly adds a "+" to the end of /etc/passwd, that's definitely a bug. If he meant that libc.so.4 and an nsswitch.conf of "passwd: files nis" doesn't require a "+", that's fine. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 9:56: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 955D237B424 for ; Thu, 28 Sep 2000 09:55:56 -0700 (PDT) Received: by gw.nectar.com (Postfix, from userid 1001) id 943CF1925D; Thu, 28 Sep 2000 11:55:55 -0500 (CDT) Date: Thu, 28 Sep 2000 11:55:55 -0500 From: "Jacques A. Vidrine" To: Seigo Tanimura Cc: current@freebsd.org Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior Message-ID: <20000928115555.D42464@spawn.nectar.com> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20000924100812.A23848@spawn.nectar.com> <200009281350.WAA23538@bunko> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200009281350.WAA23538@bunko>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Thu, Sep 28, 2000 at 10:50:53PM +0900 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Sep 28, 2000 at 10:50:53PM +0900, Seigo Tanimura wrote: > Here is another possible trouble. While libc.so.4 with nsswitch no > longer requires the magic '+' entry, libc.so.3 and earlier still > require '+'. If one needs to support applications using libc.so.3, then one needs to use the nsswitch compat mode (which is the default). OTOH, I hope to have nsswitch in 4.2-RELEASE. (I do the develoment on 4-STABLE.) > What we need before 5.0-RELEASE meets the world is a tool to find > binaries linked against libc.so.3 and earlier, and give a warning. This would be useful in any case. > It would also be helpful for us to (semi-)automatically update old > binaries installed by ports. (I have been trying this for a couple of > days) Personally I don't want sysinstall or make world to touch my ports. But a tool to do this would be great. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 9:56:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 8B0CC37B423; Thu, 28 Sep 2000 09:55:53 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8SGvEA01338; Thu, 28 Sep 2000 09:57:15 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009281657.e8SGvEA01338@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: msmith@freebsd.org, takawata@shidahara1.planet.sci.kobe-u.ac.jp, haro@tk.kubota.co.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: My system hang with ACPI kernel thread In-reply-to: Your message of "Thu, 28 Sep 2000 23:35:11 +0900." <20000928233511G.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 09:57:14 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Please set debug.aml_debug and debug.acpi_debug to 1 and > > > see what will happen. > > > > It wouldn't surprise me if the system wasn't running out of kernel > > memory. Right now we just keep mallocing storage to queue ACPI events > > (bad idea). The entire event/Notify stuff needs to be somewhat rethought > > (eg. I think we need an event filter). > > Currently kernel thread seems broken, so mallocing storage in > acpi_queue_event() never be freed. I think number of events at a > point of tme is limited and we can have static storage for the events. > The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd) > would be a good example. I have a megapatch for acpi.c that I am nearly ready to commit which converts it to use bus resources for all I/O allocations. I'll fix this in there, if you like. -- ... 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 Sep 28 9:58: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 5B22C37B423 for ; Thu, 28 Sep 2000 09:57:59 -0700 (PDT) Received: by gw.nectar.com (Postfix, from userid 1001) id BF5511925F; Thu, 28 Sep 2000 11:57:58 -0500 (CDT) Date: Thu, 28 Sep 2000 11:57:58 -0500 From: "Jacques A. Vidrine" To: Dan Nelson Cc: Garrett Wollman , Seigo Tanimura , current@FreeBSD.ORG Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior Message-ID: <20000928115758.E42464@spawn.nectar.com> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20000924100812.A23848@spawn.nectar.com> <200009281350.WAA23538@bunko> <200009281513.LAA82640@khavrinen.lcs.mit.edu> <20000928102400.A17446@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000928102400.A17446@dan.emsphone.com>; from dnelson@emsphone.com on Thu, Sep 28, 2000 at 10:24:01AM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Sep 28, 2000 at 10:24:01AM -0500, Dan Nelson wrote: > Depends on what Seigo meant. If he meant that libc.so.4 and no > /etc/nsswitch.conf implicitly adds a "+" to the end of /etc/passwd, > that's definitely a bug. If you don't have an /etc/nsswitch.conf, then it behaves just like libc.so.3, i.e. only the files are consulted, unless you have a '+' entry. > If he meant that libc.so.4 and an nsswitch.conf of "passwd: files nis" > doesn't require a "+", that's fine. And that is how it works if you do have an nsswitch.conf like that. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 10: 6:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from squishycow.goldenterrace.com.au (squishycow.goldenterrace.com.au [203.41.110.130]) by hub.freebsd.org (Postfix) with ESMTP id 4BAEA37B424; Thu, 28 Sep 2000 10:06:43 -0700 (PDT) Received: from roaming.cacheboy.net (unknown [203.41.110.145]) by squishycow.goldenterrace.com.au (Postfix) with ESMTP id DA15319D1A; Fri, 29 Sep 2000 04:06:28 +1100 (EST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id e8S5vmL01766; Thu, 28 Sep 2000 07:57:48 +0200 (CEST) (envelope-from adrian) Date: Thu, 28 Sep 2000 07:57:47 +0200 From: Adrian Chadd To: Bruce Evans Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: Re: Fsck wrappers, revisited Message-ID: <20000928075747.B1740@roaming.cacheboy.net> References: <20000923114434.A4419@roaming.cacheboy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from bde@zeta.org.au on Tue, Sep 26, 2000 at 03:51:51AM +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Sep 26, 2000, Bruce Evans wrote: > > Well, if you have any suggestions, I'm all for it. :-) > > I don't understand the problem. You get the filesystem type name > (fstypename) from fs_vfstype in struct fstab or from f_fstypename in > struct statfs. You attempt to execute strcat("/sbin/fsck_", fstypename) > to see if fsck is supported on filesystems of type fstypename. You don't try to auto-detect and fsck a mounted FS. If its mounted and you are doing it during bootup, it'll generally be in fstab which the current wrapper code looks in. So, the question is: how do you take the raw disk device and figure out which FS type it is, and then which fsck program to run? Adrian -- Adrian Chadd "The main reason Santa is so jolly is because he knows where all the bad girls live." -- Random IRC quote To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 10:19:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 3804E37B424 for ; Thu, 28 Sep 2000 10:19:21 -0700 (PDT) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id AAA61550; Fri, 29 Sep 2000 00:10:39 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Fri, 29 Sep 2000 00:10:39 +0700 (NSS) From: Max Khon To: Dan Nelson Cc: Garrett Wollman , Seigo Tanimura , n@nectar.com, current@FreeBSD.ORG Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior In-Reply-To: <20000928102400.A17446@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, there! On Thu, 28 Sep 2000, Dan Nelson wrote: > > > Here is another possible trouble. While libc.so.4 with nsswitch no > > > longer requires the magic '+' entry, libc.so.3 and earlier still > > > require '+'. > > > > IMHO, This Is A Bug. > > Depends on what Seigo meant. If he meant that libc.so.4 and no > /etc/nsswitch.conf implicitly adds a "+" to the end of /etc/passwd, > that's definitely a bug. If he meant that libc.so.4 and an > nsswitch.conf of "passwd: files nis" doesn't require a "+", that's > fine. "passwd: compat" should require '+' if I understand it correctly /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 10:36:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id B8A8437B424; Thu, 28 Sep 2000 10:36:41 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8SHabr28400; Fri, 29 Sep 2000 02:36:37 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: msmith@freebsd.org Cc: iwasaki@jp.FreeBSD.org, takawata@shidahara1.planet.sci.kobe-u.ac.jp, haro@tk.kubota.co.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: My system hang with ACPI kernel thread In-Reply-To: <200009281657.e8SGvEA01338@mass.osd.bsdi.com> References: <20000928233511G.iwasaki@jp.FreeBSD.org> <200009281657.e8SGvEA01338@mass.osd.bsdi.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000929023628R.iwasaki@jp.FreeBSD.org> Date: Fri, 29 Sep 2000 02:36:28 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 11 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Currently kernel thread seems broken, so mallocing storage in > > acpi_queue_event() never be freed. I think number of events at a > > point of tme is limited and we can have static storage for the events. > > The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd) > > would be a good example. > > I have a megapatch for acpi.c that I am nearly ready to commit which > converts it to use bus resources for all I/O allocations. I'll fix this > in there, if you like. I'm interested in your patch. Can I see it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 10:44:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 5777237B422 for ; Thu, 28 Sep 2000 10:44:13 -0700 (PDT) Received: by gw.nectar.com (Postfix, from userid 1001) id A7B7B1925D; Thu, 28 Sep 2000 12:44:12 -0500 (CDT) Date: Thu, 28 Sep 2000 12:44:12 -0500 From: "Jacques A. Vidrine" To: Max Khon Cc: Dan Nelson , Garrett Wollman , Seigo Tanimura , current@FreeBSD.ORG Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior Message-ID: <20000928124412.F42464@spawn.nectar.com> References: <20000928102400.A17446@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from fjoe@iclub.nsu.ru on Fri, Sep 29, 2000 at 12:10:39AM +0700 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Sep 29, 2000 at 12:10:39AM +0700, Max Khon wrote: > "passwd: compat" should require '+' if I understand it correctly You understand correctly :-) Further, this is the default when there is no /etc/nsswitch.conf. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 11:12:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp.ic.netlaputa.ne.jp (smtp.ic.netlaputa.ne.jp [202.208.214.17]) by hub.freebsd.org (Postfix) with ESMTP id CDAC037B422 for ; Thu, 28 Sep 2000 11:12:37 -0700 (PDT) Received: from aragorn.t-ogawa.trans-nt.co.jp (im4-ppp13.ic.netlaputa.ne.jp [210.158.243.13]) by smtp.ic.netlaputa.ne.jp (8.9.1/8.9-smtp) with ESMTP id DAA01786; Fri, 29 Sep 2000 03:12:03 +0900 (JST) Date: Fri, 29 Sep 2000 03:11:15 +0900 Message-ID: <86snqkidz0.wl.t-ogawa@triaez.kaisei.org> From: Takaya Ogawa To: Julian Elischer Cc: current@freebsd.org Subject: Re: hwptr went backwards.. In-Reply-To: In your message of "Thu, 28 Sep 2000 00:50:10 -0700 (PDT)" References: User-Agent: Wanderlust/2.3.0 (Roam) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 (generated by EMIKO 1.14.0 - "Zoomastigophora") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At Thu, 28 Sep 2000 00:50:10 -0700 (PDT), Julian Elischer wrote: > pcm0: hwptr went backwards 708 -> 628 I've seen this too on my PC running current as of Sep 20. dmesg says: pcm0: port 0xfc8c-0xfc8f,0xfc88-0xfc8b,0xfc30-0xfc3f,0xfc20-0xfc2f,0xfcc0-0xfcff irq 5 at device 11.0 on pci0 > I've seen others mention this.. > I didn't however see a resolution.. > Will I pick up a fix for this when I upgrade? > If it is well understood, is there a single file I can pre-patch > while leaving the rest of the system at the PRE_SMPNG stage? Though I don't realize the code at all, the messages almost, but not completely, went away by the following patch for me. All I did is use cvs diff and see what revision triggered the problem. So this would be a wrong solution... --- channel.c.orig Fri Sep 29 02:56:47 2000 +++ channel.c Fri Sep 29 02:58:13 2000 @@ -241,7 +241,7 @@ chn_checkunderflow(pcm_channel *c) b->fl = b->bufsize - b->rl; b->underflow = 0; } else { - chn_dmaupdate(c); + /* chn_dmaupdate(c); */ } } ---------- Takaya Ogawa t-ogawa@triaez.kaisei.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 11:22:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 69ECB37B424 for ; Thu, 28 Sep 2000 11:18:34 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8SIJhA01660; Thu, 28 Sep 2000 11:19:44 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009281819.e8SIJhA01660@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: takawata@shidahara1.planet.sci.kobe-u.ac.jp, haro@tk.kubota.co.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: My system hang with ACPI kernel thread In-reply-to: Your message of "Fri, 29 Sep 2000 02:36:28 +0900." <20000929023628R.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-2406949460" Date: Thu, 28 Sep 2000 11:19:43 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multipart MIME message. --==_Exmh_-2406949460 Content-Type: text/plain; charset=us-ascii > > > Currently kernel thread seems broken, so mallocing storage in > > > acpi_queue_event() never be freed. I think number of events at a > > > point of tme is limited and we can have static storage for the events. > > > The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd) > > > would be a good example. > > > > I have a megapatch for acpi.c that I am nearly ready to commit which > > converts it to use bus resources for all I/O allocations. I'll fix this > > in there, if you like. > > I'm interested in your patch. Can I see it? Sure. I'm not 100% sure it's going to work right, so please feel free to tell me I've broken something... --==_Exmh_-2406949460 Content-Type: text/plain ; name="acpi.diff"; charset=us-ascii Content-Description: acpi.diff Content-Disposition: attachment; filename="acpi.diff" Index: conf/files =================================================================== RCS file: /host/fs/local0/cvs/src/sys/conf/files,v retrieving revision 1.416 diff -u -r1.416 files --- conf/files 2000/09/23 22:21:39 1.416 +++ conf/files 2000/09/27 10:17:04 @@ -75,7 +75,8 @@ #dev/aac/aac_debug.c optional aac dev/aac/aac_disk.c optional aac dev/aac/aac_pci.c optional aac pci -dev/acpi/acpi.c count acpi +dev/acpi/acpi.c optional acpi +dev/acpi/acpi_io.c optional acpi dev/acpi/acpi_powerres.c optional acpi dev/acpi/aml/aml_amlmem.c optional acpi dev/acpi/aml/aml_common.c optional acpi Index: dev/acpi/acpi.c =================================================================== RCS file: /host/fs/local0/cvs/src/sys/dev/acpi/acpi.c,v retrieving revision 1.14 diff -u -r1.14 acpi.c --- dev/acpi/acpi.c 2000/09/27 05:43:53 1.14 +++ dev/acpi/acpi.c 2000/09/28 17:56:57 @@ -52,7 +52,6 @@ #include #include - #include /* for softc */ #include @@ -63,8 +62,6 @@ #include #include -#include /* for ACPI_BUS_SPACE_IO */ - /* * ACPI pmap subsystem */ @@ -93,8 +90,7 @@ static struct ACPIaddr acpi_addr; struct ACPIrsdp *acpi_rsdp; -static int acpi_port; -static int acpi_irq; +struct FACPbody acpi_init_facp; /* Character device */ @@ -121,31 +117,8 @@ -1 }; -/* - * ACPI register I/O - */ -#define ACPI_REGISTER_INPUT 0 -#define ACPI_REGISTER_OUTPUT 1 -static void acpi_register_input(u_int32_t ioaddr, - u_int32_t *value, u_int32_t size); -static void acpi_register_output(u_int32_t ioaddr, - u_int32_t *value, u_int32_t size); -static void acpi_enable_disable(acpi_softc_t *sc, boolean_t enable); -static void acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io, - u_int32_t *a, u_int32_t *b); -static void acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io, - u_int32_t *a, u_int32_t *b); -static void acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io, - u_int32_t *a, u_int32_t *b); -static void acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val); - /* - * Miscellous utility functions + * Miscellaneous utility functions */ static int acpi_sdt_checksum(struct ACPIsdt * sdt); static void acpi_handle_dsdt(acpi_softc_t *sc); @@ -164,8 +137,7 @@ /* * ACPI events */ -static void acpi_process_event(acpi_softc_t *sc, - u_int32_t status_a, u_int32_t status_b, +static void acpi_process_event(acpi_softc_t *sc, u_int32_t status_e, u_int32_t status_0, u_int32_t status_1); static void acpi_intr(void *data); static void acpi_enable_events(acpi_softc_t *sc); @@ -187,9 +159,9 @@ /* for debugging */ #ifdef ACPI_DEBUG -static int acpi_debug = 1; +int acpi_debug = 1; #else /* !ACPI_DEBUG */ -static int acpi_debug = 0; +int acpi_debug = 0; #endif /* ACPI_DEBUG */ SYSCTL_INT(_debug, OID_AUTO, acpi_debug, CTLFLAG_RW, &acpi_debug, 1, ""); @@ -303,364 +275,8 @@ } /* - * ACPI Register I/O + * Miscellaneous utility functions */ -void -acpi_gpe_enable_bit(acpi_softc_t *sc, u_int32_t bit, boolean_t on_off) -{ - int x; - u_int32_t pos, value; - void (*GPEx_EN[])(acpi_softc_t *, boolean_t, u_int32_t *) = { - acpi_io_gpe0_enable, - acpi_io_gpe0_enable - }; - - x = -1; - pos = bit; - if (bit < sc->facp_body->gpe0_len * 4) { - x = 0; - } else { - /* should we check gpe1_len too? */ - pos = bit - sc->facp_body->gpe1_base; - x = 1; - } - - if (x == -1 || (on_off != 0 && on_off != 1)) { - return; - } - - GPEx_EN[x](sc, ACPI_REGISTER_INPUT, &value); - value = (value & (~(1 << pos))) | (on_off << pos); - GPEx_EN[x](sc, ACPI_REGISTER_OUTPUT, &value); -} - -static __inline void -acpi_register_input(u_int32_t ioaddr, u_int32_t *value, u_int32_t size) -{ - bus_space_tag_t bst; - bus_space_handle_t bsh; - u_int32_t val; - - bst = ACPI_BUS_SPACE_IO; - bsh = ioaddr; - - switch (size) { - case 1: - val = bus_space_read_1(bst, bsh, 0); - break; - case 2: - val = bus_space_read_2(bst, bsh, 0); - break; - case 3: - val = bus_space_read_4(bst, bsh, 0); - val &= 0x00ffffff; - break; - case 4: - val = bus_space_read_4(bst, bsh, 0); - break; - default: - ACPI_DEVPRINTF("acpi_register_input(): invalid size\n"); - val = 0; - break; - } - - *value = val; -} - -static __inline void -acpi_register_output(u_int32_t ioaddr, u_int32_t *value, u_int32_t size) -{ - bus_space_tag_t bst; - bus_space_handle_t bsh; - u_int32_t val; - - val = *value; - bst = ACPI_BUS_SPACE_IO; - bsh = ioaddr; - - switch (size) { - case 1: - bus_space_write_1(bst, bsh, 0, val & 0xff); - break; - case 2: - bus_space_write_2(bst, bsh, 0, val & 0xffff); - break; - case 3: - bus_space_write_2(bst, bsh, 0, val & 0xffff); - bus_space_write_1(bst, bsh, 2, (val >> 16) & 0xff); - break; - case 4: - bus_space_write_4(bst, bsh, 0, val); - break; - default: - ACPI_DEVPRINTF("acpi_register_output(): invalid size\n"); - break; - } -} - -static void -acpi_enable_disable(acpi_softc_t *sc, boolean_t enable) -{ - u_char val; - bus_space_tag_t bst; - bus_space_handle_t bsh; - struct FACPbody *facp; - - facp = sc->facp_body; - bst = ACPI_BUS_SPACE_IO; - bsh = facp->smi_cmd; - - if (enable) { - val = facp->acpi_enable; - } else { - val = facp->acpi_disable; - } - - bus_space_write_1(bst, bsh, 0, val); - sc->enabled = enable; - - ACPI_DEBUGPRINT("acpi_enable_disable(%d) = (%x)\n", enable, val); -} - -static void -acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *status_a, - u_int32_t *status_b) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->pm1_evt_len / 2; - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm1a_evt_blk, status_a, size); - - *status_b = 0; - if (facp->pm1b_evt_blk) { - acpi_register_input(facp->pm1b_evt_blk, status_b, size); - } - } else { - acpi_register_output(facp->pm1a_evt_blk, status_a, size); - - if (facp->pm1b_evt_blk) { - acpi_register_output(facp->pm1b_evt_blk, status_b, size); - } - } - - ACPI_DEBUGPRINT("acpi_io_pm1_status(%d) = (%x, %x)\n", - io, *status_a, *status_b); - - return; -} - -static void -acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *status_a, - u_int32_t *status_b) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->pm1_evt_len / 2; - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm1a_evt_blk + size, status_a, size); - - *status_b = 0; - if (facp->pm1b_evt_blk) { - acpi_register_input(facp->pm1b_evt_blk + size, - status_b, size); - } - } else { - acpi_register_output(facp->pm1a_evt_blk + size, status_a, size); - - if (facp->pm1b_evt_blk) { - acpi_register_output(facp->pm1b_evt_blk + size, - status_b, size); - } - } - - ACPI_DEBUGPRINT("acpi_io_pm1_enable(%d) = (%x, %x)\n", - io, *status_a, *status_b); - - return; -} - -static void -acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io, u_int32_t *value_a, - u_int32_t *value_b) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->pm1_cnt_len; - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm1a_cnt_blk, value_a, size); - - *value_b = 0; - if (facp->pm1b_evt_blk) { - acpi_register_input(facp->pm1b_cnt_blk, value_b, size); - } - } else { - acpi_register_output(facp->pm1a_cnt_blk, value_a, size); - - if (facp->pm1b_evt_blk) { - acpi_register_output(facp->pm1b_cnt_blk, value_b, size); - } - } - - ACPI_DEBUGPRINT("acpi_io_pm1_control(%d) = (%x, %x)\n", - io, *value_a, *value_b); - - return; -} - -static void -acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->pm2_cnt_len; - - if (!facp->pm2_cnt_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm2_cnt_blk, val, size); - } else { - acpi_register_output(facp->pm2_cnt_blk, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_pm2_control(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = 0x4; /* 32-bits */ - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm_tmr_blk, val, size); - } else { - return; /* XXX read-only */ - } - - ACPI_DEBUGPRINT("acpi_io_pm_timer(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->gpe0_len / 2; - - if (!facp->gpe0_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->gpe0_blk, val, size); - } else { - acpi_register_output(facp->gpe0_blk, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_gpe0_status(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->gpe0_len / 2; - - if (!facp->gpe0_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->gpe0_blk + size, val, size); - } else { - acpi_register_output(facp->gpe0_blk + size, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_gpe0_enable(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->gpe1_len / 2; - - if (!facp->gpe1_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->gpe1_blk, val, size); - } else { - acpi_register_output(facp->gpe1_blk, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_gpe1_status(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->gpe1_len / 2; - - if (!facp->gpe1_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->gpe1_blk + size, val, size); - } else { - acpi_register_output(facp->gpe1_blk + size, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_gpe1_enable(%d) = (%x)\n", io, *val); - - return; -} - -/* - * Miscellous utility functions - */ - static int acpi_sdt_checksum(struct ACPIsdt *sdt) { @@ -785,8 +401,7 @@ /* in discovery mode, we have everything we need now */ if (sc == NULL) { - acpi_port = body->smi_cmd; - acpi_irq = body->sci_int; + bcopy(body, &acpi_init_facp, sizeof(*body)); return; } @@ -887,18 +502,16 @@ if (state > ACPI_S_STATE_S0) { /* clear WAK_STS bit by writing a one */ - acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &val_a, &val_b); - if ((val_a | val_b) & ACPI_PM1_WAK_STS) { + acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &val_a); + if (val_a & ACPI_PM1_WAK_STS) { sc->broken_wakeuplogic = 0; } else { ACPI_DEVPRINTF("wake-up logic seems broken, " "this may cause troubles on wakeup\n"); sc->broken_wakeuplogic = 1; } - val_a = val_b = 0; val_a = ACPI_PM1_WAK_STS; - val_b = ACPI_PM1_WAK_STS; - acpi_io_pm1_status(sc, ACPI_REGISTER_OUTPUT, &val_a, &val_b); + acpi_io_pm1_status(sc, ACPI_REGISTER_OUTPUT, &val_a); /* ignore power button and sleep button events for 5 sec. */ sc->ignore_events = ACPI_PM1_PWRBTN_EN | ACPI_PM1_SLPBTN_EN; @@ -926,8 +539,8 @@ count = 0; for (;;) { - acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &val_a, &val_b); - if ((val_a | val_b) & ACPI_PM1_WAK_STS) { + acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &val_a); + if (val_a & ACPI_PM1_WAK_STS) { break; } /* XXX @@ -1072,12 +685,12 @@ */ static void -acpi_process_event(acpi_softc_t *sc, u_int32_t status_a, u_int32_t status_b, +acpi_process_event(acpi_softc_t *sc, u_int32_t status_e, u_int32_t status_0, u_int32_t status_1) { int i; - if (status_a & ACPI_PM1_PWRBTN_EN || status_b & ACPI_PM1_PWRBTN_EN) { + if (status_e & ACPI_PM1_PWRBTN_EN) { if (sc->ignore_events & ACPI_PM1_PWRBTN_EN) { ACPI_DEBUGPRINT("PWRBTN event ingnored\n"); } else { @@ -1094,7 +707,7 @@ } } - if (status_a & ACPI_PM1_SLPBTN_EN || status_b & ACPI_PM1_SLPBTN_EN) { + if (status_e & ACPI_PM1_SLPBTN_EN) { if (sc->ignore_events & ACPI_PM1_SLPBTN_EN) { ACPI_DEBUGPRINT("SLPBTN event ingnored\n"); } else { @@ -1117,9 +730,9 @@ static void acpi_intr(void *data) { - u_int32_t enable_a, enable_b, enable_0, enable_1; - u_int32_t status_a, status_b, status_0, status_1; - u_int32_t val_a, val_b; + u_int32_t enable; + u_int32_t status_e, status_0, status_1; + u_int32_t val; int debug; acpi_softc_t *sc; @@ -1130,35 +743,32 @@ /* * Power Management 1 Status Registers */ - status_a = status_b = enable_a = enable_b = 0; - acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); + status_e = enable = 0; + acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &status_e); /* * Get current interrupt mask */ - acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &enable_a, &enable_b); + acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &enable); /* * Disable events and re-enable again */ - if ((status_a & enable_a) != 0 || (status_b & enable_b) != 0) { + if ((status_e & enable) != 0) { acpi_debug = debug; /* OK, you can speak */ ACPI_DEBUGPRINT("pm1_status intr CALLED\n"); /* Disable all interrupt generation */ - val_a = enable_a & (~ACPI_PM1_ALL_ENABLE_BITS); - val_b = enable_b & (~ACPI_PM1_ALL_ENABLE_BITS); - acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &val_a, &val_b); + val = enable & (~ACPI_PM1_ALL_ENABLE_BITS); + acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &val); /* Clear interrupt status */ - val_a = enable_a & ACPI_PM1_ALL_ENABLE_BITS; - val_b = enable_b & ACPI_PM1_ALL_ENABLE_BITS; - acpi_io_pm1_status(sc, ACPI_REGISTER_OUTPUT, &val_a, &val_b); + val = enable & ACPI_PM1_ALL_ENABLE_BITS; + acpi_io_pm1_status(sc, ACPI_REGISTER_OUTPUT, &val); /* Re-enable interrupt */ - acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, - &enable_a, &enable_b); + acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &enable); acpi_debug = 0; /* Shut up again */ } @@ -1166,36 +776,36 @@ /* * General-Purpose Events 0 Status Registers */ - status_0 = enable_0 = 0; + status_0 = enable = 0; acpi_io_gpe0_status(sc, ACPI_REGISTER_INPUT, &status_0); /* * Get current interrupt mask */ - acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &enable_0); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &enable); /* * Disable events and re-enable again */ - if ((status_0 & enable_0) != 0) { + if ((status_0 & enable) != 0) { acpi_debug = debug; /* OK, you can speak */ ACPI_DEBUGPRINT("gpe0_status intr CALLED\n"); /* Disable all interrupt generation */ - val_a = enable_0 & ~status_0; + val = enable & ~status_0; #if 0 /* or should we disable all? */ - val_a = 0x0; + val = 0x0; #endif - acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &val_a); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &val); #if 0 /* Clear interrupt status */ - val_a = enable_0; /* XXX */ - acpi_io_gpe0_status(sc, ACPI_REGISTER_OUTPUT, &val_a); + val = enable; /* XXX */ + acpi_io_gpe0_status(sc, ACPI_REGISTER_OUTPUT, &val); /* Re-enable interrupt */ - acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &enable_0); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &enable); acpi_debug = 0; /* Shut up again */ #endif @@ -1204,36 +814,36 @@ /* * General-Purpose Events 1 Status Registers */ - status_1 = enable_1 = 0; + status_1 = enable = 0; acpi_io_gpe1_status(sc, ACPI_REGISTER_INPUT, &status_1); /* Get current interrupt mask */ - acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &enable_1); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &enable); /* * Disable events and re-enable again */ - if ((status_1 & enable_1) != 0) { + if ((status_1 & enable) != 0) { acpi_debug = debug; /* OK, you can speak */ ACPI_DEBUGPRINT("gpe1_status intr CALLED\n"); /* Disable all interrupt generation */ - val_a = enable_1 & ~status_1; + val = enable & ~status_1; #if 0 /* or should we disable all? */ - val_a = 0x0; + val = 0x0; #endif - acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &val_a); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &val); /* Clear interrupt status */ - val_a = enable_1; /* XXX */ - acpi_io_gpe1_status(sc, ACPI_REGISTER_OUTPUT, &val_a); + val = enable; /* XXX */ + acpi_io_gpe1_status(sc, ACPI_REGISTER_OUTPUT, &val); /* Re-enable interrupt */ - acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &enable_1); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &enable); acpi_debug = 0; /* Shut up again */ } @@ -1241,7 +851,7 @@ acpi_debug = debug; /* Restore debug level */ /* do something to handle the events... */ - acpi_process_event(sc, status_a, status_b, status_0, status_1); + acpi_process_event(sc, status_e, status_0, status_1); } static int acpi_set_gpe_bits(struct aml_name *name, va_list ap) @@ -1270,24 +880,23 @@ static void acpi_enable_events(acpi_softc_t *sc) { - u_int32_t status_a, status_b; + u_int32_t status; + u_int32_t mask0, mask1; u_int32_t flags; /* * Setup PM1 Enable Registers Fixed Feature Enable Bits (4.7.3.1.2) * based on flags field of Fixed ACPI Description Table (5.2.5). */ - acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); + acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &status); flags = sc->facp_body->flags; if ((flags & ACPI_FACP_FLAG_PWR_BUTTON) == 0) { - status_a |= ACPI_PM1_PWRBTN_EN; - status_b |= ACPI_PM1_PWRBTN_EN; + status |= ACPI_PM1_PWRBTN_EN; } if ((flags & ACPI_FACP_FLAG_SLP_BUTTON) == 0) { - status_a |= ACPI_PM1_SLPBTN_EN; - status_b |= ACPI_PM1_SLPBTN_EN; + status |= ACPI_PM1_SLPBTN_EN; } - acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &status_a, &status_b); + acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &status); #if 1 /* @@ -1296,26 +905,26 @@ * \_GPE scope (4.7.2.2.1.2). */ - status_a = status_b = 0; + mask0 = mask1 = 0; aml_apply_foreach_found_objects(NULL, "\\_GPE._L", acpi_set_gpe_bits, - sc, &status_a, &status_b); - sc->gpe0_mask = status_a; - sc->gpe1_mask = status_b; + sc, &mask0, &mask1); /* XXX correct? */ + sc->gpe0_mask = mask0; + sc->gpe1_mask = mask1; - acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &status_a); - acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &status_b); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &mask0); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &mask1); #endif /* print all event status for debugging */ - acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); - acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); - acpi_io_gpe0_status(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_gpe1_status(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_pm1_control(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); - acpi_io_pm2_control(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_pm_timer(sc, ACPI_REGISTER_INPUT, &status_a); + acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_gpe0_status(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_gpe1_status(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_pm1_control(sc, ACPI_REGISTER_INPUT, &mask0, &mask1); + acpi_io_pm2_control(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_pm_timer(sc, ACPI_REGISTER_INPUT, &status); } static void @@ -1451,10 +1060,58 @@ device_printf(parent, "could not attach ACPI\n"); return; } - if (acpi_port != 0) - bus_set_resource(child, SYS_RES_IOPORT, 0, acpi_port, 1); - if (acpi_irq != 0) - bus_set_resource(child, SYS_RES_IRQ, 0, acpi_irq, 1); + + /* + * SMI command register + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_SMI_CMD, + acpi_init_facp.smi_cmd, 1); + + /* + * PM1 event registers + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM1A_EVT, + acpi_init_facp.pm1a_evt_blk, acpi_init_facp.pm1_evt_len); + if (acpi_init_facp.pm1b_evt_blk != 0) + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM1B_EVT, + acpi_init_facp.pm1b_evt_blk, acpi_init_facp.pm1_evt_len); + + /* + * PM1 control registers + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM1A_CNT, + acpi_init_facp.pm1a_cnt_blk, acpi_init_facp.pm1_cnt_len); + if (acpi_init_facp.pm1b_cnt_blk != 0) + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM1B_CNT, + acpi_init_facp.pm1b_cnt_blk, acpi_init_facp.pm1_cnt_len); + + /* + * PM2 control register + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM2_CNT, + acpi_init_facp.pm2_cnt_blk, acpi_init_facp.pm2_cnt_len); + + /* + * PM timer register + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM_TMR, + acpi_init_facp.pm_tmr_blk, 4); + + /* + * General purpose event registers + */ + if (acpi_init_facp.gpe0_blk != 0) + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_GPE0, + acpi_init_facp.gpe0_blk, acpi_init_facp.gpe0_len); + if (acpi_init_facp.gpe1_blk != 0) + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_GPE1, + acpi_init_facp.gpe1_blk, acpi_init_facp.gpe1_len); + + /* + * Notification interrupt + */ + if (acpi_init_facp.sci_int != 0) + bus_set_resource(child, SYS_RES_IRQ, 0, acpi_init_facp.sci_int, 1); } static int @@ -1485,6 +1142,7 @@ acpi_attach(device_t dev) { acpi_softc_t *sc; + int i; /* * Set up the softc and parse the ACPI data completely. @@ -1498,12 +1156,16 @@ /* * Allocate our resources */ - sc->port_rid = 0; - if ((sc->port = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, - 0, ~0, 1, RF_ACTIVE)) == NULL) { - ACPI_DEVPRINTF("could not allocate port\n"); - acpi_free(sc); - return(ENOMEM); + for (i = 0; i < ACPI_RES_MAX; i++) { + sc->iores[i].rid = i; + sc->iores[i].rsc = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->iores[i].rid, + 0, ~0, 1, RF_ACTIVE); + if (sc->iores[i].rsc != NULL) { + sc->iores[i].bhandle = rman_get_bushandle(sc->iores[i].rsc); + sc->iores[i].btag = rman_get_bustag(sc->iores[i].rsc); + } else { + /* XXX barf on mandatory resources missing */ + } } sc->irq_rid = 0; if ((sc->irq = bus_alloc_resource(dev, SYS_RES_IRQ, &sc->irq_rid, @@ -1564,8 +1226,16 @@ static void acpi_free(struct acpi_softc *sc) { - if (sc->port != NULL) - bus_release_resource(sc->dev, SYS_RES_IOPORT, sc->port_rid, sc->port); + int i; + + for (i = 0; i < ACPI_RES_MAX; i++) { + if (sc->iores[i].rsc != NULL) { + bus_release_resource(sc->dev, + SYS_RES_IOPORT, + sc->iores[i].rid, + sc->iores[1].rsc); + } + } if (sc->irq_handle != NULL) bus_teardown_intr(sc->dev, sc->irq, sc->irq_handle); if (sc->irq != NULL) Index: dev/acpi/acpi.h =================================================================== RCS file: /host/fs/local0/cvs/src/sys/dev/acpi/acpi.h,v retrieving revision 1.10 diff -u -r1.10 acpi.h --- dev/acpi/acpi.h 2000/09/27 05:43:54 1.10 +++ dev/acpi/acpi.h 2000/09/28 17:57:49 @@ -92,15 +92,37 @@ int ae_arg; }; +/* + * I/O resource structure + */ + +#define ACPI_RES_SMI_CMD 0 +#define ACPI_RES_PM1A_EVT 1 +#define ACPI_RES_PM1B_EVT 2 +#define ACPI_RES_PM1A_CNT 3 +#define ACPI_RES_PM1B_CNT 4 +#define ACPI_RES_PM2_CNT 5 +#define ACPI_RES_PM_TMR 6 +#define ACPI_RES_GPE0 7 +#define ACPI_RES_GPE1 8 +#define ACPI_RES_MAX 9 + +struct acpi_io_resource { + struct resource *rsc; + int rid; + bus_space_handle_t bhandle; + bus_space_tag_t btag; +}; + /* * Softc -*/ + */ typedef struct acpi_softc { device_t dev; dev_t dev_t; + + struct acpi_io_resource iores[ACPI_RES_MAX]; - struct resource *port; - int port_rid; struct resource *irq; int irq_rid; void *irq_handle; @@ -126,6 +148,23 @@ } acpi_softc_t; /* + * ACPI register I/O + */ +#define ACPI_REGISTER_INPUT 0 +#define ACPI_REGISTER_OUTPUT 1 +extern void acpi_enable_disable(acpi_softc_t *sc, boolean_t enable); +extern void acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *status); +extern void acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *enable); +extern void acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val_a, u_int32_t *val_b); +extern void acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val); + + +/* * Device State */ extern u_int8_t acpi_get_current_device_state(struct aml_name *name); @@ -147,7 +186,7 @@ /* * GPE enable bit manipulation */ -extern void acpi_gpe_enable_bit(acpi_softc_t *, u_int32_t, boolean_t); +extern void acpi_gpe_enable_bit(acpi_softc_t *sc, u_int32_t bit, boolean_t on_off); /* * Event queue @@ -164,3 +203,5 @@ #define ACPI_DEBUGPRINT(args...) do { if (acpi_debug) ACPI_DEVPRINTF(args);} while(0) #endif /* !_DEV_ACPI_ACPI_H_ */ + + Index: dev/acpi/acpi_io.c =================================================================== RCS file: acpi_io.c diff -N acpi_io.c --- /dev/null Thu Sep 28 10:32:34 2000 +++ acpi_io.c Wed Sep 27 04:15:36 2000 @@ -0,0 +1,358 @@ +/*- + * Copyright (c) 1999 Takanori Watanabe + * Copyright (c) 1999, 2000 Mitsuru IWASAKI + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $Id: acpi.c,v 1.26 2000/08/15 14:43:43 iwasaki Exp $ + * $FreeBSD: src/sys/dev/acpi/acpi.c,v 1.13 2000/09/27 01:40:47 msmith Exp $ + */ + +#include "opt_acpi.h" +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include /* for EVENTHANDLER_REGISTER */ +#include /* for RB_POWEROFF */ +#include /* for DELAY */ +#include /* for RFSTOPPED*/ +#include /* for kthread stuff*/ +#include + +#include +#include +#include + +#include +#include /* for softc */ + +/* + * ACPI Register I/O + */ +static __inline void +acpi_register_input(acpi_softc_t *sc, int res, int offset, u_int32_t *value, u_int32_t size) +{ + bus_space_tag_t bst; + bus_space_handle_t bsh; + u_int32_t val; + + if (sc->iores[res].rsc == NULL) + return; + + bst = sc->iores[res].btag; + bsh = sc->iores[res].bhandle; + + switch (size) { + case 1: + val = bus_space_read_1(bst, bsh, offset); + break; + case 2: + val = bus_space_read_2(bst, bsh, offset); + break; + case 3: + val = bus_space_read_4(bst, bsh, offset); + val &= 0x00ffffff; + break; + case 4: + val = bus_space_read_4(bst, bsh, offset); + break; + default: + ACPI_DEVPRINTF("acpi_register_input(): invalid size\n"); + val = 0; + break; + } + + *value = val; +} + +static __inline void +acpi_register_output(acpi_softc_t *sc, int res, int offset, u_int32_t *value, u_int32_t size) +{ + bus_space_tag_t bst; + bus_space_handle_t bsh; + u_int32_t val; + + if (sc->iores[res].rsc == NULL) + return; + + val = *value; + bst = sc->iores[res].btag; + bsh = sc->iores[res].bhandle; + + switch (size) { + case 1: + bus_space_write_1(bst, bsh, offset, val & 0xff); + break; + case 2: + bus_space_write_2(bst, bsh, offset, val & 0xffff); + break; + case 3: + bus_space_write_2(bst, bsh, offset, val & 0xffff); + bus_space_write_1(bst, bsh, offset + 2, (val >> 16) & 0xff); + break; + case 4: + bus_space_write_4(bst, bsh, offset, val); + break; + default: + ACPI_DEVPRINTF("acpi_register_output(): invalid size\n"); + break; + } +} + +static __inline void +acpi_io_mirreg(acpi_softc_t *sc, boolean_t io, u_int32_t *data, + int res, int altres, int offset, int size) +{ + u_int32_t result; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, res, offset, &result, size); + *data = result; + acpi_register_input(sc, altres, offset, &result, size); + *data |= result; + } else { + acpi_register_output(sc, res, offset, data, size); + acpi_register_output(sc, altres, offset, data, size); + } + + return; +} + +void +acpi_enable_disable(acpi_softc_t *sc, boolean_t enable) +{ + u_int8_t val; + + val = enable ? sc->facp_body->acpi_enable : sc->facp_body->acpi_disable; + bus_space_write_1(sc->iores[ACPI_RES_SMI_CMD].btag, + sc->iores[ACPI_RES_SMI_CMD].bhandle, + 0, val); + sc->enabled = enable; + + ACPI_DEBUGPRINT("acpi_enable_disable(%d) = (%x)\n", enable, val); +} + +void +acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *status) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->pm1_evt_len / 2; + acpi_io_mirreg(sc, io, status, ACPI_RES_PM1A_EVT, ACPI_RES_PM1B_EVT, 0, size); + + ACPI_DEBUGPRINT("acpi_io_pm1_status(%d) = (%x)\n", io, *status); +} + +void +acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *enable) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->pm1_evt_len / 2; + acpi_io_mirreg(sc, io, enable, ACPI_RES_PM1A_EVT, ACPI_RES_PM1B_EVT, size, size); + + ACPI_DEBUGPRINT("acpi_io_pm1_enable(%d) = (%x)\n", io, *enable); +} + +/* + * PM1 is awkward because the SLP_TYP bits are not common between the two registers. + * A better interface than this might pass the SLP_TYP bits separately. + */ +void +acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io, u_int32_t *value_a, u_int32_t *value_b) +{ + struct FACPbody *facp; + u_int32_t result; + + facp = sc->facp_body; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_PM1A_CNT, 0, &result, facp->pm1_cnt_len); + *value_a = result; + acpi_register_input(sc, ACPI_RES_PM1B_CNT, 0, &result, facp->pm1_cnt_len); + *value_a |= result; + *value_a &= ~ACPI_CNT_SLP_TYPX; /* mask the SLP_TYP bits */ + } else { + acpi_register_output(sc, ACPI_RES_PM1A_CNT, 0, value_a, facp->pm1_cnt_len); + acpi_register_output(sc, ACPI_RES_PM1B_CNT, 0, value_b, facp->pm1_cnt_len); + } + + ACPI_DEBUGPRINT("acpi_io_pm1_control(%d) = (%x, %x)\n", io, *value_a, *value_b); +} + +void +acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->pm2_cnt_len; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_PM2_CNT, 0, val, size); + } else { + acpi_register_output(sc, ACPI_RES_PM2_CNT, 0, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_pm2_control(%d) = (%x)\n", io, *val); + + return; +} + +void +acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_PM_TMR, 0, val, sizeof(u_int32_t)); + + ACPI_DEBUGPRINT("acpi_io_pm_timer(%d) = (%x)\n", io, *val); + } +} + +void +acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->gpe0_len / 2; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_GPE0, 0, val, size); + } else { + acpi_register_output(sc, ACPI_RES_GPE0, 0, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_gpe0_status(%d) = (%x)\n", io, *val); +} + +void +acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->gpe0_len / 2; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_GPE0, size, val, size); + } else { + acpi_register_output(sc, ACPI_RES_GPE0, size, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_gpe0_enable(%d) = (%x)\n", io, *val); +} + +void +acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->gpe1_len / 2; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_GPE1, 0, val, size); + } else { + acpi_register_output(sc, ACPI_RES_GPE1, 0, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_gpe1_status(%d) = (%x)\n", io, *val); +} + +void +acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->gpe1_len / 2; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_GPE1, size, val, size); + } else { + acpi_register_output(sc, ACPI_RES_GPE1, size, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_gpe0_enable(%d) = (%x)\n", io, *val); +} + +void +acpi_gpe_enable_bit(acpi_softc_t *sc, u_int32_t bit, boolean_t on_off) +{ + u_int32_t value; + int res; + + /* + * Is the bit in the first GPE port? + */ + if (bit < ((sc->facp_body->gpe0_len / 2) * 8)) { + res = ACPI_RES_GPE0; + } else { + /* + * Is the bit in the second GPE port? + */ + bit -= sc->facp_body->gpe1_base; + if (bit < ((sc->facp_body->gpe1_len / 2) * 8)) { + res = ACPI_RES_GPE1; + } else { + return; /* do nothing */ + } + } + + switch (res) { + case ACPI_RES_GPE0: + acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &value); + break; + case ACPI_RES_GPE1: + acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &value); + break; + } + value = (value & ~(1 << bit)) | (on_off ? (1 << bit) : 0); + switch (res) { + case ACPI_RES_GPE0: + acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &value); + break; + case ACPI_RES_GPE1: + acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &value); + break; + } +} + Index: dev/acpi/acpi_powerres.c =================================================================== RCS file: /host/fs/local0/cvs/src/sys/dev/acpi/acpi_powerres.c,v retrieving revision 1.7 diff -u -r1.7 acpi_powerres.c --- dev/acpi/acpi_powerres.c 2000/09/27 05:43:54 1.7 +++ dev/acpi/acpi_powerres.c 2000/09/28 17:37:02 @@ -33,8 +33,11 @@ #include #include -#include +#include +#include +#include +#include #include #include --==_Exmh_-2406949460 Content-Type: text/plain; charset=us-ascii ... 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 --==_Exmh_-2406949460-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 11:37:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailhotel.chrillesen.dk (vax.chrillesen.dk [193.88.12.35]) by hub.freebsd.org (Postfix) with ESMTP id 4266437B43E for ; Thu, 28 Sep 2000 11:37:26 -0700 (PDT) Received: by mailhotel.chrillesen.dk (Postfix, from userid 1009) id D53DC5D08; Thu, 28 Sep 2000 20:37:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailhotel.chrillesen.dk (Postfix) with ESMTP id C683F1F20 for ; Thu, 28 Sep 2000 20:37:22 +0200 (CEST) Date: Thu, 28 Sep 2000 20:37:22 +0200 (CEST) From: Anonymous Coward X-Sender: barry@vax.chrillesen.dk Reply-To: freebsd-haX0rs@netscum.dk To: current@freebsd.org Subject: No kezboard with any -current snap floppies... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Howdy. I tried booting from a pair of kern/mfsroot floppies downloaded from current.freebsd.org, and no go. the kbd attach fails with 6. This also happens with grabbing the most current pair of floppies from today, as well as the beginning of Aug floppies, so this seems to be b0rken for quite some time, spanning the range of available snaps. This is on an HP NetSwerver LPr, and I had no problems with a pair of NetBSD floppies on the same hardware. Anyone else sees this, or do I need to copy down some info before the boot dmesg disappears? Be happy to do this if nobody sees the same thing. Otherwise, I'll probably try some different hardware just to get something happening... thanks barry bouwsma, all-purpose nobody (reply-to is valid) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 12: 8:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from goku.cl.msu.edu (goku.cl.msu.edu [35.8.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 9426D37B424 for ; Thu, 28 Sep 2000 12:08:40 -0700 (PDT) Received: (from dervish@localhost) by goku.cl.msu.edu (8.11.0/8.11.0) id e8SJ8Zw64324 for freebsd-current@FreeBSD.ORG; Thu, 28 Sep 2000 15:08:35 -0400 (EDT) (envelope-from dervish) Date: Thu, 28 Sep 2000 15:08:35 -0400 From: Bush Doctor To: freebsd-current@FreeBSD.ORG Subject: Re: -Current + X 4.0.1 = mouse problems Message-ID: <20000928150835.A57700@goku.cl.msu.edu> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <20000923205043.A63108@rucus.ru.ac.za> <39CD3291.2A00C204@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <39CD3291.2A00C204@gorean.org>; from DougB@gorean.org on Sat, Sep 23, 2000 at 03:45:37PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT i386 WWW-Home-Page: http://bantu.cl.msu.edu Organisation: Information Systems - Michigan State University Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Out of da blue Doug Barton aka (DougB@gorean.org) said: > David Siebörger wrote: > > > I've experienced the (apparently common) problem of switching from X > > to console and back to X and getting an unresponsive mouse pointer in > > X. This occurs when I use protocol "Auto", or don't specify a > > protocol. > > Someone was kind enough to send me the attached patch. With > > Option "Protocol" "Auto" > Option "Device" "/dev/sysmouse" > > it works with moused. I tried protocol sysmouse, but it didn't work. > Neither did Christian's advice about the mousesystems protocol. I also > have a wheeled mouse, logitech specifically. I too am experiencing problem. I have a logitech serial wheel mouse. However X will only fire up if I tell it to ignore the "cannot open input device" for my Mouse1 identifier :(. I'll try this patch and see what happens. > > It would be nice to include this patch in our X4 port. > > Doug > -- > "The dead cannot be seduced." > - Kai, "Lexx" > > Do YOU Yahoo!? > --- programs/Xserver/hw/xfree86/input/mouse/mouse.c.orig Sun Jul 23 17:50:10 2000 > +++ programs/Xserver/hw/xfree86/input/mouse/mouse.c Sun Jul 23 17:54:22 2000 > @@ -692,10 +692,15 @@ > pMse->protocolID = protocolID; > } > } > +#ifndef __FreeBSD__ > memcpy(pMse->protoPara, proto[pMse->protocolID], sizeof(pMse->protoPara)); > +#endif > if (automatic) { > > if (name) { > +#ifdef __FreeBSD__ > + memcpy(pMse->protoPara, proto[pMse->protocolID], sizeof(pMse->protoPara)); > +#endif > /* Possible protoPara overrides from SetupAuto. */ > for (i = 0; i < sizeof(pMse->protoPara); i++) > if (protoPara[i] != -1) > --- programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.c.orig Sat Feb 12 22:45:41 2000 > +++ programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.c Sun Jul 23 17:50:10 2000 > @@ -165,7 +165,11 @@ > mode.rate = rate > 0 ? rate : -1; > mode.resolution = res > 0 ? res : -1; > mode.accelfactor = -1; > +#ifdef __FreeBSD__ > + mode.level = 1; > +#else > mode.level = -1; > +#endif > ioctl(pInfo->fd, MOUSE_SETMODE, &mode); > } > #endif > #:^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 12:11:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailhotel.chrillesen.dk (vax.chrillesen.dk [193.88.12.35]) by hub.freebsd.org (Postfix) with ESMTP id AD4C937B422 for ; Thu, 28 Sep 2000 12:11:32 -0700 (PDT) Received: by mailhotel.chrillesen.dk (Postfix, from userid 1009) id 2450A5D08; Thu, 28 Sep 2000 21:11:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailhotel.chrillesen.dk (Postfix) with ESMTP id 15B651F20 for ; Thu, 28 Sep 2000 21:11:31 +0200 (CEST) Date: Thu, 28 Sep 2000 21:11:31 +0200 (CEST) From: Anonymous Coward X-Sender: barry@vax.chrillesen.dk Reply-To: freebsd-haX0rs@netscum.dk To: current@freebsd.org Subject: Re: No kezboard with any -current snap floppies... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2585 Sep 1993 barry@fluffy.gets.an.analprobe.dk wrote: > I tried booting from a pair of kern/mfsroot floppies downloaded from > current.freebsd.org, and no go. the kbd attach fails with 6. This What is more, now that I've had success on some other hardware, is that what I thought was a New Feature is probably related, if not the reason. On the NetSwerver, it totally skips the kernel config screen that I expected to see and that turns out to be there after all, well before the attempt to attach the kezboard. If needed, I'll provide more info... > barry bouwsma, all-purpose nobody (reply-to is valid) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 12:35:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 046DF37B42C for ; Thu, 28 Sep 2000 12:34:12 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8SJY4r44407; Fri, 29 Sep 2000 04:34:04 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: iwasaki@jp.freebsd.org Cc: takawata@shidahara1.planet.sci.kobe-u.ac.jp, haro@tk.kubota.co.jp, current@freebsd.org, acpi-jp@jp.freebsd.org Subject: Re: My system hang with ACPI kernel thread In-Reply-To: <20000928193031R.iwasaki@jp.FreeBSD.org> References: <20000928101721L.haro@tk.kubota.co.jp> <200009280438.NAA63726@shidahara1.planet.sci.kobe-u.ac.jp> <20000928193031R.iwasaki@jp.FreeBSD.org> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000929043324K.iwasaki@jp.FreeBSD.org> Date: Fri, 29 Sep 2000 04:33:24 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 238 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > > In message <20000928101721L.haro@tk.kubota.co.jp>, Munehiro Matsuda wrote: > > > > >With the addition of ACPI kernel thread, my system hangs in about > > >10 miniutes use after boot up. By disabling kernel thread, system > > >runs just fine. > > > > > >Do you have any idea where to look at? > > >I'll try and see what I can do myself. > > > > Please set debug.aml_debug and debug.acpi_debug to 1 and > > see what will happen. > > I could find a couple of possibilities from VersaProNX.asl; lack of > SleepOp or EC I/O. If the former, I can try to write it as well as > StallOp tonight, of course Intel ACPICA compatible one. Ok, I've just wrote Stall() and Sleep() operators. Differences between them are short-term or long-term, not relinquish CPU or relinquish CPU. I used DELAY() for StallOp and tsleep() for SleepOp. BTW, is timeout parameter of tsleep broken for now? I had to call wakeup() explicitly, otherwise it won't return from tsleep :-( Index: dev/acpi/acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpi/acpi.c,v retrieving revision 1.14 diff -u -r1.14 acpi.c --- dev/acpi/acpi.c 2000/09/27 05:43:53 1.14 +++ dev/acpi/acpi.c 2000/09/28 19:10:52 @@ -1707,5 +1707,51 @@ SYSINIT(acpi, SI_SUB_KTHREAD_IDLE, SI_ORDER_ANY, acpi_start_threads, 0); +/* + * System service interface + */ + +#include + +#if 1 +/* XXX tsleep timeout broken? */ +static void +acpi_sleep_end(void *chan) +{ + wakeup(chan); +} +#endif +int +acpi_sleep(u_int32_t micro) +{ + int x, error; + static u_int8_t count = 0; + + x = error = 0; + + if (micro == 0) { + return (1); + } + + if (curproc == NULL) { + return (2); + } + +#if 1 +/* XXX tsleep timeout broken? */ + timeout(acpi_sleep_end, (caddr_t)acpi_sleep + count, + (hz * micro) / 1000000L); +#endif + error = tsleep((caddr_t)acpi_sleep + count, PWAIT, "acpislp", + (hz * micro) / 1000000L); + if (error != 0 && error != EWOULDBLOCK) { + return (2); + } + x = splhigh(); + count++; + splx(x); + + return (0); +} Index: dev/acpi/acpi.h =================================================================== RCS file: /home/ncvs/src/sys/dev/acpi/acpi.h,v retrieving revision 1.10 diff -u -r1.10 acpi.h --- dev/acpi/acpi.h 2000/09/27 05:43:54 1.10 +++ dev/acpi/acpi.h 2000/09/28 19:25:37 @@ -163,4 +163,9 @@ #define ACPI_DEVPRINTF(args...) printf("acpi0: " args) #define ACPI_DEBUGPRINT(args...) do { if (acpi_debug) ACPI_DEVPRINTF(args);} while(0) +/* + * System service interface + */ +extern int acpi_sleep(u_int32_t micro); + #endif /* !_DEV_ACPI_ACPI_H_ */ Index: dev/acpi/aml/aml_common.h =================================================================== RCS file: /home/ncvs/src/sys/dev/acpi/aml/aml_common.h,v retrieving revision 1.2 diff -u -r1.2 aml_common.h --- dev/acpi/aml/aml_common.h 2000/09/20 01:01:27 1.2 +++ dev/acpi/aml/aml_common.h 2000/09/28 18:17:27 @@ -47,11 +47,15 @@ printf(fmt, args); \ } while(0) #define AML_DEBUGGER(x, y) /* no debugger in kernel */ +#define AML_STALL(micro) DELAY(micro) +#define AML_SLEEP(sec, milli) OsdSleep(sec, milli) #else /* !_KERNEL */ #define AML_SYSASSERT(x) assert(x) #define AML_SYSABORT() abort() #define AML_SYSERRX(eval, fmt, args...) errx(eval, fmt, args) #define AML_DEBUGGER(x, y) aml_dbgr(x, y) +#define AML_STALL(m) /* not required in userland */ +#define AML_SLEEP(s, m) /* not required in userland */ #endif /* _KERNEL */ union aml_object; Index: dev/acpi/aml/aml_parse.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpi/aml/aml_parse.c,v retrieving revision 1.3 diff -u -r1.3 aml_parse.c --- dev/acpi/aml/aml_parse.c 2000/09/20 22:53:39 1.3 +++ dev/acpi/aml/aml_parse.c 2000/09/28 11:40:44 @@ -55,6 +55,8 @@ #include "debug.h" #else /* _KERNEL */ #include +#include +#include #endif /* !_KERNEL */ static int findsetleftbit(int num); @@ -1484,14 +1486,18 @@ aml_parse_termobj(env, indent); AML_DEBUGPRINT(")"); break; - case 0x21: /* StallOp *//* XXX Not yet */ + case 0x21: /* StallOp */ AML_DEBUGPRINT("Stall("); - aml_parse_termobj(env, indent); + num1 = aml_objtonum(env, aml_eval_name(env, + aml_parse_termobj(env, indent))); AML_DEBUGPRINT(")"); + AML_STALL(num1); break; - case 0x22: /* SleepOp *//* XXX Not yet */ + case 0x22: /* SleepOp */ AML_DEBUGPRINT("Sleep("); - aml_parse_termobj(env, indent); + num1 = aml_objtonum(env, aml_eval_name(env, + aml_parse_termobj(env, indent))); + AML_SLEEP(0, num1); AML_DEBUGPRINT(")"); break; case 0x23: /* AcquireOp *//* XXX Not yet */ Index: i386/include/acpica_osd.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/acpica_osd.h,v retrieving revision 1.4 diff -u -r1.4 acpica_osd.h --- i386/include/acpica_osd.h 2000/09/02 15:06:54 1.4 +++ i386/include/acpica_osd.h 2000/09/28 19:30:05 @@ -38,6 +38,8 @@ #include #include +#include + #include "pcib_if.h" /* @@ -317,3 +319,42 @@ { return (OsdWritePciCfg(Bus, DeviceFunction, Register, Value, 4)); } + +#ifndef ACPI_NO_OSDFUNC_INLINE +static __inline +#endif +ACPI_STATUS +OsdSleepUsec(UINT32 Microseconds) +{ + int error; + ACPI_STATUS status; + + error = acpi_sleep(Microseconds); + switch (error) { + case 0: + /* The running thread slept for the time specified */ + status = AE_OK; + break; + case 1: + /* TBD!!!! */ + status = AE_BAD_PARAMETER; + break; + case 2: + default: + /* The running thread did not slept because of a host OS error */ + status = AE_ERROR; + break; + } + + return (status); +} + +#ifndef ACPI_NO_OSDFUNC_INLINE +static __inline +#endif +ACPI_STATUS +OsdSleep(UINT32 Seconds, UINT32 Milliseconds) +{ + return OsdSleepUsec(Seconds * 1000000L + Milliseconds * 1000); +} + Index: sys/acpi.h =================================================================== RCS file: /home/ncvs/src/sys/sys/acpi.h,v retrieving revision 1.2 diff -u -r1.2 acpi.h --- sys/acpi.h 2000/08/29 20:30:54 1.2 +++ sys/acpi.h 2000/09/28 19:23:54 @@ -314,6 +314,9 @@ ACPI_STATUS OsdWritePciCfgByte(UINT32, UINT32 , UINT32 , UINT8); ACPI_STATUS OsdWritePciCfgWord(UINT32, UINT32 , UINT32 , UINT16); ACPI_STATUS OsdWritePciCfgDword(UINT32, UINT32 , UINT32 , UINT32); + +ACPI_STATUS OsdSleep(UINT32, UINT32); +ACPI_STATUS OsdSleepUsec(UINT32); #endif /* ACPI_NO_OSDFUNC_INLINE */ #else /* !_KERNEL */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 14:38:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from unix.jdthomas.net (c755117-a.eugene1.or.home.com [24.16.233.151]) by hub.freebsd.org (Postfix) with ESMTP id 196D037B423 for ; Thu, 28 Sep 2000 14:37:54 -0700 (PDT) Received: from Debug (c755117-a.eugene1.or.home.com [24.16.233.151]) by unix.jdthomas.net (8.11.0/8.9.3) with SMTP id e8SLrLG79644 for ; Thu, 28 Sep 2000 14:53:21 -0700 (PDT) (envelope-from cvs@mezzoforte.org) Message-Id: <200009282153.e8SLrLG79644@unix.jdthomas.net> To: freebsd-current@FreeBSD.org From: cvs@mezzoforte.org Subject: Make World Date: Thu, 28 Sep 2000 21:53:21 GMT X-Mailer: Endymion MailMan Standard Edition v3.0.24 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I recently cvsup'ped my source to the Current 5.0 version of FreeBSD. I recompiled the kernel and did all of that jazz and ultimately decided I wanted to go back to 4.1. So, I used CVSup to download the 4.1 release. I deleted the usr/obj directory and reissued the "make buildworld" command. It went for a long time, but after a while it errored out with this message: Writing Makefile for DynaLoader mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/auto/DynaLoader perl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib - I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib - I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib - I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib DynaLoader_pm.PL DynaLoader.pm Perl lib version (5.00503) doesn't match executable version (5.006) at /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/Config.pm line 7. Compilation failed in require at DynaLoader_pm.PL line 2. BEGIN failed--compilation aborted at DynaLoader_pm.PL line 2. *** Error code 255 Stop in /usr/obj/usr/src/gnu/usr.bin/perl/perl/ext/DynaLoader. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I thought perhaps that I had some old sources laying around, so I blew away my entire src directory and re-downloaded it from CVS. I deleted the usr/obj directory, and did a make buildworld and came up with the EXACT SAME ERROR! I cannot figure this out. Does anyone have any advice? Thanks, Justin --------------------------------------------- This message was sent through JT's Webmail. http://webmail.jdthomas.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 15: 3:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay1.inwind.it (relay1.inwind.it [212.141.53.67]) by hub.freebsd.org (Postfix) with ESMTP id 5D1DF37B440 for ; Thu, 28 Sep 2000 15:03:01 -0700 (PDT) Received: from bartequi.ottodomain.org (212.141.79.1) by relay1.inwind.it (5.1.046) id 39AFDC990042C86B; Fri, 29 Sep 2000 00:02:27 +0200 From: Salvo Bartolotta Date: Thu, 28 Sep 2000 23:03:04 GMT Message-ID: <20000928.23030400@bartequi.ottodomain.org> Subject: Re: Make World To: cvs@mezzoforte.org Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <200009282153.e8SLrLG79644@unix.jdthomas.net> References: <200009282153.e8SLrLG79644@unix.jdthomas.net> X-Mailer: SuperCalifragilis X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 9/28/00, 10:53:21 PM, cvs@mezzoforte.org wrote regarding Make=20 World: > I recently cvsup'ped my source to the Current 5.0 version of FreeBSD. = =20 I > recompiled the kernel and did all of that jazz and ultimately decided = I wanted > to go back to 4.1. So, I used CVSup to download the 4.1 release. I=20 deleted > the usr/obj directory and reissued the "make buildworld" command. It = went for > a long time, but after a while it errored out with this message: > Writing Makefile for DynaLoader > mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/auto/DynaLoader > perl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib - > I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib - > I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib - > I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib DynaLoader_pm.PL=20 DynaLoader.pm > Perl lib version (5.00503) doesn't match executable version (5.006) > at /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/Config.pm line 7. > Compilation failed in require at DynaLoader_pm.PL line 2. > BEGIN failed--compilation aborted at DynaLoader_pm.PL line 2. > *** Error code 255 > Stop in /usr/obj/usr/src/gnu/usr.bin/perl/perl/ext/DynaLoader. > *** Error code 1 > Stop in /usr/src/gnu/usr.bin/perl/perl. > *** Error code 1 > Stop in /usr/src/gnu/usr.bin/perl. > *** Error code 1 > Stop in /usr/src/gnu/usr.bin. > *** Error code 1 > Stop in /usr/src/gnu. > *** Error code 1 > Stop in /usr/src. > *** Error code 1 > Stop in /usr/src. > *** Error code 1 > Stop in /usr/src. > I thought perhaps that I had some old sources laying around, so I blew= =20 away my > entire src directory and re-downloaded it from CVS. I deleted the=20 usr/obj > directory, and did a make buildworld and came up with the EXACT SAME=20 ERROR! I > cannot figure this out. Does anyone have any advice? > Thanks, > Justin Justin, CURRENT utilizes a different (more recent) version of perl (5.6.0). AFAIR, this problem has already been reported to the list; AFAIR, Kris=20 Kennaway suggested wiping out all traces of perl before making the 4.x=20 buildworld. N.B. I am NOT sure this will grant you success. AFAIR, a few weeks ago, you had to downgrade such pieces as e.g.=20 binutils and gcc. You will have to check those items yourself. At any=20 rate, if something does go wrong, you have a clue ... HTH, Salvo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 17:54:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3.email.verio.net [129.250.36.43]) by hub.freebsd.org (Postfix) with ESMTP id CEA6037B423; Thu, 28 Sep 2000 17:54:05 -0700 (PDT) Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout3.email.verio.net with esmtp (Exim 3.12 #7) id 13eoR9-0006Ii-00; Fri, 29 Sep 2000 00:54:03 +0000 Received: from [204.1.90.43] (helo=power) by dfw-mmp1.email.verio.net with smtp (Exim 3.15 #4) id 13eoR9-00076R-00; Fri, 29 Sep 2000 00:54:03 +0000 From: "Tony Johnson" To: "Thomas David Rivers" , Cc: , , Subject: RE: interesting problem Date: Thu, 28 Sep 2000 19:54:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200009281033.GAA42518@lakes.dignus.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I really did not want to reply to this but since some people believe that I am just see-ing things, then I will set this straight. I have a dual PPro-200 systems. aha-3950u2 scsi card. Teflon cables from scsi-cables.com. Segate cheetah 4.5gig drive that runs FreeBSD5.0-Current since it came out. I have been running FreeBSD for years... I ran 3.0 and 4.0 when they were /current and I never had these problems. I cannot even get the thing (5.0-Current in recent days) to boot from boot floppies that you put on ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386. If you are producing an OS that does not boot on /current then say this publicly and not curse me out for your production of a non functional product. I'm sure I could produce a set of non-functioning asm code that just crashes peoples machines, if your idea of development is this. I don't believe that I need to write an email list for this. I have a better idea, how about an option on the install to save buffer cache to a floppy disk , or atleast the portion that caused the automatic reboot??? Gdb anyone? If you need more information from me about my product then please ask me and I will say so. -----Original Message----- From: owner-freebsd-current@FreeBSD.ORG [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Thomas David Rivers Sent: Thursday, September 28, 2000 5:33 AM To: bright@wintelcom.net; gjohnson@gs.verio.net Cc: freebsd-current@FreeBSD.ORG; grog@lemis.com; kris@FreeBSD.ORG Subject: Re: interesting problem Alfred Perlstein wrote: > > * Tony Johnson [000927 18:26] wrote: > > OK > > Well Here is the issue. If I put in the 2 boot floppies I get a page fault > > 12 after I press Q for "quit" on the visual kernel config. If I can save a > > crash dump before any FS's are mounted or even before I tell FBSD where to > > put the crash dump, I'd really like to know this... I'd like to read a > > handbook page on thisb since some people think I just haven't read it. > > > > At this point in an install, if you could tell me (and the rest of the > > FreeBSD users) where I could get the boot floppies to save a crash dump > > (because I haven't even gotten this far) then I would appreciate this amd be > > more then happy to substantiate this by sending you a crash dump. > > Do you realize how much developer time you're wasting by thrashing > around cluelessly on the list demanding help? > > Here's a clue: > > Forget about your damn irq problem, boot with the disks installed, > then read section of the handbook about crashdumps, compile a debug > kernel and figure out what the problem is. Fix it and send us a > patch. > > Or you could simply run -stable. Alfred, Just playing `devils advocate' here. But, in some initial install situations, exactly how is the user, even the most knowledgeable one, supposed to do much of anything if the install itself doesn't work? Not too much chance of building a kernel, getting a crashdump, etc... Although it may be something we want to put off for awhile, being able to gather debugging information during a failed install would be rather nice. I'm not sure how this could happen; perhaps a crashdump to an MSDOS file system (if available)? Or, straight to a partition with some recovery program that reads the dump? Or, over a serial line? [Just tossing out ideas.] Maybe ficl can get involved and manage this? I would keep this as one of those "maybe nice to have in the ideal future" ideas - but it's something to ponder... - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 18:41:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 6BFE437B43C for ; Thu, 28 Sep 2000 18:41:41 -0700 (PDT) Received: from localhost (trish@localhost) by superconductor.rush.net (8.9.3/8.9.3) with ESMTP id VAA08146; Thu, 28 Sep 2000 21:41:16 -0400 (EDT) Date: Thu, 28 Sep 2000 21:41:15 -0400 (EDT) From: Siobhan Patricia Lynch X-Sender: trish@superconductor.rush.net To: Julian Elischer Cc: "Boyd R. Faulkner" , "Peter S. Housel" , freebsd-current@FreeBSD.ORG Subject: Re: Network bridge on current. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 28 Sep 2000, Julian Elischer wrote: I would assume that code hasn;t changed, it works with ipfw, man bridge: options BRIDGE in the kernel config file, and is controlled by two sysctl variables: net.link.ether.bridge Set to 1 to enable bridging, set to 0 to disable it net.link.ether.bridge_ipfw I assume he's trying to mimic my slashdot kludge, which I wouldn;t recommend unless the issue is you can;t change the network topology. -Trish > hmmmm, > > netgraph's bridging code is more direct but it can not > do IP filtering on the packets that are en-route. This is because it > is a purely MAC-layer service. > > I am not sure about Luigi's bridging code. I know the dummynet stuff > seems to connect with the ipfw code but I don't think that the > bridge code does... (I may be wrong) So I don't know how you plan on > filtering the bridged segments.. > > > On Thu, 28 Sep 2000, Boyd R. Faulkner wrote: > > > On Thu, Sep 28, 2000 at 12:11:54AM -0700, Peter S. Housel wrote: > > > > I am wondering how to do network bridging on current. The description > > > > in the handbook seems to be out of date as the sysctl IODs are no longer > > > > in evidence. Does loading ng_bridge substitute for building the kernel > > > > with OPTIONS BRIDGE? > > > > > > Excuse my ignorance (and curiousity), but wouldn't it be cheaper to > > > just buy a switch? > > > > > > Cheers, > > > -Peter S. Housel- housel@acm.org http://members.home.com/housel/ > > > > I intend to use it as a firewall. The switch will live behind it. > > > > Boyd > > > > -- > > Boyd Faulkner "...but the chocolate at > > faulkner@asgard.hos.net Rumpelmayer's is great..." > > http://asgard.hos.net/~faulkner -- A. Crowley Book of Lies > > 1011101 > > > > > > > > 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 > __ Trish Lynch FreeBSD - The Power to Serve trish@bsdunix.net Rush Networking trish@rush.net VA Linux Systems trish@valinux.com O|S|D|N trish@osdn.com --- "I said 'If love has these conditions, I don't understand those songs you love.' She said 'This is not a love song This isn't fantasyland.'" -Rush, Cold Fire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 18:45:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 4A69637B42C for ; Thu, 28 Sep 2000 18:45:15 -0700 (PDT) Received: from localhost (trish@localhost) by superconductor.rush.net (8.9.3/8.9.3) with ESMTP id VAA28500; Thu, 28 Sep 2000 21:45:06 -0400 (EDT) Date: Thu, 28 Sep 2000 21:45:06 -0400 (EDT) From: Siobhan Patricia Lynch X-Sender: trish@superconductor.rush.net To: Julian Elischer Cc: "Boyd R. Faulkner" , "Peter S. Housel" , freebsd-current@FreeBSD.ORG Subject: Re: Network bridge on current. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 28 Sep 2000, Siobhan Patricia Lynch wrote: uhoh, on a related note, I missed something, the sysctl's have been taken out? I definitely missed something. when did this happen? -Trish > On Thu, 28 Sep 2000, Julian Elischer wrote: > > I would assume that code hasn;t changed, it works with ipfw, man bridge: > > options BRIDGE > > in the kernel config file, and is controlled by two sysctl variables: > > net.link.ether.bridge > > Set to 1 to enable bridging, set to 0 to disable it > > net.link.ether.bridge_ipfw > > > I assume he's trying to mimic my slashdot kludge, which I wouldn;t > recommend unless the issue is you can;t change the network topology. > > -Trish > > > hmmmm, > > > > netgraph's bridging code is more direct but it can not > > do IP filtering on the packets that are en-route. This is because it > > is a purely MAC-layer service. > > > > I am not sure about Luigi's bridging code. I know the dummynet stuff > > seems to connect with the ipfw code but I don't think that the > > bridge code does... (I may be wrong) So I don't know how you plan on > > filtering the bridged segments.. > > > > > > On Thu, 28 Sep 2000, Boyd R. Faulkner wrote: > > > > > On Thu, Sep 28, 2000 at 12:11:54AM -0700, Peter S. Housel wrote: > > > > > I am wondering how to do network bridging on current. The description > > > > > in the handbook seems to be out of date as the sysctl IODs are no longer > > > > > in evidence. Does loading ng_bridge substitute for building the kernel > > > > > with OPTIONS BRIDGE? > > > > > > > > Excuse my ignorance (and curiousity), but wouldn't it be cheaper to > > > > just buy a switch? > > > > > > > > Cheers, > > > > -Peter S. Housel- housel@acm.org http://members.home.com/housel/ > > > > > > I intend to use it as a firewall. The switch will live behind it. > > > > > > Boyd > > > > > > -- > > > Boyd Faulkner "...but the chocolate at > > > faulkner@asgard.hos.net Rumpelmayer's is great..." > > > http://asgard.hos.net/~faulkner -- A. Crowley Book of Lies > > > 1011101 > > > > > > > > > > > > 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 > > > > __ > > Trish Lynch > FreeBSD - The Power to Serve trish@bsdunix.net > Rush Networking trish@rush.net > VA Linux Systems trish@valinux.com > O|S|D|N trish@osdn.com > --- > > "I said 'If love has these conditions, > I don't understand those songs you love.' > She said 'This is not a love song > This isn't fantasyland.'" > -Rush, Cold Fire > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > __ Trish Lynch FreeBSD - The Power to Serve trish@bsdunix.net Rush Networking trish@rush.net VA Linux Systems trish@valinux.com O|S|D|N trish@osdn.com --- "Can't let them rape me again Your venom's not family here won't let them fill me with fatalistic remedies" -Dream Theater, Scarred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 18:51:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 8D4F937B422; Thu, 28 Sep 2000 18:51:27 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8T1oWE04325; Fri, 29 Sep 2000 11:20:32 +0930 (CST) (envelope-from grog) Date: Fri, 29 Sep 2000 11:20:32 +0930 From: Greg Lehey To: Tony Johnson Cc: Thomas David Rivers , bright@wintelcom.net, freebsd-current@FreeBSD.ORG, kris@FreeBSD.ORG Subject: Re: interesting problem Message-ID: <20000929112032.A4293@wantadilla.lemis.com> References: <200009281033.GAA42518@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from gjohnson@gs.verio.net on Thu, Sep 28, 2000 at 07:54:01PM -0500 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Format recovered--see http://www.lemis.com/email/email-format.html] On Thursday, 28 September 2000 at 19:54:01 -0500, Tony Johnson wrote: > On Thursday, September 28, 2000 5:33 AM, Thomas David Rivers wrote: >> Alfred Perlstein wrote: >>> >>> * Tony Johnson [000927 18:26] wrote: >>>> OK Well Here is the issue. If I put in the 2 boot floppies I get >>>> a page fault 12 after I press Q for "quit" on the visual kernel >>>> config. If I can save a crash dump before any FS's are mounted or >>>> even before I tell FBSD where to put the crash dump, I'd really >>>> like to know this... I'd like to read a handbook page on thisb >>>> since some people think I just haven't read it. >>>> >>>> At this point in an install, if you could tell me (and the rest of >>>> the FreeBSD users) where I could get the boot floppies to save a >>>> crash dump (because I haven't even gotten this far) then I would >>>> appreciate this amd be more then happy to substantiate this by >>>> sending you a crash dump. >>> >>> Do you realize how much developer time you're wasting by thrashing >>> around cluelessly on the list demanding help? >>> >>> Here's a clue: >>> >>> Forget about your damn irq problem, boot with the disks installed, >>> then read section of the handbook about crashdumps, compile a debug >>> kernel and figure out what the problem is. Fix it and send us a >>> patch. >>> >>> Or you could simply run -stable. >> >> Alfred, >> >> Just playing `devils advocate' here. But, in some initial >> install situations, exactly how is the user, even the most >> knowledgeable one, supposed to do much of anything if the >> install itself doesn't work? Not too much chance of building >> a kernel, getting a crashdump, etc... >> >> Although it may be something we want to put off for awhile, >> being able to gather debugging information during a failed >> install would be rather nice. I'm not sure how this could >> happen; perhaps a crashdump to an MSDOS file system (if available)? >> Or, straight to a partition with some recovery program that >> reads the dump? Or, over a serial line? [Just tossing out ideas.] >> Maybe ficl can get involved and manage this? >> >> I would keep this as one of those "maybe nice to have in the >> ideal future" ideas - but it's something to ponder... Certainly it would be a nice idea. We have plenty of cases where a -CURRENT system might have difficulties booting. In general we solve the problem in one of two ways: 1. Build a kernel with debugger support and analyse what the problem is. 2. Work around it long enough to get the system to a point where you can take dumps. This is the approach Alfred is suggesting. I don't think this has much to to with the current situation: based on the evidence we have seen, it seems that Tony has tried to boot a release snapshot of -CURRENT. It failed. Coincidentally, he has also disabled IDE support in the belief that this might buy him something. Now he comes and claims that there is a connection between these two events, but he doesn't give us any evidence. > I really did not want to reply to this but since some people believe > that I am just see-ing things, then I will set this straight. I don't think anybody claims you're seeing things. > I have a dual PPro-200 systems. aha-3950u2 scsi card. Teflon > cables from scsi-cables.com. Segate cheetah 4.5gig drive that runs > FreeBSD5.0-Current since it came out. Maybe you should change the teflon cables. > I have been running FreeBSD for years... I ran 3.0 and 4.0 when > they were /current and I never had these problems. I cannot even > get the thing (5.0-Current in recent days) to boot from boot > floppies that you put on > ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386. If you are > producing an OS that does not boot on /current then say this > publicly and not curse me out for your production of a non > functional product. For public record: we are not producing an OS that does not boot. We're prepared to believe that you're unable to boot it, but you're not doing anything to get people to help you. > I'm sure I could produce a set of non-functioning asm code that just > crashes peoples machines, if your idea of development is this. I > don't believe that I need to write an email list for this. No, of course not. In fact, saying things like that really discredits you. > I have a better idea, how about an option on the install to save > buffer cache to a floppy disk , or atleast the portion that caused > the automatic reboot??? Gdb anyone? A typical machine nowadays has 128 MB of memory. That would just about fit on an LS-120, but you'd need about 90 floppies to dump to. That doesn't make sense. My personal feeling is that you should take Alfred's advice and try to boot without disabling IDE. It may or may not work. If it doesn't, you'll know you're wrong about connecting the two events. If it does, it'll give you a system which is usable for debugging the problem. > If you need more information from me about my product then please > ask me and I will say so. I thought we were talking about a product, not a problem you're having. Maybe it's time to remind people about -CURRENT: Many users compile almost daily from FreeBSD-CURRENT sources, but there are times when the sources are uncompilable. The problems are always resolved, but others can take their place. On occasion, keeping up with FreeBSD-CURRENT can be a full-time business. If you use -CURRENT, you should be prepared to spend a lot of time keeping the system running. In particular, note who should be doing the work: the people who have the problem. It doesn't do any good to thrash around, make unsubstantiated claims and blame other people. On the contrary, it makes people think you're a jerk. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 19: 1: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id A83ED37B422 for ; Thu, 28 Sep 2000 19:00:49 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8T20lf04430 for FreeBSD-current@FreeBSD.ORG; Fri, 29 Sep 2000 11:30:47 +0930 (CST) (envelope-from grog) Date: Fri, 29 Sep 2000 11:30:47 +0930 From: Greg Lehey To: FreeBSD current users Subject: Repeated panic out of chgsbsize Message-ID: <20000929113047.B4293@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the past couple of days, I've had a couple of panics out of chgsbsize: (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:303 #1 0xc01cbac9 in panic (fmt=0xc0380e6f "page fault") at ../../kern/kern_shutdown.c:553 #2 0xc0316466 in trap_fatal (frame=0xc038a5c4, eva=48) at ../../i386/i386/trap.c:951 #3 0xc0316119 in trap_pfault (frame=0xc038a5c4, usermode=0, eva=48) at ../../i386/i386/trap.c:844 #4 0xc0315c8f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1033507840, tf_ebp = -1070029304, tf_isp = -1070029328, tf_ebx = -1069888396, tf_edx = 6864928, tf_ecx = -808467136, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1070853968, tf_cs = 8, tf_eflags = 66050, tf_esp = -1033507840, tf_ss = -1070029272}) at ../../i386/i386/trap.c:443 #5 0xc02c10b0 in acquire_lock (lk=0xc03acc74) at ../../ufs/ffs/ffs_softdep.c:263 #6 0xc02c4eac in softdep_update_inodeblock (ip=0xc265ec00, bp=0xc6c17f60, waitfor=0) at ../../ufs/ffs/ffs_softdep.c:3626 #7 0xc02bd9b1 in ffs_update (vp=0xcfcfc540, waitfor=0) at ../../ufs/ffs/ffs_inode.c:107 #8 0xc02c9922 in ffs_fsync (ap=0xc038a6d4) at ../../ufs/ffs/ffs_vnops.c:289 #9 0xc02c8243 in ffs_sync (mp=0xc1a7be00, waitfor=2, cred=0xc0e39780, p=0xc03e0400) at vnode_if.h:537 #10 0xc01fdf19 in sync (p=0xc03e0400, uap=0x0) at ../../kern/vfs_syscalls.c:566 #11 0xc01cb4ff in boot (howto=256) at ../../kern/kern_shutdown.c:225 #12 0xc01cbac9 in panic (fmt=0xc0356920 "reducing sbsize: lost count, uid = %d") at ../../kern/kern_shutdown.c:553 #13 0xc01c8d7b in chgsbsize (uid=50, diff=-17520, max=9223372036854775807) at ../../kern/kern_proc.c:206 #14 0xc01ee6aa in sbrelease (sb=0xcdc091f4, so=0xcdc09180) at ../../kern/uipc_socket2.c:453 #15 0xc01eb9fb in sofree (so=0xcdc09180) at ../../kern/uipc_socket.c:261 #16 0xc0221e0b in in_pcbdetach (inp=0xce1c3aa0) at ../../netinet/in_pcb.c:542 #17 0xc022c462 in tcp_close (tp=0xce1c3b60) at ../../netinet/tcp_subr.c:711 #18 0xc0229bf6 in tcp_input (m=0xc0e96500, off0=20, proto=6) at ../../netinet/tcp_input.c:2012 #19 0xc02247ee in ip_input (m=0xc0e96500) at ../../netinet/ip_input.c:756 #20 0xc022484b in ipintr () at ../../netinet/ip_input.c:784 #21 0xc0309195 in swi_net_next () (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:303 #1 0xc01cbac9 in panic (fmt=0xc0380e6f "page fault") at ../../kern/kern_shutdown.c:553 #2 0xc0316466 in trap_fatal (frame=0xc038a728, eva=48) at ../../i386/i386/trap.c:951 #3 0xc0316119 in trap_pfault (frame=0xc038a728, usermode=0, eva=48) at ../../i386/i386/trap.c:844 #4 0xc0315c8f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 0, tf_ebp = -1070028948, tf_isp = -1070028972, tf_ebx = -1069888396, tf_edx = 6864928, tf_ecx = -1046781312, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1070853968, tf_cs = 8, tf_eflags = 66050, tf_esp = -960338688, tf_ss = -1070028924}) at ../../i386/i386/trap.c:443 #5 0xc02c10b0 in acquire_lock (lk=0xc03acc74) at ../../ufs/ffs/ffs_softdep.c:263 #6 0xc02c63a8 in softdep_count_dependencies (bp=0xc6c26500, wantcount=0) at ../../ufs/ffs/ffs_softdep.c:4566 #7 0xc02c96fb in ffs_fsync (ap=0xc038a800) at ../../sys/buf.h:439 #8 0xc02c8243 in ffs_sync (mp=0xc1a7be00, waitfor=2, cred=0xc0e39780, p=0xc03e0400) at vnode_if.h:537 #9 0xc01fdf19 in sync (p=0xc03e0400, uap=0x0) at ../../kern/vfs_syscalls.c:566 #10 0xc01cb4ff in boot (howto=256) at ../../kern/kern_shutdown.c:225 #11 0xc01cbac9 in panic (fmt=0xc0356920 "reducing sbsize: lost count, uid = %d") at ../../kern/kern_shutdown.c:553 #12 0xc01c8d7b in chgsbsize (uid=50, diff=-17424, max=9223372036854775807) at ../../kern/kern_proc.c:206 #13 0xc01ee6aa in sbrelease (sb=0xcdc08674, so=0xcdc08600) at ../../kern/uipc_socket2.c:453 #14 0xc01eb9fb in sofree (so=0xcdc08600) at ../../kern/uipc_socket.c:261 #15 0xc0221e0b in in_pcbdetach (inp=0xce1c0aa0) at ../../netinet/in_pcb.c:542 #16 0xc022c462 in tcp_close (tp=0xce1c0b60) at ../../netinet/tcp_subr.c:711 #17 0xc022cf76 in tcp_timer_2msl (xtp=0xce1c0b60) at ../../netinet/tcp_timer.c:212 #18 0xc01d2015 in softclock () at ../../kern/kern_timeout.c:131 This is out of a -CURRENT built some time round Mon Aug 28 16:17:04 CST(+9:30) 2000. I haven't had any other problems, so it doesn't seem to be a general problem. Before I go looking in more detail, has anybody else seen this, or do they have an idea what I should be looking at? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 19:24:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from volatile.chemicals.tacorp.com (ci391991-a.grnvle1.sc.home.com [24.9.31.75]) by hub.freebsd.org (Postfix) with ESMTP id 9A48837B446; Thu, 28 Sep 2000 19:20:53 -0700 (PDT) Received: (from morganw@localhost) by volatile.chemicals.tacorp.com (8.11.0/8.11.0) id e8T2Kq171337; Thu, 28 Sep 2000 22:20:52 -0400 (EDT)?g (envelope-from morganw)œ Date: Thu, 28 Sep 2000 22:20:52 -0400 (EDT) From: Wesley Morgan To: current@freebsd.org Cc: smp@freebsd.org Subject: panic in "kernel configuration menu" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When the kernel configuration menu comes up with the three possible selections, pressing ctrl-alt-del ends up with this message: panic: spin lock (null) held by 0x0 for > 5 seconds sounds like one that should be an easy fix -- _ __ ___ ____ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ wesleymorgan@home.com _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 19:46: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by hub.freebsd.org (Postfix) with ESMTP id 89E5E37B424; Thu, 28 Sep 2000 19:45:18 -0700 (PDT) Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp (Exim 3.12 #7) id 13eqAm-0000Xv-00; Fri, 29 Sep 2000 02:45:16 +0000 Received: from [204.1.90.43] (helo=power) by dfw-mmp2.email.verio.net with smtp (Exim 3.15 #4) id 13eqAl-0006F2-00; Fri, 29 Sep 2000 02:45:15 +0000 From: "Tony Johnson" To: "Greg Lehey" Cc: "Thomas David Rivers" , , , Subject: RE: interesting problem Date: Thu, 28 Sep 2000 21:45:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20000929112032.A4293@wantadilla.lemis.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I will not provide comments as the below messages are already too messy. Remove my teflon cables... Hmmm... I'll try it but something tells me that this is like trying to shoot an arbitrary star in the midnight sky. FreeBSD doesn't like teflon or is it just my system??? The issue is this. I have been cvsup-ing 5.0-Current for months and recently I have and these problems. Within the last 4 weeks. My scsi cables or my adaptec controller had no influence on this since recently... I don't believe turning on stuff that has no functionality to the system should be an issue. If it is then this is broken. "People compile daily from -Current" Well I was one of them and I don't believe that my system is the problem! People keep saying that I am shooting blanks because I haven't provided any evidence. Give me a way to provide evidence and I will show you that 2000927-5.0CURRENT has crashed my machine which has worked on pretty much every revision of FreeBSD since 3.0-Current! The teflon cables and everything... As said below... "In particular, note who should be doing the work: the people who have the problem. It doesn't do any good to thrash around, make unsubstantiated claims and blame other people. On the contrary, it makes people think you're a jerk." Since I am complaining then I need to figure out what U have done to make 5.0-CURRENT crash?? Well atleast U admit that U do not know and U do not care. So anyone who is using FreeBSD should also not care?? This is more screwed up then I thought and people @FreeBSD have made this much harder then necessary. -----Original Message----- From: Greg Lehey [mailto:grog@lemis.com] Sent: Thursday, September 28, 2000 8:51 PM To: Tony Johnson Cc: Thomas David Rivers; bright@wintelcom.net; freebsd-current@FreeBSD.ORG; kris@FreeBSD.ORG Subject: Re: interesting problem [Format recovered--see http://www.lemis.com/email/email-format.html] On Thursday, 28 September 2000 at 19:54:01 -0500, Tony Johnson wrote: > On Thursday, September 28, 2000 5:33 AM, Thomas David Rivers wrote: >> Alfred Perlstein wrote: >>> >>> * Tony Johnson [000927 18:26] wrote: >>>> OK Well Here is the issue. If I put in the 2 boot floppies I get >>>> a page fault 12 after I press Q for "quit" on the visual kernel >>>> config. If I can save a crash dump before any FS's are mounted or >>>> even before I tell FBSD where to put the crash dump, I'd really >>>> like to know this... I'd like to read a handbook page on thisb >>>> since some people think I just haven't read it. >>>> >>>> At this point in an install, if you could tell me (and the rest of >>>> the FreeBSD users) where I could get the boot floppies to save a >>>> crash dump (because I haven't even gotten this far) then I would >>>> appreciate this amd be more then happy to substantiate this by >>>> sending you a crash dump. >>> >>> Do you realize how much developer time you're wasting by thrashing >>> around cluelessly on the list demanding help? >>> >>> Here's a clue: >>> >>> Forget about your damn irq problem, boot with the disks installed, >>> then read section of the handbook about crashdumps, compile a debug >>> kernel and figure out what the problem is. Fix it and send us a >>> patch. >>> >>> Or you could simply run -stable. >> >> Alfred, >> >> Just playing `devils advocate' here. But, in some initial >> install situations, exactly how is the user, even the most >> knowledgeable one, supposed to do much of anything if the >> install itself doesn't work? Not too much chance of building >> a kernel, getting a crashdump, etc... >> >> Although it may be something we want to put off for awhile, >> being able to gather debugging information during a failed >> install would be rather nice. I'm not sure how this could >> happen; perhaps a crashdump to an MSDOS file system (if available)? >> Or, straight to a partition with some recovery program that >> reads the dump? Or, over a serial line? [Just tossing out ideas.] >> Maybe ficl can get involved and manage this? >> >> I would keep this as one of those "maybe nice to have in the >> ideal future" ideas - but it's something to ponder... Certainly it would be a nice idea. We have plenty of cases where a -CURRENT system might have difficulties booting. In general we solve the problem in one of two ways: 1. Build a kernel with debugger support and analyse what the problem is. 2. Work around it long enough to get the system to a point where you can take dumps. This is the approach Alfred is suggesting. I don't think this has much to to with the current situation: based on the evidence we have seen, it seems that Tony has tried to boot a release snapshot of -CURRENT. It failed. Coincidentally, he has also disabled IDE support in the belief that this might buy him something. Now he comes and claims that there is a connection between these two events, but he doesn't give us any evidence. > I really did not want to reply to this but since some people believe > that I am just see-ing things, then I will set this straight. I don't think anybody claims you're seeing things. > I have a dual PPro-200 systems. aha-3950u2 scsi card. Teflon > cables from scsi-cables.com. Segate cheetah 4.5gig drive that runs > FreeBSD5.0-Current since it came out. Maybe you should change the teflon cables. > I have been running FreeBSD for years... I ran 3.0 and 4.0 when > they were /current and I never had these problems. I cannot even > get the thing (5.0-Current in recent days) to boot from boot > floppies that you put on > ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386. If you are > producing an OS that does not boot on /current then say this > publicly and not curse me out for your production of a non > functional product. For public record: we are not producing an OS that does not boot. We're prepared to believe that you're unable to boot it, but you're not doing anything to get people to help you. > I'm sure I could produce a set of non-functioning asm code that just > crashes peoples machines, if your idea of development is this. I > don't believe that I need to write an email list for this. No, of course not. In fact, saying things like that really discredits you. > I have a better idea, how about an option on the install to save > buffer cache to a floppy disk , or atleast the portion that caused > the automatic reboot??? Gdb anyone? A typical machine nowadays has 128 MB of memory. That would just about fit on an LS-120, but you'd need about 90 floppies to dump to. That doesn't make sense. My personal feeling is that you should take Alfred's advice and try to boot without disabling IDE. It may or may not work. If it doesn't, you'll know you're wrong about connecting the two events. If it does, it'll give you a system which is usable for debugging the problem. > If you need more information from me about my product then please > ask me and I will say so. I thought we were talking about a product, not a problem you're having. Maybe it's time to remind people about -CURRENT: Many users compile almost daily from FreeBSD-CURRENT sources, but there are times when the sources are uncompilable. The problems are always resolved, but others can take their place. On occasion, keeping up with FreeBSD-CURRENT can be a full-time business. If you use -CURRENT, you should be prepared to spend a lot of time keeping the system running. In particular, note who should be doing the work: the people who have the problem. It doesn't do any good to thrash around, make unsubstantiated claims and blame other people. On the contrary, it makes people think you're a jerk. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 20: 0:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43]) by hub.freebsd.org (Postfix) with ESMTP id B5D2737B42C for ; Thu, 28 Sep 2000 20:00:46 -0700 (PDT) Received: (from nnd@localhost) by wint.itfs.nsk.su (8.11.0/8.11.0) id e8T30S802550; Fri, 29 Sep 2000 10:00:28 +0700 (NOVST) (envelope-from nnd) Date: Fri, 29 Sep 2000 10:00:28 +0700 (NOVST) Message-Id: <200009290300.e8T30S802550@wint.itfs.nsk.su> From: Nickolay Dudorov To: current@freebsd.org Subject: Re: interesting problem In-Reply-To: <20000929112032.A4293@wantadilla.lemis.com> X-Newsgroups: itfs.freebsd.current User-Agent: tin/1.5.6-20000803 ("Dust") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000929112032.A4293@wantadilla.lemis.com> you wrote: > > I don't think this has much to to with the current situation: based on > the evidence we have seen, it seems that Tony has tried to boot a > release snapshot of -CURRENT. It failed. Coincidentally, he has also > disabled IDE support in the belief that this might buy him something. > Now he comes and claims that there is a connection between these two > events, but he doesn't give us any evidence. I must say that (at least in my configuration) there IS the connection between 'trap 12' while booting CURRENT builded (with build+install-world and build+install-kernel) at 27.09 and 28.09 AND disabled in BIOS IDE controller. My system is based on Abit's BP6 motherboard with two Celerons 366. If I disable in BIOS conf. menu standard IDE controller and try to boot the system with the (ATA) disks on the HPT366 controller I receive 'trap 12' after 'atapci0: Busmastering DMA not enabled' message. After enabling primary IDE controller in BIOS without any disks or CDROMs on it I successfully boot this -current system and write this message from it. -current builded at 24.09 successfully boots and works on my system with primary and secondary IDE controllers disabled in BIOS. Unfortunately I have no time to spend on debugging this situation. If somebody ( sos ?) wants the screen shot of the trap message I can send it to you (with the results of the 'nm'-ing the kernel ?). N.Dudorov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 20: 5:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 2C1EA37B422; Thu, 28 Sep 2000 20:05:01 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8T34cf04810; Fri, 29 Sep 2000 12:34:38 +0930 (CST) (envelope-from grog) Date: Fri, 29 Sep 2000 12:34:38 +0930 From: Greg Lehey To: Tony Johnson Cc: Thomas David Rivers , bright@wintelcom.net, freebsd-current@FreeBSD.ORG, kris@FreeBSD.ORG Subject: Re: interesting problem Message-ID: <20000929123438.F4293@wantadilla.lemis.com> References: <20000929112032.A4293@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from gjohnson@gs.verio.net on Thu, Sep 28, 2000 at 09:45:13PM -0500 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 28 September 2000 at 21:45:13 -0500, Tony Johnson wrote: > I will not provide comments as the below messages are already too > messy. It would be nice if you'd adhere to the conventions when you reply, however. It's much easier to understand in chronological order. I've now had to manually move your comments to below the text to which they refer. > The issue is this. I have been cvsup-ing 5.0-Current for months and > recently I have and these problems. Within the last 4 weeks. My > scsi cables or my adaptec controller had no influence on this since > recently... OK, this is new information. > I don't believe turning on stuff that has no functionality to the > system should be an issue. If it is then this is broken. Agreed, if it is. We first need to establish that. You seem to be missing the point that we don't blame individual components until we have evidence. > "People compile daily from -Current" Well I was one of them and I > don't believe that my system is the problem! I don't believe anything yet. You need to find out what the problem is. In case you didn't notice it, I've had some problems as well in the last couple of days. Follow that thread, it might give you an idea about how we go about solving problems in -CURRENT. > On Thursday, September 28, 2000 8:51 PM, Greg Lehey wrote: >> On Thursday, 28 September 2000 at 19:54:01 -0500, Tony Johnson wrote: >>> I have a dual PPro-200 systems. aha-3950u2 scsi card. Teflon >>> cables from scsi-cables.com. Segate cheetah 4.5gig drive that runs >>> FreeBSD5.0-Current since it came out. >> >> Maybe you should change the teflon cables. > Remove my teflon cables... Hmmm... I'll try it but something tells > me that this is like trying to shoot an arbitrary star in the > midnight sky. FreeBSD doesn't like teflon or is it just my > system??? I'm sorry, this was intended as a reductio ad absurdum. I consider it so unlikely that it is the cables that I was drawing a parallel to you assuming that disabling the IDE drivers was the reason for >> My personal feeling is that you should take Alfred's advice and try to >> boot without disabling IDE. It may or may not work. If it doesn't, >> you'll know you're wrong about connecting the two events. If it does, >> it'll give you a system which is usable for debugging the problem. > > People keep saying that I am shooting blanks because I haven't > provided any evidence. Give me a way to provide evidence and I will > show you that 2000927-5.0CURRENT has crashed my machine which has > worked on pretty much every revision of FreeBSD since 3.0-Current! > The teflon cables and everything... It looks a little funny now that I've moved your text here, doesn't it? See how chronological order changes and clarifies things? In case you haven't noticed, I have given you a suggestion immediately above, but since you replied in a different place, you appear not to have noticed it. >> Maybe it's time to remind people about -CURRENT: >> >> Many users compile almost daily from FreeBSD-CURRENT sources, but >> there are times when the sources are uncompilable. The problems are >> always resolved, but others can take their place. On occasion, >> keeping up with FreeBSD-CURRENT can be a full-time business. If you >> use -CURRENT, you should be prepared to spend a lot of time keeping >> the system running. >> >> In particular, note who should be doing the work: the people who have >> the problem. It doesn't do any good to thrash around, make >> unsubstantiated claims and blame other people. On the contrary, it >> makes people think you're a jerk. > > As said below... As said just above, where it belongs. > "In particular, note who should be doing the work: the people who have > the problem. It doesn't do any good to thrash around, make > unsubstantiated claims and blame other people. On the contrary, it > makes people think you're a jerk." You don't need to repeat it, it's there in the text. > Since I am complaining then I need to figure out what U have done to > make 5.0-CURRENT crash?? Well atleast U admit that U do not know > and U do not care. So anyone who is using FreeBSD should also not > care?? This is more screwed up then I thought and people @FreeBSD > have made this much harder then necessary. This kind of statement just tends to harden the negative impression you're already making. We care, but we don't care enough to do work for other people when they're just being abusive. If you want to run -CURRENT, at least pull your weight. I won't answer another message of this nature. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 20:24:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 6B8B737B424; Thu, 28 Sep 2000 20:24:15 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8T3LWQ04932; Fri, 29 Sep 2000 12:51:32 +0930 (CST) (envelope-from grog) Date: Fri, 29 Sep 2000 12:51:32 +0930 From: Greg Lehey To: Wesley Morgan Cc: current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: panic in "kernel configuration menu" Message-ID: <20000929125132.H4293@wantadilla.lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from morganw@chemicals.tacorp.com on Thu, Sep 28, 2000 at 10:20:52PM -0400 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 28 September 2000 at 22:20:52 -0400, Wesley Morgan wrote: > When the kernel configuration menu comes up with the three possible > selections, pressing ctrl-alt-del ends up with this message: > > panic: spin lock (null) held by 0x0 for > 5 seconds > > sounds like one that should be an easy fix Don't count on it. At the moment, it probably fits into the category "well don't do that then". Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 21: 6:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id DE19137B423; Thu, 28 Sep 2000 21:06:23 -0700 (PDT) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8T45sU92435; Thu, 28 Sep 2000 21:05:54 -0700 (PDT) (envelope-from jkh@winston.osd.bsdi.com) To: "Tony Johnson" Cc: "Greg Lehey" , "Thomas David Rivers" , bright@wintelcom.net, freebsd-current@FreeBSD.ORG, kris@FreeBSD.ORG Subject: Re: interesting problem In-Reply-To: Message from "Tony Johnson" of "Thu, 28 Sep 2000 21:45:13 CDT." Date: Thu, 28 Sep 2000 21:05:54 -0700 Message-ID: <92431.970200354@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I will not provide comments as the below messages are already too messy. > Remove my teflon cables... Hmmm... I'll try it but something tells me that > this is like trying to shoot an arbitrary star in the midnight sky. FreeBSD > doesn't like teflon or is it just my system??? I think there have been a few people in this thread who've replied with a significant lack of tact and for that probably need to be taken to task - I don't think that many aspects of this thread have reflected well on the participants in that regard. That said, I'll take the liberty of translating what I believe they're *trying* to say in a way which I'm hoping will be a more tactful. The practice of running -current, something which any commercial Unix development shop would not even give its "customers" the benefit of, is one definitely not recommended for everyone. It's basically for developers and people who can, at the very minimum, provide crash dumps and actively help to debug problems. Please note that I do not say "help report problems" since that's not actually what's being solicited by making -current widely available - that would entail a staff of people who did little more than interpret problem reports and we're not big enough to sustain that kind of effort yet. What we're looking for with -current are essentially "co-developers", everyone else being actively (and, in some cases, forcefully) directed to -stable. In short, I honestly believe you're simply on the wrong branch and will do both yourself and the developers a world of good by jumping out of the shark tank and into more hospitable waters. Should your problems persist in -stable, that will be an entirely different matter and I'll be among the first to jump in and try and help you debug the problem. With -current, all bets are literally off. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Sep 28 22:57:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from simon.catburg.net (cust-92-32.customer.jump.net [207.8.92.32]) by hub.freebsd.org (Postfix) with ESMTP id F40B637B423 for ; Thu, 28 Sep 2000 22:57:13 -0700 (PDT) Received: (from faulkner@localhost) by simon.catburg.net (8.11.0/8.11.0) id e8T5rQ700465; Fri, 29 Sep 2000 00:53:26 -0500 (CDT) (envelope-from faulkner) Date: Fri, 29 Sep 2000 00:53:26 -0500 From: "Boyd R. Faulkner" To: Siobhan Patricia Lynch Cc: Julian Elischer , "Boyd R. Faulkner" , "Peter S. Housel" , freebsd-current@FreeBSD.ORG Subject: Re: Network bridge on current. Message-ID: <20000929005326.A442@simon.catburg.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from trish@bsdunix.net on Thu, Sep 28, 2000 at 09:41:15PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Never mind. I had not updated the boot blocks and was not running the right kernel. That was an adventure! Sorry for the noise and thanks. Boyd On Thu, Sep 28, 2000 at 09:41:15PM -0400, Siobhan Patricia Lynch wrote: > On Thu, 28 Sep 2000, Julian Elischer wrote: > > I would assume that code hasn;t changed, it works with ipfw, man bridge: > > options BRIDGE > > in the kernel config file, and is controlled by two sysctl variables: > > net.link.ether.bridge > > Set to 1 to enable bridging, set to 0 to disable it > > net.link.ether.bridge_ipfw > > > I assume he's trying to mimic my slashdot kludge, which I wouldn;t > recommend unless the issue is you can;t change the network topology. > > -Trish > > > hmmmm, > > > > netgraph's bridging code is more direct but it can not > > do IP filtering on the packets that are en-route. This is because it > > is a purely MAC-layer service. > > > > I am not sure about Luigi's bridging code. I know the dummynet stuff > > seems to connect with the ipfw code but I don't think that the > > bridge code does... (I may be wrong) So I don't know how you plan on > > filtering the bridged segments.. > > > > > > On Thu, 28 Sep 2000, Boyd R. Faulkner wrote: > > > > > On Thu, Sep 28, 2000 at 12:11:54AM -0700, Peter S. Housel wrote: > > > > > I am wondering how to do network bridging on current. The description > > > > > in the handbook seems to be out of date as the sysctl IODs are no longer > > > > > in evidence. Does loading ng_bridge substitute for building the kernel > > > > > with OPTIONS BRIDGE? > > > > > > > > Excuse my ignorance (and curiousity), but wouldn't it be cheaper to > > > > just buy a switch? > > > > > > > > Cheers, > > > > -Peter S. Housel- housel@acm.org http://members.home.com/housel/ > > > > > > I intend to use it as a firewall. The switch will live behind it. > > > > > > Boyd > > > > > > -- > > > Boyd Faulkner "...but the chocolate at > > > faulkner@asgard.hos.net Rumpelmayer's is great..." > > > http://asgard.hos.net/~faulkner -- A. Crowley Book of Lies > > > 1011101 > > > > > > > > > > > > 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 > > > > __ > > Trish Lynch > FreeBSD - The Power to Serve trish@bsdunix.net > Rush Networking trish@rush.net > VA Linux Systems trish@valinux.com > O|S|D|N trish@osdn.com > --- > > "I said 'If love has these conditions, > I don't understand those songs you love.' > She said 'This is not a love song > This isn't fantasyland.'" > -Rush, Cold Fire Boyd -- Boyd Faulkner "...but the chocolate at faulkner@asgard.hos.net Rumpelmayer's is great..." http://asgard.hos.net/~faulkner -- A. Crowley Book of Lies 1011101 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 0:18:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0905537B423; Fri, 29 Sep 2000 00:18:32 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8T7IMv27396; Fri, 29 Sep 2000 00:18:22 -0700 (PDT) Date: Fri, 29 Sep 2000 00:18:22 -0700 From: Alfred Perlstein To: Tony Johnson Cc: Thomas David Rivers , freebsd-current@FreeBSD.ORG, grog@lemis.com, kris@FreeBSD.ORG Subject: Re: interesting problem Message-ID: <20000929001822.A7553@fw.wintelcom.net> References: <200009281033.GAA42518@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from gjohnson@gs.verio.net on Thu, Sep 28, 2000 at 07:54:01PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Tony Johnson [000928 17:54] wrote: > I really did not want to reply to this but since some people believe that I > am just see-ing things, then I will set this straight. No we don't Tony, we aren't claiming any stability in -current, I'm sure people will remeber your initial bug report and eventually work out a fix. Unfortunatly for you they may also remeber how you continued to hammer on this issue while completely deluding yourself. > > I have a dual PPro-200 systems. aha-3950u2 scsi card. Teflon cables from > scsi-cables.com. Segate cheetah 4.5gig drive that runs FreeBSD5.0-Current > since it came out. > > I have been running FreeBSD for years... I ran 3.0 and 4.0 when they were > /current and I never had these problems. You were obviously luckier than I was at times. > I cannot even get the thing > (5.0-Current in recent days) to boot from boot floppies that you put on > ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386. If you are producing > an OS that does not boot on /current then say this publicly and not curse me > out for your production of a non functional product. We do, read on. > I'm sure I could > produce a set of non-functioning asm code that just crashes peoples > machines, if your idea of development is this. I don't believe that I need > to write an email list for this. Actually Tony, I'm unsure if you're able to produce _any_ code because so I really can't remeber seeing any code produced by you. You also seriously need to read the handbook, http://www.freebsd.org/handbook/current-stable.html: 18.2.1.1. What is FreeBSD-CURRENT? FreeBSD-CURRENT is, quite literally, nothing more than a daily snapshot of the working sources for FreeBSD. These include work in progress, experimental changes and transitional mechanisms that may or may not be present in the next official release of the software. While many of us compile almost daily from FreeBSD-CURRENT sources, there are periods of time when the sources are literally un-compilable. These problems are generally resolved as expeditiously as possible, but whether or not FreeBSD-CURRENT sources bring disaster or greatly desired functionality can literally be a matter of which part of any given 24 hour period you grabbed them in! It goes on to say: 18.2.1.3. What is FreeBSD-CURRENT not? 1.A fast-track to getting pre-release bits because you heard there is some cool new feature in there and you want to be the first on your block to have it. 2.A quick way of getting bug fixes. 3.In any way ``officially supported'' by us. We do our best to help people genuinely in one of the 3 ``legitimate'' FreeBSD-CURRENT categories, but we simply do not have the time to provide tech support for it. This is not because we are mean and nasty people who do not like helping people out (we would not even be doing FreeBSD if we were), it is literally because we cannot answer 400 messages a day and actually work on FreeBSD! I am sure that, if given the choice between having us answer lots of questions or continuing to improve FreeBSD, most of you would vote for us improving it. Can you imagine that! Yup, you were warned, you were told, the only thing we couldn't do (unfortunatly) is fly someone over to fwap you with a rolled up newspaper when you initially thought of running -current. I think all three points are reason enough for you to stop using -current. > I have a better idea, how about an option on the install to save buffer > cache to a floppy disk , or atleast the portion that caused the automatic > reboot??? Gdb anyone? Sure, send patches, follow my previous advice or simply piss off. jeez, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 0:31: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id F3ECB37B423 for ; Fri, 29 Sep 2000 00:31:00 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8T7Uvf27888; Fri, 29 Sep 2000 00:30:57 -0700 (PDT) Date: Fri, 29 Sep 2000 00:30:57 -0700 From: Alfred Perlstein To: Thomas David Rivers Cc: freebsd-current@FreeBSD.ORG Subject: Re: interesting problem Message-ID: <20000929003056.A27736@fw.wintelcom.net> References: <20000927183939.B7553@fw.wintelcom.net> <200009281033.GAA42518@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200009281033.GAA42518@lakes.dignus.com>; from rivers@dignus.com on Thu, Sep 28, 2000 at 06:33:03AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Thomas David Rivers [000928 03:34] wrote: > > Alfred, > > Just playing `devils advocate' here. But, in some initial > install situations, exactly how is the user, even the most > knowledgeable one, supposed to do much of anything if the > install itself doesn't work? Not too much chance of building > a kernel, getting a crashdump, etc... I think I just detailed how one could do that in my first two responses. > Although it may be something we want to put off for awhile, > being able to gather debugging information during a failed > install would be rather nice. I'm not sure how this could > happen; perhaps a crashdump to an MSDOS file system (if available)? > Or, straight to a partition with some recovery program that > reads the dump? Or, over a serial line? [Just tossing out ideas.] > Maybe ficl can get involved and manage this? > > I would keep this as one of those "maybe nice to have in the > ideal future" ideas - but it's something to ponder... Yes, it's a very good idea. I've brought up changing the default panic to output a traceback so that the user could post it, but bringing it up is a far cry from implementing it. * even without debug symbols a traceback can be very helpful if one can locate the IP and text addresses of the kernel. However, he shouldn't have been using -current in the first place, and when someone offers to reach out and help it's not the time to get snippy about it. (seriously, refusing to read the handbook?) I've been guilty of this sort of cluelessness and arrogance in the past and I'm glad that a few people came down on me about my attitude while at the same time offering extremely useful advice. Jordan, Mike Smith and John Polstra to name a few, all in one incident actually. I think without their application of knowledge and smack-down I wouldn't have learned nearly as much. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 0:49:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 65E3C37B422 for ; Fri, 29 Sep 2000 00:49:09 -0700 (PDT) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8T7mtU93093; Fri, 29 Sep 2000 00:48:56 -0700 (PDT) (envelope-from jkh@winston.osd.bsdi.com) To: Makoto MATSUSHITA Cc: current@freebsd.org Subject: Re: sysinstall: Avoiding version checking of CD-ROM (patch included) In-Reply-To: Message from Makoto MATSUSHITA of "Wed, 27 Sep 2000 12:57:19 +0900." <20000927125719J.matusita@jp.FreeBSD.org> Date: Fri, 29 Sep 2000 00:48:55 -0700 Message-ID: <93088.970213735@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Speaking about sysinstall, would you please check my PR (bin/21423, > ) ? Done and fixed, thanks! It should be in the next (20000930) -current snapshot in ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/ - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 1:57:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id 1134937B424 for ; Fri, 29 Sep 2000 01:57:40 -0700 (PDT) Received: from castle2.jp.FreeBSD.org (castle2.jp.FreeBSD.org [210.226.20.120]) by updraft.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id RAA65301; Fri, 29 Sep 2000 17:57:33 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by castle2.jp.FreeBSD.org (8.11.0+3.3W/8.11.0) with ESMTP/inet id e8T8vUX27181; Fri, 29 Sep 2000 17:57:31 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: current@freebsd.org In-Reply-To: <93088.970213735@winston.osd.bsdi.com> References: <93088.970213735@winston.osd.bsdi.com> X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.2 (Molpe) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 46 From: Makoto MATSUSHITA To: jkh@winston.osd.bsdi.com Subject: Re: sysinstall: Avoiding version checking of CD-ROM (patch included) Date: Fri, 29 Sep 2000 17:56:06 +0900 Message-Id: <20000929175606Y.matusita@jp.FreeBSD.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG jkh> Done and fixed, thanks! Wow, thank you ^_^ But.. maybe my PR is not clearly described, it does not fix current situation; very sorry for my poor presentations. Here is a current directory structure (just extracted tarballs) of 5-current as of Sep/29/2000. % cd ~ftp/pub/FreeBSD/snapshots/i386/livetree/5-LATEST/ % ls COPYRIGHT cdrom.inf kernel.GENERIC root tmp bin dev mnt sbin usr boot etc proc sys var % ls boot/kernel/kernel* zsh: no matches found: boot/kernel/kernel* % We can easily found that: * Generic kernel is /kernel.GENERIC. (and sysinstall copies /kernel.GENERIC to /kernel when installed) * There is no /boot/kernel/kernel. We cannot boot without kernel:) So, it should be: * Generic kernel go to /boot/kernel directory (I have no idea of about its filename). * After installation, /boot/kernel/kernel exists. To do that, we can: * modify src/release/Makefile to put generic kernel under /boot/kernel. * modify src/release/install.c to copy generic kernel to /boot/kernel/kernel. or, * modify src/release/Makefile to put generic kernel to /boot/kernel/kernel. * modify src/release/install.c, not to do copying generic kernel. (this is done by rev. 1.283) Sorry if I'm wrong, -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 2: 5:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from kbtfw.kubota.co.jp (kbtfw.kubota.co.jp [133.253.102.202]) by hub.freebsd.org (Postfix) with ESMTP id 41EFF37B422 for ; Fri, 29 Sep 2000 02:04:59 -0700 (PDT) Received: by kbtfw.kubota.co.jp; id SAA04453; Fri, 29 Sep 2000 18:04:51 +0900 (JST) Received: from unknown(133.253.122.1) by kbtfw.kubota.co.jp via smap (V4.2) id xma004268; Fri, 29 Sep 00 18:04:37 +0900 Received: from jkpc15.tk.kubota.co.jp ([133.253.157.145]) by kbtmx.eto.kubota.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA13916; Fri, 29 Sep 2000 18:04:37 +0900 (JST) Received: from localhost (localhost.tk.kubota.co.jp [127.0.0.1]) by jkpc15.tk.kubota.co.jp (8.11.0/3.7W-02/21/99) with ESMTP id e8T91GY11658; Fri, 29 Sep 2000 18:01:16 +0900 (JST) To: takawata@shidahara1.planet.sci.kobe-u.ac.jp Cc: current@freebsd.org, acpi-jp@jp.freebsd.org Subject: Re: My system hang with ACPI kernel thread In-Reply-To: <200009280438.NAA63726@shidahara1.planet.sci.kobe-u.ac.jp> References: <20000928101721L.haro@tk.kubota.co.jp> <200009280438.NAA63726@shidahara1.planet.sci.kobe-u.ac.jp> 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: <20000929180116W.haro@tk.kubota.co.jp> Date: Fri, 29 Sep 2000 18:01:16 +0900 From: Munehiro Matsuda X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Takanori Watanabe Date: Thu, 28 Sep 2000 13:38:57 +0900 ::>With the addition of ACPI kernel thread, my system hangs in about ::>10 miniutes use after boot up. By disabling kernel thread, system ::>runs just fine. ::> ::>Do you have any idea where to look at? ::>I'll try and see what I can do myself. :: ::Please set debug.aml_debug and debug.acpi_debug to 1 and ::see what will happen. I'm sorry, there was a fault on my side. I had old /modules directory (Pre SMPng patch), and for some reason if enabled ACPI kernel thread, system hang. I've removed everything under /modules and system seems to be happy! So sorry for the false alarm. Haro =------------------------------------------------------------------------------ _ _ 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 Fri Sep 29 2:23: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 4B05737B422 for ; Fri, 29 Sep 2000 02:16:18 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8T9GmA04415; Fri, 29 Sep 2000 02:16:48 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009290916.e8T9GmA04415@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Munehiro Matsuda Cc: takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.freebsd.org Subject: ACPI megapatch Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_294820930" Date: Fri, 29 Sep 2000 02:16:48 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multipart MIME message. --==_Exmh_294820930 Content-Type: text/plain; charset=us-ascii Here's the latest ACPI megapatch: - Move all the register I/O into a separate file - Made all the I/O spaces use proper bus resources - Allocate the resources in machine-dependant code - Map ACPI-used memory in machine-dependant code - Create a machine-dependant "acpiprobe" device which just knows how to find and set up ACPI for the machine-independant code - Remove all the ACPI #ifdefs from non-ACPI code - Minor style and commenting fixes Issues outstanding: - Need to remove superfluous headers - Need to decide the correct split between and in terms of functionality. Comments, etc. all welcome as usual. --==_Exmh_294820930 Content-Type: text/plain ; name="acpi.diff"; charset=us-ascii Content-Description: acpi.diff Content-Disposition: attachment; filename="acpi.diff" Index: conf/files =================================================================== RCS file: /host/fs/local0/cvs/src/sys/conf/files,v retrieving revision 1.416 diff -u -r1.416 files --- conf/files 2000/09/23 22:21:39 1.416 +++ conf/files 2000/09/27 10:17:04 @@ -75,7 +75,8 @@ #dev/aac/aac_debug.c optional aac dev/aac/aac_disk.c optional aac dev/aac/aac_pci.c optional aac pci -dev/acpi/acpi.c count acpi +dev/acpi/acpi.c optional acpi +dev/acpi/acpi_io.c optional acpi dev/acpi/acpi_powerres.c optional acpi dev/acpi/aml/aml_amlmem.c optional acpi dev/acpi/aml/aml_common.c optional acpi Index: dev/acpi/acpi.c =================================================================== RCS file: /host/fs/local0/cvs/src/sys/dev/acpi/acpi.c,v retrieving revision 1.14 diff -u -r1.14 acpi.c --- dev/acpi/acpi.c 2000/09/27 05:43:53 1.14 +++ dev/acpi/acpi.c 2000/09/29 07:54:01 @@ -52,7 +52,6 @@ #include #include - #include /* for softc */ #include @@ -63,38 +62,14 @@ #include #include -#include /* for ACPI_BUS_SPACE_IO */ - -/* - * ACPI pmap subsystem - */ -#define ACPI_SMAP_MAX_SIZE 16 - -struct ACPIaddr { - int entries; - struct { - vm_offset_t pa_base; - vm_offset_t va_base; - vm_size_t size; - u_int32_t type; - } t [ACPI_SMAP_MAX_SIZE]; -}; - -static void acpi_pmap_init(void); -static void acpi_pmap_release(void); -static vm_offset_t acpi_pmap_ptv(vm_offset_t pa); -static vm_offset_t acpi_pmap_vtp(vm_offset_t va); -static void acpi_free(struct acpi_softc *sc); /* * These items cannot be in acpi_softc because they are be initialized * before probing for the device. */ -static struct ACPIaddr acpi_addr; +struct ACPIaddr acpi_addr; struct ACPIrsdp *acpi_rsdp; -static int acpi_port; -static int acpi_irq; /* Character device */ @@ -122,32 +97,8 @@ }; /* - * ACPI register I/O + * Miscellaneous utility functions */ -#define ACPI_REGISTER_INPUT 0 -#define ACPI_REGISTER_OUTPUT 1 -static void acpi_register_input(u_int32_t ioaddr, - u_int32_t *value, u_int32_t size); -static void acpi_register_output(u_int32_t ioaddr, - u_int32_t *value, u_int32_t size); -static void acpi_enable_disable(acpi_softc_t *sc, boolean_t enable); -static void acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io, - u_int32_t *a, u_int32_t *b); -static void acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io, - u_int32_t *a, u_int32_t *b); -static void acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io, - u_int32_t *a, u_int32_t *b); -static void acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val); -static void acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val); - -/* - * Miscellous utility functions - */ -static int acpi_sdt_checksum(struct ACPIsdt * sdt); static void acpi_handle_dsdt(acpi_softc_t *sc); static void acpi_handle_facp(acpi_softc_t *sc, struct ACPIsdt *facp); static int acpi_handle_rsdt(acpi_softc_t *sc); @@ -164,8 +115,7 @@ /* * ACPI events */ -static void acpi_process_event(acpi_softc_t *sc, - u_int32_t status_a, u_int32_t status_b, +static void acpi_process_event(acpi_softc_t *sc, u_int32_t status_e, u_int32_t status_0, u_int32_t status_1); static void acpi_intr(void *data); static void acpi_enable_events(acpi_softc_t *sc); @@ -174,22 +124,22 @@ /* * Bus interface */ -static int acpi_send_pm_event(acpi_softc_t *sc, u_int8_t state); -static void acpi_identify(driver_t *driver, device_t parent); static int acpi_probe(device_t dev); static int acpi_attach(device_t dev); +static void acpi_free(struct acpi_softc *sc); /* * Event thread */ +static int acpi_send_pm_event(acpi_softc_t *sc, u_int8_t state); static void acpi_event_thread(void *); static void acpi_start_threads(void *); /* for debugging */ #ifdef ACPI_DEBUG -static int acpi_debug = 1; +int acpi_debug = 1; #else /* !ACPI_DEBUG */ -static int acpi_debug = 0; +int acpi_debug = 0; #endif /* ACPI_DEBUG */ SYSCTL_INT(_debug, OID_AUTO, acpi_debug, CTLFLAG_RW, &acpi_debug, 1, ""); @@ -197,9 +147,8 @@ /* * ACPI pmap subsystem */ - void -acpi_init_addr_range() +acpi_init_addr_range(void) { acpi_addr.entries = 0; } @@ -238,35 +187,7 @@ acpi_addr.entries++; } -static void -acpi_pmap_init() -{ - int i; - vm_offset_t va; - - for (i = 0; i < acpi_addr.entries; i++) { - va = (vm_offset_t) pmap_mapdev(acpi_addr.t[i].pa_base, - acpi_addr.t[i].size); - acpi_addr.t[i].va_base = va; - ACPI_DEBUGPRINT("ADDR RANGE %x %x (mapped 0x%x)\n", - acpi_addr.t[i].pa_base, acpi_addr.t[i].size, va); - } -} - -static void -acpi_pmap_release() -{ -#if 0 - int i; - - for (i = 0; i < acpi_addr.entries; i++) { - pmap_unmapdev(acpi_addr.t[i].va_base, acpi_addr.t[i].size); - } - acpi_addr.entries = 0; -#endif -} - -static vm_offset_t +vm_offset_t acpi_pmap_ptv(vm_offset_t pa) { int i; @@ -284,7 +205,7 @@ return (va); } -static vm_offset_t +vm_offset_t acpi_pmap_vtp(vm_offset_t va) { int i; @@ -302,366 +223,10 @@ return (pa); } -/* - * ACPI Register I/O - */ -void -acpi_gpe_enable_bit(acpi_softc_t *sc, u_int32_t bit, boolean_t on_off) -{ - int x; - u_int32_t pos, value; - void (*GPEx_EN[])(acpi_softc_t *, boolean_t, u_int32_t *) = { - acpi_io_gpe0_enable, - acpi_io_gpe0_enable - }; - - x = -1; - pos = bit; - if (bit < sc->facp_body->gpe0_len * 4) { - x = 0; - } else { - /* should we check gpe1_len too? */ - pos = bit - sc->facp_body->gpe1_base; - x = 1; - } - - if (x == -1 || (on_off != 0 && on_off != 1)) { - return; - } - - GPEx_EN[x](sc, ACPI_REGISTER_INPUT, &value); - value = (value & (~(1 << pos))) | (on_off << pos); - GPEx_EN[x](sc, ACPI_REGISTER_OUTPUT, &value); -} - -static __inline void -acpi_register_input(u_int32_t ioaddr, u_int32_t *value, u_int32_t size) -{ - bus_space_tag_t bst; - bus_space_handle_t bsh; - u_int32_t val; - - bst = ACPI_BUS_SPACE_IO; - bsh = ioaddr; - - switch (size) { - case 1: - val = bus_space_read_1(bst, bsh, 0); - break; - case 2: - val = bus_space_read_2(bst, bsh, 0); - break; - case 3: - val = bus_space_read_4(bst, bsh, 0); - val &= 0x00ffffff; - break; - case 4: - val = bus_space_read_4(bst, bsh, 0); - break; - default: - ACPI_DEVPRINTF("acpi_register_input(): invalid size\n"); - val = 0; - break; - } - - *value = val; -} - -static __inline void -acpi_register_output(u_int32_t ioaddr, u_int32_t *value, u_int32_t size) -{ - bus_space_tag_t bst; - bus_space_handle_t bsh; - u_int32_t val; - - val = *value; - bst = ACPI_BUS_SPACE_IO; - bsh = ioaddr; - - switch (size) { - case 1: - bus_space_write_1(bst, bsh, 0, val & 0xff); - break; - case 2: - bus_space_write_2(bst, bsh, 0, val & 0xffff); - break; - case 3: - bus_space_write_2(bst, bsh, 0, val & 0xffff); - bus_space_write_1(bst, bsh, 2, (val >> 16) & 0xff); - break; - case 4: - bus_space_write_4(bst, bsh, 0, val); - break; - default: - ACPI_DEVPRINTF("acpi_register_output(): invalid size\n"); - break; - } -} - -static void -acpi_enable_disable(acpi_softc_t *sc, boolean_t enable) -{ - u_char val; - bus_space_tag_t bst; - bus_space_handle_t bsh; - struct FACPbody *facp; - - facp = sc->facp_body; - bst = ACPI_BUS_SPACE_IO; - bsh = facp->smi_cmd; - - if (enable) { - val = facp->acpi_enable; - } else { - val = facp->acpi_disable; - } - - bus_space_write_1(bst, bsh, 0, val); - sc->enabled = enable; - - ACPI_DEBUGPRINT("acpi_enable_disable(%d) = (%x)\n", enable, val); -} - -static void -acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *status_a, - u_int32_t *status_b) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->pm1_evt_len / 2; - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm1a_evt_blk, status_a, size); - - *status_b = 0; - if (facp->pm1b_evt_blk) { - acpi_register_input(facp->pm1b_evt_blk, status_b, size); - } - } else { - acpi_register_output(facp->pm1a_evt_blk, status_a, size); - - if (facp->pm1b_evt_blk) { - acpi_register_output(facp->pm1b_evt_blk, status_b, size); - } - } - - ACPI_DEBUGPRINT("acpi_io_pm1_status(%d) = (%x, %x)\n", - io, *status_a, *status_b); - - return; -} - -static void -acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *status_a, - u_int32_t *status_b) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->pm1_evt_len / 2; - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm1a_evt_blk + size, status_a, size); - - *status_b = 0; - if (facp->pm1b_evt_blk) { - acpi_register_input(facp->pm1b_evt_blk + size, - status_b, size); - } - } else { - acpi_register_output(facp->pm1a_evt_blk + size, status_a, size); - - if (facp->pm1b_evt_blk) { - acpi_register_output(facp->pm1b_evt_blk + size, - status_b, size); - } - } - - ACPI_DEBUGPRINT("acpi_io_pm1_enable(%d) = (%x, %x)\n", - io, *status_a, *status_b); - - return; -} - -static void -acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io, u_int32_t *value_a, - u_int32_t *value_b) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->pm1_cnt_len; - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm1a_cnt_blk, value_a, size); - - *value_b = 0; - if (facp->pm1b_evt_blk) { - acpi_register_input(facp->pm1b_cnt_blk, value_b, size); - } - } else { - acpi_register_output(facp->pm1a_cnt_blk, value_a, size); - - if (facp->pm1b_evt_blk) { - acpi_register_output(facp->pm1b_cnt_blk, value_b, size); - } - } - - ACPI_DEBUGPRINT("acpi_io_pm1_control(%d) = (%x, %x)\n", - io, *value_a, *value_b); - - return; -} - -static void -acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->pm2_cnt_len; - - if (!facp->pm2_cnt_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm2_cnt_blk, val, size); - } else { - acpi_register_output(facp->pm2_cnt_blk, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_pm2_control(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = 0x4; /* 32-bits */ - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->pm_tmr_blk, val, size); - } else { - return; /* XXX read-only */ - } - - ACPI_DEBUGPRINT("acpi_io_pm_timer(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->gpe0_len / 2; - - if (!facp->gpe0_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->gpe0_blk, val, size); - } else { - acpi_register_output(facp->gpe0_blk, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_gpe0_status(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->gpe0_len / 2; - - if (!facp->gpe0_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->gpe0_blk + size, val, size); - } else { - acpi_register_output(facp->gpe0_blk + size, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_gpe0_enable(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->gpe1_len / 2; - - if (!facp->gpe1_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->gpe1_blk, val, size); - } else { - acpi_register_output(facp->gpe1_blk, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_gpe1_status(%d) = (%x)\n", io, *val); - - return; -} - -static void -acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val) -{ - int size; - struct FACPbody *facp; - - facp = sc->facp_body; - size = facp->gpe1_len / 2; - - if (!facp->gpe1_blk) { - return; /* optional */ - } - - if (io == ACPI_REGISTER_INPUT) { - acpi_register_input(facp->gpe1_blk + size, val, size); - } else { - acpi_register_output(facp->gpe1_blk + size, val, size); - } - - ACPI_DEBUGPRINT("acpi_io_gpe1_enable(%d) = (%x)\n", io, *val); - - return; -} - /* - * Miscellous utility functions + * Miscellaneous utility functions */ - -static int +int acpi_sdt_checksum(struct ACPIsdt *sdt) { u_char cksm, *ckbf; @@ -769,10 +334,6 @@ /* * Handle the FACP. - * - * In the special case where sc is NULL, we are just trying to set acpi_port - * and acpi_irq, so don't try to do anything to the softc, and return as soon - * as we have worked them out. */ static void acpi_handle_facp(acpi_softc_t *sc, struct ACPIsdt *facp) @@ -781,16 +342,8 @@ struct FACPbody *body; struct FACS *facs; - body = (struct FACPbody *)facp->body; - - /* in discovery mode, we have everything we need now */ - if (sc == NULL) { - acpi_port = body->smi_cmd; - acpi_irq = body->sci_int; - return; - } - ACPI_DEBUGPRINT(" FACP found\n"); + body = (struct FACPbody *)facp->body; sc->facp = facp; sc->facp_body = body; sc->dsdt = NULL; @@ -824,9 +377,6 @@ /* * Handle the RSDT. - * - * In the special case where sc is NULL, we are just trying to set acpi_port - * and acpi_irq, so don't try to do anything to the softc. */ static int acpi_handle_rsdt(acpi_softc_t *sc) @@ -847,8 +397,7 @@ ACPI_DEVPRINTF("RSDT is broken\n"); return (-1); } - if (sc != NULL) - sc->rsdt = rsdt; + sc->rsdt = rsdt; entries = (rsdt->len - SIZEOF_SDT_HDR) / sizeof(u_int32_t); ACPI_DEBUGPRINT("RSDT have %d entries\n", entries); ptrs = (u_int32_t *) & rsdt->body; @@ -864,7 +413,6 @@ acpi_handle_facp(sc, sdt); } } - return (0); } @@ -887,18 +435,16 @@ if (state > ACPI_S_STATE_S0) { /* clear WAK_STS bit by writing a one */ - acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &val_a, &val_b); - if ((val_a | val_b) & ACPI_PM1_WAK_STS) { + acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &val_a); + if (val_a & ACPI_PM1_WAK_STS) { sc->broken_wakeuplogic = 0; } else { ACPI_DEVPRINTF("wake-up logic seems broken, " "this may cause troubles on wakeup\n"); sc->broken_wakeuplogic = 1; } - val_a = val_b = 0; val_a = ACPI_PM1_WAK_STS; - val_b = ACPI_PM1_WAK_STS; - acpi_io_pm1_status(sc, ACPI_REGISTER_OUTPUT, &val_a, &val_b); + acpi_io_pm1_status(sc, ACPI_REGISTER_OUTPUT, &val_a); /* ignore power button and sleep button events for 5 sec. */ sc->ignore_events = ACPI_PM1_PWRBTN_EN | ACPI_PM1_SLPBTN_EN; @@ -926,8 +472,8 @@ count = 0; for (;;) { - acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &val_a, &val_b); - if ((val_a | val_b) & ACPI_PM1_WAK_STS) { + acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &val_a); + if (val_a & ACPI_PM1_WAK_STS) { break; } /* XXX @@ -1072,12 +618,12 @@ */ static void -acpi_process_event(acpi_softc_t *sc, u_int32_t status_a, u_int32_t status_b, +acpi_process_event(acpi_softc_t *sc, u_int32_t status_e, u_int32_t status_0, u_int32_t status_1) { int i; - if (status_a & ACPI_PM1_PWRBTN_EN || status_b & ACPI_PM1_PWRBTN_EN) { + if (status_e & ACPI_PM1_PWRBTN_EN) { if (sc->ignore_events & ACPI_PM1_PWRBTN_EN) { ACPI_DEBUGPRINT("PWRBTN event ingnored\n"); } else { @@ -1094,7 +640,7 @@ } } - if (status_a & ACPI_PM1_SLPBTN_EN || status_b & ACPI_PM1_SLPBTN_EN) { + if (status_e & ACPI_PM1_SLPBTN_EN) { if (sc->ignore_events & ACPI_PM1_SLPBTN_EN) { ACPI_DEBUGPRINT("SLPBTN event ingnored\n"); } else { @@ -1117,9 +663,9 @@ static void acpi_intr(void *data) { - u_int32_t enable_a, enable_b, enable_0, enable_1; - u_int32_t status_a, status_b, status_0, status_1; - u_int32_t val_a, val_b; + u_int32_t enable; + u_int32_t status_e, status_0, status_1; + u_int32_t val; int debug; acpi_softc_t *sc; @@ -1130,35 +676,32 @@ /* * Power Management 1 Status Registers */ - status_a = status_b = enable_a = enable_b = 0; - acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); + status_e = enable = 0; + acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &status_e); /* * Get current interrupt mask */ - acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &enable_a, &enable_b); + acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &enable); /* * Disable events and re-enable again */ - if ((status_a & enable_a) != 0 || (status_b & enable_b) != 0) { + if ((status_e & enable) != 0) { acpi_debug = debug; /* OK, you can speak */ ACPI_DEBUGPRINT("pm1_status intr CALLED\n"); /* Disable all interrupt generation */ - val_a = enable_a & (~ACPI_PM1_ALL_ENABLE_BITS); - val_b = enable_b & (~ACPI_PM1_ALL_ENABLE_BITS); - acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &val_a, &val_b); + val = enable & (~ACPI_PM1_ALL_ENABLE_BITS); + acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &val); /* Clear interrupt status */ - val_a = enable_a & ACPI_PM1_ALL_ENABLE_BITS; - val_b = enable_b & ACPI_PM1_ALL_ENABLE_BITS; - acpi_io_pm1_status(sc, ACPI_REGISTER_OUTPUT, &val_a, &val_b); + val = enable & ACPI_PM1_ALL_ENABLE_BITS; + acpi_io_pm1_status(sc, ACPI_REGISTER_OUTPUT, &val); /* Re-enable interrupt */ - acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, - &enable_a, &enable_b); + acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &enable); acpi_debug = 0; /* Shut up again */ } @@ -1166,36 +709,36 @@ /* * General-Purpose Events 0 Status Registers */ - status_0 = enable_0 = 0; + status_0 = enable = 0; acpi_io_gpe0_status(sc, ACPI_REGISTER_INPUT, &status_0); /* * Get current interrupt mask */ - acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &enable_0); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &enable); /* * Disable events and re-enable again */ - if ((status_0 & enable_0) != 0) { + if ((status_0 & enable) != 0) { acpi_debug = debug; /* OK, you can speak */ ACPI_DEBUGPRINT("gpe0_status intr CALLED\n"); /* Disable all interrupt generation */ - val_a = enable_0 & ~status_0; + val = enable & ~status_0; #if 0 /* or should we disable all? */ - val_a = 0x0; + val = 0x0; #endif - acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &val_a); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &val); #if 0 /* Clear interrupt status */ - val_a = enable_0; /* XXX */ - acpi_io_gpe0_status(sc, ACPI_REGISTER_OUTPUT, &val_a); + val = enable; /* XXX */ + acpi_io_gpe0_status(sc, ACPI_REGISTER_OUTPUT, &val); /* Re-enable interrupt */ - acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &enable_0); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &enable); acpi_debug = 0; /* Shut up again */ #endif @@ -1204,36 +747,36 @@ /* * General-Purpose Events 1 Status Registers */ - status_1 = enable_1 = 0; + status_1 = enable = 0; acpi_io_gpe1_status(sc, ACPI_REGISTER_INPUT, &status_1); /* Get current interrupt mask */ - acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &enable_1); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &enable); /* * Disable events and re-enable again */ - if ((status_1 & enable_1) != 0) { + if ((status_1 & enable) != 0) { acpi_debug = debug; /* OK, you can speak */ ACPI_DEBUGPRINT("gpe1_status intr CALLED\n"); /* Disable all interrupt generation */ - val_a = enable_1 & ~status_1; + val = enable & ~status_1; #if 0 /* or should we disable all? */ - val_a = 0x0; + val = 0x0; #endif - acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &val_a); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &val); /* Clear interrupt status */ - val_a = enable_1; /* XXX */ - acpi_io_gpe1_status(sc, ACPI_REGISTER_OUTPUT, &val_a); + val = enable; /* XXX */ + acpi_io_gpe1_status(sc, ACPI_REGISTER_OUTPUT, &val); /* Re-enable interrupt */ - acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &enable_1); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &enable); acpi_debug = 0; /* Shut up again */ } @@ -1241,7 +784,7 @@ acpi_debug = debug; /* Restore debug level */ /* do something to handle the events... */ - acpi_process_event(sc, status_a, status_b, status_0, status_1); + acpi_process_event(sc, status_e, status_0, status_1); } static int acpi_set_gpe_bits(struct aml_name *name, va_list ap) @@ -1270,24 +813,23 @@ static void acpi_enable_events(acpi_softc_t *sc) { - u_int32_t status_a, status_b; + u_int32_t status; + u_int32_t mask0, mask1; u_int32_t flags; /* * Setup PM1 Enable Registers Fixed Feature Enable Bits (4.7.3.1.2) * based on flags field of Fixed ACPI Description Table (5.2.5). */ - acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); + acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &status); flags = sc->facp_body->flags; if ((flags & ACPI_FACP_FLAG_PWR_BUTTON) == 0) { - status_a |= ACPI_PM1_PWRBTN_EN; - status_b |= ACPI_PM1_PWRBTN_EN; + status |= ACPI_PM1_PWRBTN_EN; } if ((flags & ACPI_FACP_FLAG_SLP_BUTTON) == 0) { - status_a |= ACPI_PM1_SLPBTN_EN; - status_b |= ACPI_PM1_SLPBTN_EN; + status |= ACPI_PM1_SLPBTN_EN; } - acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &status_a, &status_b); + acpi_io_pm1_enable(sc, ACPI_REGISTER_OUTPUT, &status); #if 1 /* @@ -1296,26 +838,26 @@ * \_GPE scope (4.7.2.2.1.2). */ - status_a = status_b = 0; + mask0 = mask1 = 0; aml_apply_foreach_found_objects(NULL, "\\_GPE._L", acpi_set_gpe_bits, - sc, &status_a, &status_b); - sc->gpe0_mask = status_a; - sc->gpe1_mask = status_b; + sc, &mask0, &mask1); /* XXX correct? */ + sc->gpe0_mask = mask0; + sc->gpe1_mask = mask1; - acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &status_a); - acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &status_b); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &mask0); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &mask1); #endif /* print all event status for debugging */ - acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); - acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); - acpi_io_gpe0_status(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_gpe1_status(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_pm1_control(sc, ACPI_REGISTER_INPUT, &status_a, &status_b); - acpi_io_pm2_control(sc, ACPI_REGISTER_INPUT, &status_a); - acpi_io_pm_timer(sc, ACPI_REGISTER_INPUT, &status_a); + acpi_io_pm1_status(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_pm1_enable(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_gpe0_status(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_gpe1_status(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_pm1_control(sc, ACPI_REGISTER_INPUT, &mask0, &mask1); + acpi_io_pm2_control(sc, ACPI_REGISTER_INPUT, &status); + acpi_io_pm_timer(sc, ACPI_REGISTER_INPUT, &status); } static void @@ -1396,7 +938,6 @@ /* * Bus interface */ - static devclass_t acpi_devclass; static int @@ -1424,39 +965,6 @@ return (error); } -static void -acpi_identify(driver_t *driver, device_t parent) -{ - device_t child; - - /* - * If the MD code hasn't detected an RSDT, or there has already - * been an 'acpi' device instantiated, give up now. - */ - if ((acpi_rsdp == NULL) || (device_find_child(parent, "acpi", 0))) - return; - - /* - * Handle enough of the RSDT to work out what our I/O resources - * are. - */ - acpi_pmap_init(); - if (acpi_handle_rsdt(NULL)) - return; - - /* - * Create the device and establish its resources. - */ - if ((child = BUS_ADD_CHILD(parent, 101, "acpi", 0)) == NULL) { - device_printf(parent, "could not attach ACPI\n"); - return; - } - if (acpi_port != 0) - bus_set_resource(child, SYS_RES_IOPORT, 0, acpi_port, 1); - if (acpi_irq != 0) - bus_set_resource(child, SYS_RES_IRQ, 0, acpi_irq, 1); -} - static int acpi_probe(device_t dev) { @@ -1485,6 +993,7 @@ acpi_attach(device_t dev) { acpi_softc_t *sc; + int i; /* * Set up the softc and parse the ACPI data completely. @@ -1498,12 +1007,16 @@ /* * Allocate our resources */ - sc->port_rid = 0; - if ((sc->port = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, - 0, ~0, 1, RF_ACTIVE)) == NULL) { - ACPI_DEVPRINTF("could not allocate port\n"); - acpi_free(sc); - return(ENOMEM); + for (i = 0; i < ACPI_RES_MAX; i++) { + sc->iores[i].rid = i; + sc->iores[i].rsc = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->iores[i].rid, + 0, ~0, 1, RF_ACTIVE); + if (sc->iores[i].rsc != NULL) { + sc->iores[i].bhandle = rman_get_bushandle(sc->iores[i].rsc); + sc->iores[i].btag = rman_get_bustag(sc->iores[i].rsc); + } else { + /* XXX barf on mandatory resources missing */ + } } sc->irq_rid = 0; if ((sc->irq = bus_alloc_resource(dev, SYS_RES_IRQ, &sc->irq_rid, @@ -1535,8 +1048,6 @@ EVENTHANDLER_REGISTER(shutdown_final, acpi_soft_off, sc, SHUTDOWN_PRI_LAST); - acpi_pmap_release(); - sc->dev_t = make_dev(&acpi_cdevsw, 0, 0, 5, 0660, "acpi"); sc->dev_t->si_drv1 = sc; @@ -1564,13 +1075,20 @@ static void acpi_free(struct acpi_softc *sc) { - if (sc->port != NULL) - bus_release_resource(sc->dev, SYS_RES_IOPORT, sc->port_rid, sc->port); + int i; + + for (i = 0; i < ACPI_RES_MAX; i++) { + if (sc->iores[i].rsc != NULL) { + bus_release_resource(sc->dev, + SYS_RES_IOPORT, + sc->iores[i].rid, + sc->iores[1].rsc); + } + } if (sc->irq_handle != NULL) bus_teardown_intr(sc->dev, sc->irq, sc->irq_handle); if (sc->irq != NULL) bus_release_resource(sc->dev, SYS_RES_IRQ, sc->irq_rid, sc->irq); - acpi_pmap_release(); } static int @@ -1589,7 +1107,6 @@ static device_method_t acpi_methods[] = { /* Device interface */ - DEVMETHOD(device_identify, acpi_identify), DEVMETHOD(device_probe, acpi_probe), DEVMETHOD(device_attach, acpi_attach), DEVMETHOD(device_resume, acpi_resume), @@ -1697,7 +1214,10 @@ void acpi_start_threads(void *arg) { acpi_softc_t *sc = devclass_get_softc(acpi_devclass, 0); - device_t dev = devclass_get_device(acpi_devclass, 0); + + /* check to see that we were attached */ + if (sc == NULL) + return; ACPI_DEBUGPRINT("start thread\n"); if (kthread_create(acpi_event_thread, sc, &sc->acpi_thread, 0, "acpi")) { @@ -1706,6 +1226,3 @@ } SYSINIT(acpi, SI_SUB_KTHREAD_IDLE, SI_ORDER_ANY, acpi_start_threads, 0); - - - Index: dev/acpi/acpi.h =================================================================== RCS file: /host/fs/local0/cvs/src/sys/dev/acpi/acpi.h,v retrieving revision 1.10 diff -u -r1.10 acpi.h --- dev/acpi/acpi.h 2000/09/27 05:43:54 1.10 +++ dev/acpi/acpi.h 2000/09/29 07:15:30 @@ -92,15 +92,37 @@ int ae_arg; }; +/* + * I/O resource structure + */ + +#define ACPI_RES_SMI_CMD 0 +#define ACPI_RES_PM1A_EVT 1 +#define ACPI_RES_PM1B_EVT 2 +#define ACPI_RES_PM1A_CNT 3 +#define ACPI_RES_PM1B_CNT 4 +#define ACPI_RES_PM2_CNT 5 +#define ACPI_RES_PM_TMR 6 +#define ACPI_RES_GPE0 7 +#define ACPI_RES_GPE1 8 +#define ACPI_RES_MAX 9 + +struct acpi_io_resource { + struct resource *rsc; + int rid; + bus_space_handle_t bhandle; + bus_space_tag_t btag; +}; + /* * Softc -*/ + */ typedef struct acpi_softc { device_t dev; dev_t dev_t; + + struct acpi_io_resource iores[ACPI_RES_MAX]; - struct resource *port; - int port_rid; struct resource *irq; int irq_rid; void *irq_handle; @@ -126,6 +148,23 @@ } acpi_softc_t; /* + * ACPI register I/O + */ +#define ACPI_REGISTER_INPUT 0 +#define ACPI_REGISTER_OUTPUT 1 +extern void acpi_enable_disable(acpi_softc_t *sc, boolean_t enable); +extern void acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *status); +extern void acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *enable); +extern void acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val_a, u_int32_t *val_b); +extern void acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val); +extern void acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val); + + +/* * Device State */ extern u_int8_t acpi_get_current_device_state(struct aml_name *name); @@ -147,7 +186,7 @@ /* * GPE enable bit manipulation */ -extern void acpi_gpe_enable_bit(acpi_softc_t *, u_int32_t, boolean_t); +extern void acpi_gpe_enable_bit(acpi_softc_t *sc, u_int32_t bit, boolean_t on_off); /* * Event queue @@ -155,6 +194,29 @@ extern void acpi_queue_event(acpi_softc_t *sc, int type, int arg); /* + * ACPI pmap subsystem + */ +#define ACPI_SMAP_MAX_SIZE 16 + +struct ACPIaddr { + int entries; + struct { + vm_offset_t pa_base; + vm_offset_t va_base; + vm_size_t size; + u_int32_t type; + } t [ACPI_SMAP_MAX_SIZE]; +}; + +extern struct ACPIaddr acpi_addr; +extern struct ACPIrsdp *acpi_rsdp; /* ACPI Root System Description Table */ +extern void acpi_init_addr_range(void); +extern void acpi_register_addr_range(u_int64_t base, u_int64_t size, u_int32_t type); +extern int acpi_sdt_checksum(struct ACPIsdt * sdt); +extern vm_offset_t acpi_pmap_ptv(vm_offset_t pa); +extern vm_offset_t acpi_pmap_vtp(vm_offset_t va); + +/* * Debugging, console output * * XXX this should really be using device_printf @@ -164,3 +226,5 @@ #define ACPI_DEBUGPRINT(args...) do { if (acpi_debug) ACPI_DEVPRINTF(args);} while(0) #endif /* !_DEV_ACPI_ACPI_H_ */ + + Index: dev/acpi/acpi_io.c =================================================================== RCS file: acpi_io.c diff -N acpi_io.c --- /dev/null Thu Sep 28 10:32:34 2000 +++ acpi_io.c Fri Sep 29 01:35:14 2000 @@ -0,0 +1,373 @@ +/*- + * Copyright (c) 1999 Takanori Watanabe + * Copyright (c) 1999, 2000 Mitsuru IWASAKI + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $Id: acpi.c,v 1.26 2000/08/15 14:43:43 iwasaki Exp $ + * $FreeBSD: src/sys/dev/acpi/acpi.c,v 1.13 2000/09/27 01:40:47 msmith Exp $ + */ + +#include "opt_acpi.h" +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include /* for EVENTHANDLER_REGISTER */ +#include /* for RB_POWEROFF */ +#include /* for DELAY */ +#include /* for RFSTOPPED*/ +#include /* for kthread stuff*/ +#include + +#include +#include +#include + +#include +#include /* for softc */ + +/* + * ACPI Register I/O + */ +static __inline void +acpi_register_input(acpi_softc_t *sc, int res, int offset, u_int32_t *value, u_int32_t size) +{ + bus_space_tag_t bst; + bus_space_handle_t bsh; + u_int32_t val; + + if (sc->iores[res].rsc == NULL) + return; + + bst = sc->iores[res].btag; + bsh = sc->iores[res].bhandle; + + switch (size) { + case 1: + val = bus_space_read_1(bst, bsh, offset); + break; + case 2: + val = bus_space_read_2(bst, bsh, offset); + break; + case 3: + val = bus_space_read_4(bst, bsh, offset); + val &= 0x00ffffff; + break; + case 4: + val = bus_space_read_4(bst, bsh, offset); + break; + default: + ACPI_DEVPRINTF("acpi_register_input(): invalid size (%d)\n", size); + val = 0; + break; + } + + *value = val; +} + +static __inline void +acpi_register_output(acpi_softc_t *sc, int res, int offset, u_int32_t *value, u_int32_t size) +{ + bus_space_tag_t bst; + bus_space_handle_t bsh; + u_int32_t val; + + if (sc->iores[res].rsc == NULL) + return; + + val = *value; + bst = sc->iores[res].btag; + bsh = sc->iores[res].bhandle; + + switch (size) { + case 1: + bus_space_write_1(bst, bsh, offset, val & 0xff); + break; + case 2: + bus_space_write_2(bst, bsh, offset, val & 0xffff); + break; + case 3: + bus_space_write_2(bst, bsh, offset, val & 0xffff); + bus_space_write_1(bst, bsh, offset + 2, (val >> 16) & 0xff); + break; + case 4: + bus_space_write_4(bst, bsh, offset, val); + break; + default: + ACPI_DEVPRINTF("acpi_register_output(): invalid size\n"); + break; + } +} + +static __inline void +acpi_io_mirreg(acpi_softc_t *sc, boolean_t io, u_int32_t *data, + int res, int altres, int offset, int size) +{ + u_int32_t result; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, res, offset, &result, size); + *data = result; + acpi_register_input(sc, altres, offset, &result, size); + *data |= result; + } else { + acpi_register_output(sc, res, offset, data, size); + acpi_register_output(sc, altres, offset, data, size); + } + + return; +} + +void +acpi_enable_disable(acpi_softc_t *sc, boolean_t enable) +{ + u_int8_t val; + + val = enable ? sc->facp_body->acpi_enable : sc->facp_body->acpi_disable; + bus_space_write_1(sc->iores[ACPI_RES_SMI_CMD].btag, + sc->iores[ACPI_RES_SMI_CMD].bhandle, + 0, val); + sc->enabled = enable; + + ACPI_DEBUGPRINT("acpi_enable_disable(%d) = (%x)\n", enable, val); +} + +void +acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *status) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->pm1_evt_len / 2; + acpi_io_mirreg(sc, io, status, ACPI_RES_PM1A_EVT, ACPI_RES_PM1B_EVT, 0, size); + + ACPI_DEBUGPRINT("acpi_io_pm1_status(%d) = (%x)\n", io, *status); +} + +void +acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *enable) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->pm1_evt_len / 2; + acpi_io_mirreg(sc, io, enable, ACPI_RES_PM1A_EVT, ACPI_RES_PM1B_EVT, size, size); + + ACPI_DEBUGPRINT("acpi_io_pm1_enable(%d) = (%x)\n", io, *enable); +} + +/* + * PM1 is awkward because the SLP_TYP bits are not common between the two registers. + * A better interface than this might pass the SLP_TYP bits separately. + */ +void +acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io, u_int32_t *value_a, u_int32_t *value_b) +{ + struct FACPbody *facp; + u_int32_t result; + + facp = sc->facp_body; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_PM1A_CNT, 0, &result, facp->pm1_cnt_len); + *value_a = result; + acpi_register_input(sc, ACPI_RES_PM1B_CNT, 0, &result, facp->pm1_cnt_len); + *value_a |= result; + *value_a &= ~ACPI_CNT_SLP_TYPX; /* mask the SLP_TYP bits */ + } else { + acpi_register_output(sc, ACPI_RES_PM1A_CNT, 0, value_a, facp->pm1_cnt_len); + acpi_register_output(sc, ACPI_RES_PM1B_CNT, 0, value_b, facp->pm1_cnt_len); + } + + ACPI_DEBUGPRINT("acpi_io_pm1_control(%d) = (%x, %x)\n", io, *value_a, *value_b); +} + +void +acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->pm2_cnt_len; + + if (size == 0) /* port is optional */ + return; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_PM2_CNT, 0, val, size); + } else { + acpi_register_output(sc, ACPI_RES_PM2_CNT, 0, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_pm2_control(%d) = (%x)\n", io, *val); + + return; +} + +void +acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_PM_TMR, 0, val, sizeof(u_int32_t)); + + ACPI_DEBUGPRINT("acpi_io_pm_timer(%d) = (%x)\n", io, *val); + } +} + +void +acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->gpe0_len / 2; + + if (size == 0) /* port is optional */ + return; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_GPE0, 0, val, size); + } else { + acpi_register_output(sc, ACPI_RES_GPE0, 0, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_gpe0_status(%d) = (%x)\n", io, *val); +} + +void +acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->gpe0_len / 2; + + if (size == 0) /* port is optional */ + return; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_GPE0, size, val, size); + } else { + acpi_register_output(sc, ACPI_RES_GPE0, size, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_gpe0_enable(%d) = (%x)\n", io, *val); +} + +void +acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->gpe1_len / 2; + + if (size == 0) /* port is optional */ + return; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_GPE1, 0, val, size); + } else { + acpi_register_output(sc, ACPI_RES_GPE1, 0, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_gpe1_status(%d) = (%x)\n", io, *val); +} + +void +acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val) +{ + int size; + struct FACPbody *facp; + + facp = sc->facp_body; + size = facp->gpe1_len / 2; + + if (size == 0) /* port is optional */ + return; + + if (io == ACPI_REGISTER_INPUT) { + acpi_register_input(sc, ACPI_RES_GPE1, size, val, size); + } else { + acpi_register_output(sc, ACPI_RES_GPE1, size, val, size); + } + + ACPI_DEBUGPRINT("acpi_io_gpe0_enable(%d) = (%x)\n", io, *val); +} + +void +acpi_gpe_enable_bit(acpi_softc_t *sc, u_int32_t bit, boolean_t on_off) +{ + u_int32_t value; + int res; + + /* + * Is the bit in the first GPE port? + */ + if (bit < ((sc->facp_body->gpe0_len / 2) * 8)) { + res = ACPI_RES_GPE0; + } else { + /* + * Is the bit in the second GPE port? + */ + bit -= sc->facp_body->gpe1_base; + if (bit < ((sc->facp_body->gpe1_len / 2) * 8)) { + res = ACPI_RES_GPE1; + } else { + return; /* do nothing */ + } + } + + switch (res) { + case ACPI_RES_GPE0: + acpi_io_gpe0_enable(sc, ACPI_REGISTER_INPUT, &value); + break; + case ACPI_RES_GPE1: + acpi_io_gpe1_enable(sc, ACPI_REGISTER_INPUT, &value); + break; + } + value = (value & ~(1 << bit)) | (on_off ? (1 << bit) : 0); + switch (res) { + case ACPI_RES_GPE0: + acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &value); + break; + case ACPI_RES_GPE1: + acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &value); + break; + } +} + Index: dev/acpi/acpi_powerres.c =================================================================== RCS file: /host/fs/local0/cvs/src/sys/dev/acpi/acpi_powerres.c,v retrieving revision 1.7 diff -u -r1.7 acpi_powerres.c --- dev/acpi/acpi_powerres.c 2000/09/27 05:43:54 1.7 +++ dev/acpi/acpi_powerres.c 2000/09/28 17:37:02 @@ -33,8 +33,11 @@ #include #include -#include +#include +#include +#include +#include #include #include Index: i386/i386/acpi_machdep.c =================================================================== RCS file: /host/fs/local0/cvs/src/sys/i386/i386/acpi_machdep.c,v retrieving revision 1.2 diff -u -r1.2 acpi_machdep.c --- i386/i386/acpi_machdep.c 2000/09/02 15:06:35 1.2 +++ i386/i386/acpi_machdep.c 2000/09/29 08:22:33 @@ -1,5 +1,6 @@ /*- * Copyright (c) 2000 Mitsuru IWASAKI + * Copyright (c) 2000 Michael Smith * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -28,9 +29,273 @@ */ #include "opt_acpi.h" +#include +#include +#include +#include +#include +#include -#include +#include +#include +#include +#include /* for EVENTHANDLER_REGISTER */ +#include /* for RB_POWEROFF */ +#include /* for DELAY */ +#include /* for RFSTOPPED*/ +#include /* for kthread stuff*/ +#include + +#include +#include +#include + +#include +#include /* for softc */ + +#include +#include +#include +#include +#include +#include +#include +#include /* XXX trim includes */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include + + +#include + #ifdef ACPI_NO_OSDFUNC_INLINE #include #endif /* ACPI_NO_OSDFUNC_INLINE */ + +static void acpiprobe_identify(driver_t *driver, device_t parent); +static void acpiprobe_mapmem(void); +static struct FACPbody *acpiprobe_facp(struct ACPIrsdp *rsdp); + + +static device_method_t acpiprobe_methods[] = { + /* Device interface */ + DEVMETHOD(device_identify, acpiprobe_identify), + {0, 0} +}; + +static driver_t acpiprobe_driver = { + "acpiprobe", + acpiprobe_methods, + 0, +}; + +static devclass_t acpiprobe_devclass; +DRIVER_MODULE(acpiprobe, nexus, acpiprobe_driver, acpiprobe_devclass, 0, 0); + +static void +acpiprobe_identify(driver_t *driver, device_t parent) +{ + device_t child; + u_long sigaddr; + struct ACPIrsdp *rsdp; + struct FACPbody *facp; + u_int8_t ck, *cv; + int i; + + /* + * If we've already got ACPI attached somehow, don't try again. + */ + if (device_find_child(parent, "acpi", 0)) { + printf("ACPI: already attached\n"); + return; + } + + /* + * Search for the RSD PTR signature. + */ + if ((sigaddr = bios_sigsearch(0, "RSD PTR ", 8, 16, 0)) == 0) { + printf("ACPI: no support in system\n"); + return; + } + + /* get a virtual pointer to the structure */ + rsdp = (struct ACPIrsdp *)(uintptr_t)BIOS_PADDRTOVADDR(sigaddr); + for (cv = (u_int8_t *)rsdp, ck = 0, i = 0; i < sizeof(struct ACPIrsdp); i++) { + ck += cv[i]; + } + + /* If checksum is OK, attach ACPI */ + if (ck != 0) { + printf("ACPI: Bad ACPI BIOS data checksum\n"); + return; + } + + /* + * Handle enough of the RSDT to work out what our I/O resources are. + */ + acpi_rsdp = rsdp; + acpiprobe_mapmem(); + if ((facp = acpiprobe_facp(rsdp)) == NULL) { + printf("ACPI: can't map RSDT/FACT\n"); + return; + } + + /* + * Create the device and establish its resources. + */ + if ((child = BUS_ADD_CHILD(parent, 101, "acpi", 0)) == NULL) { + device_printf(parent, "ACPI: could not attach child\n"); + return; + } + + /* + * SMI command register + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_SMI_CMD, + facp->smi_cmd, 1); + + /* + * PM1 event registers + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM1A_EVT, + facp->pm1a_evt_blk, facp->pm1_evt_len); + if (facp->pm1b_evt_blk != 0) + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM1B_EVT, + facp->pm1b_evt_blk, facp->pm1_evt_len); + + /* + * PM1 control registers + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM1A_CNT, + facp->pm1a_cnt_blk, facp->pm1_cnt_len); + if (facp->pm1b_cnt_blk != 0) + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM1B_CNT, + facp->pm1b_cnt_blk, facp->pm1_cnt_len); + + /* + * PM2 control register + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM2_CNT, + facp->pm2_cnt_blk, facp->pm2_cnt_len); + + /* + * PM timer register + */ + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_PM_TMR, + facp->pm_tmr_blk, 4); + + /* + * General purpose event registers + */ + if (facp->gpe0_blk != 0) + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_GPE0, + facp->gpe0_blk, facp->gpe0_len); + if (facp->gpe1_blk != 0) + bus_set_resource(child, SYS_RES_IOPORT, ACPI_RES_GPE1, + facp->gpe1_blk, facp->gpe1_len); + + /* + * Notification interrupt + */ + if (facp->sci_int != 0) + bus_set_resource(child, SYS_RES_IRQ, 0, facp->sci_int, 1); +} + +/* + * Find and map all memory regions that are regarded as belonging to ACPI + * and let the MI code know about them. Scan the ACPI memory map as managed + * by the MI code and map it into kernel space. + */ +static void +acpiprobe_mapmem(void) +{ + struct vm86frame vmf; + struct vm86context vmc; + struct bios_smap *smap; + vm_offset_t va; + int i; + + bzero(&vmf, sizeof(struct vm86frame)); + + acpi_init_addr_range(); + + /* + * Scan memory map with INT 15:E820 + */ + vmc.npages = 0; + smap = (void *)vm86_addpage(&vmc, 1, KERNBASE + (1 << PAGE_SHIFT)); + vm86_getptr(&vmc, (vm_offset_t)smap, &vmf.vmf_es, &vmf.vmf_di); + + vmf.vmf_ebx = 0; + do { + vmf.vmf_eax = 0xE820; + vmf.vmf_edx = SMAP_SIG; + vmf.vmf_ecx = sizeof(struct bios_smap); + i = vm86_datacall(0x15, &vmf, &vmc); + if (i || vmf.vmf_eax != SMAP_SIG) + break; + + /* ACPI-owned memory? */ + if (smap->type == 0x03 || smap->type == 0x04) { + acpi_register_addr_range(smap->base, smap->length, smap->type); + } + } while (vmf.vmf_ebx != 0); + + /* + * Map the physical ranges that have been registered into the kernel. + */ + for (i = 0; i < acpi_addr.entries; i++) { + va = (vm_offset_t)pmap_mapdev(acpi_addr.t[i].pa_base, acpi_addr.t[i].size); + acpi_addr.t[i].va_base = va; + } +} + +/* + * Locate the FACP within the mapped ACPI memory. + */ +static struct FACPbody * +acpiprobe_facp(struct ACPIrsdp *rsdp) +{ + u_int32_t *ptrs; + int entries; + int i; + struct ACPIsdt *rsdt, *sdt; + char sigstring[5]; + + rsdt = (struct ACPIsdt *)acpi_pmap_ptv(rsdp->addr); + if (rsdt == NULL) { + ACPI_DEVPRINTF("can't map memory for RSDT"); + return(NULL); + } + if ((strncmp(rsdt->signature, "RSDT", 4) != 0) || + (acpi_sdt_checksum(rsdt) != 0)) { + ACPI_DEVPRINTF("RSDT is broken\n"); + return(NULL); + } + entries = (rsdt->len - SIZEOF_SDT_HDR) / sizeof(u_int32_t); + ptrs = (u_int32_t *)&rsdt->body; + + for (i = 0; i < entries; i++) { + sdt = (struct ACPIsdt *) acpi_pmap_ptv((vm_offset_t) ptrs[i]); + if (strncmp(sdt->signature, "FACP", 4) == 0 && acpi_sdt_checksum(sdt) == 0) { + return((struct FACPbody *)sdt->body); + } + } + return(NULL); +} Index: i386/i386/bios.c =================================================================== RCS file: /host/fs/local0/cvs/src/sys/i386/i386/bios.c,v retrieving revision 1.38 diff -u -r1.38 bios.c --- i386/i386/bios.c 2000/08/31 15:34:54 1.38 +++ i386/i386/bios.c 2000/09/29 05:34:30 @@ -31,7 +31,6 @@ * Code for dealing with the BIOS in x86 PC systems. */ -#include "acpi.h" #include "isa.h" #include @@ -50,10 +49,6 @@ #include #include -#if NACPI > 0 -#include -#endif - #define BIOS_START 0xe0000 #define BIOS_SIZE 0x20000 @@ -148,26 +143,6 @@ printf("pnpbios: Bad PnP BIOS data checksum\n"); } } -#if NACPI > 0 - /* - * ACPI BIOS - * acpi_rsdp is GLOBAL and holds RSD PTR signature - */ - if ((sigaddr = bios_sigsearch(0, "RSD PTR ", 8, 16, 0)) != 0) { - /* get a virtual pointer to the structure */ - acpi_rsdp = (struct ACPIrsdp *)(uintptr_t)BIOS_PADDRTOVADDR(sigaddr); - for (cv = (u_int8_t *)acpi_rsdp, ck = 0, i = 0; i < sizeof(struct ACPIrsdp); i++) { - ck += cv[i]; - } - - /* If checksum is NG, disable it */ - if (ck != 0) { - printf("ACPI: Bad ACPI BIOS data checksum\n"); - acpi_rsdp=NULL;/* 0xa0000<=RSD_PTR<0x100000*/ - } - } -#endif - if (bootverbose) { /* look for other know signatures */ printf("Other BIOS signatures found:\n"); Index: i386/i386/machdep.c =================================================================== RCS file: /host/fs/local0/cvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.411 diff -u -r1.411 machdep.c --- i386/i386/machdep.c 2000/09/22 23:39:50 1.411 +++ i386/i386/machdep.c 2000/09/29 07:21:34 @@ -37,7 +37,6 @@ * from: @(#)machdep.c 7.4 (Berkeley) 6/3/91 * $FreeBSD: src/sys/i386/i386/machdep.c,v 1.411 2000/09/22 23:39:50 ps Exp $ */ -#include "acpi.h" #include "apm.h" #include "npx.h" #include "opt_atalk.h" @@ -100,6 +99,7 @@ #include #include #include +#include #include /* pcb.h included via sys/user.h */ #include #include @@ -120,10 +120,6 @@ #include #include -#if NACPI > 0 -#include -#endif - extern void init386 __P((int first)); extern void dblfault_handler __P((void)); @@ -1468,11 +1464,7 @@ vm_offset_t pa, physmap[PHYSMAP_SIZE]; pt_entry_t pte; const char *cp; - struct { - u_int64_t base; - u_int64_t length; - u_int32_t type; - } *smap; + struct bios_smap *smap; bzero(&vmf, sizeof(struct vm86frame)); bzero(physmap, sizeof(physmap)); @@ -1532,22 +1524,16 @@ /* * get memory map with INT 15:E820 */ -#define SMAPSIZ sizeof(*smap) -#define SMAP_SIG 0x534D4150 /* 'SMAP' */ - vmc.npages = 0; smap = (void *)vm86_addpage(&vmc, 1, KERNBASE + (1 << PAGE_SHIFT)); vm86_getptr(&vmc, (vm_offset_t)smap, &vmf.vmf_es, &vmf.vmf_di); -#if NACPI > 0 - acpi_init_addr_range(); -#endif physmap_idx = 0; vmf.vmf_ebx = 0; do { vmf.vmf_eax = 0xE820; vmf.vmf_edx = SMAP_SIG; - vmf.vmf_ecx = SMAPSIZ; + vmf.vmf_ecx = sizeof(struct bios_smap); i = vm86_datacall(0x15, &vmf, &vmc); if (i || vmf.vmf_eax != SMAP_SIG) break; @@ -1558,13 +1544,7 @@ (u_int32_t)smap->base, *(u_int32_t *)((char *)&smap->length + 4), (u_int32_t)smap->length); -#if NACPI > 0 - /* Save ACPI related memory Info */ - if (smap->type == 0x03 || smap->type == 0x04) { - acpi_register_addr_range(smap->base, - smap->length, smap->type); - } -#endif + if (smap->type != 0x01) goto next_run; Index: i386/include/pc/bios.h =================================================================== RCS file: /host/fs/local0/cvs/src/sys/i386/include/pc/bios.h,v retrieving revision 1.8 diff -u -r1.8 bios.h --- i386/include/pc/bios.h 2000/04/16 20:48:31 1.8 +++ i386/include/pc/bios.h 2000/09/29 05:46:52 @@ -218,3 +218,16 @@ extern int bios16_call(struct bios_regs *, char *); extern int bios32(struct bios_regs *, u_int, u_short); extern void set_bios_selectors(struct bios_segments *, int); + +/* + * Int 15:E820 'SMAP' structure + * + * XXX add constants for type + */ +#define SMAP_SIG 0x534D4150 /* 'SMAP' */ +struct bios_smap { + u_int64_t base; + u_int64_t length; + u_int32_t type; +} __attribute__ ((packed)); + Index: kern/kern_synch.c =================================================================== RCS file: /host/fs/local0/cvs/src/sys/kern/kern_synch.c,v retrieving revision 1.100 diff -u -r1.100 kern_synch.c --- kern/kern_synch.c 2000/09/24 00:33:51 1.100 +++ kern/kern_synch.c 2000/09/29 07:56:19 @@ -913,9 +913,11 @@ */ microuptime(&new_switchtime); if (timevalcmp(&new_switchtime, &switchtime, <)) { +#if 0 printf("microuptime() went backwards (%ld.%06ld -> %ld.%06ld)\n", switchtime.tv_sec, switchtime.tv_usec, new_switchtime.tv_sec, new_switchtime.tv_usec); +#endif new_switchtime = switchtime; } else { p->p_runtime += (new_switchtime.tv_usec - switchtime.tv_usec) + Index: sys/acpi.h =================================================================== RCS file: /host/fs/local0/cvs/src/sys/sys/acpi.h,v retrieving revision 1.2 diff -u -r1.2 acpi.h --- sys/acpi.h 2000/08/29 20:30:54 1.2 +++ sys/acpi.h 2000/09/29 07:07:48 @@ -33,6 +33,21 @@ #include +/* Generic Address structure */ +struct ACPIgas { + u_int8_t address_space_id; +#define ACPI_GAS_MEMORY 0 +#define ACPI_GAS_IO 1 +#define ACPI_GAS_PCI 2 +#define ACPI_GAS_EMBEDDED 3 +#define ACPI_GAS_SMBUS 4 +#define ACPI_GAS_FIXED 0x7f + u_int8_t register_bit_width; + u_int8_t register_bit_offset; + u_int8_t res; + u_int64_t address; +} __attribute__((packed)); + /* Root System Description Pointer */ struct ACPIrsdp { u_char signature[8]; @@ -96,7 +111,8 @@ u_int8_t day_alrm; u_int8_t mon_alrm; u_int8_t century; - u_char reserved4[3]; + u_int16_t iapc_boot_arch; + u_char reserved4[1]; u_int32_t flags; #define ACPI_FACP_FLAG_WBINVD 1 /* WBINVD is correctly supported */ #define ACPI_FACP_FLAG_WBINVD_FLUSH 2 /* WBINVD flushes caches */ @@ -108,6 +124,19 @@ #define ACPI_FACP_FLAG_RTC_S4 128 /* RTC can wakeup from S4 state */ #define ACPI_FACP_FLAG_TMR_VAL_EXT 256 /* TMR_VAL is 32bit */ #define ACPI_FACP_FLAG_DCK_CAP 512 /* Can support docking */ + struct ACPIgas reset_reg; + u_int8_t reset_value; + u_int8_t reserved5[3]; + u_int64_t x_firmware_ctrl; + u_int64_t x_dsdt; + struct ACPIgas x_pm1a_evt_blk; + struct ACPIgas x_pm1b_evt_blk; + struct ACPIgas x_pm1a_cnt_blk; + struct ACPIgas x_pm1b_cnt_blk; + struct ACPIgas x_pm2_cnt_blk; + struct ACPIgas x_pm_tmr_blk; + struct ACPIgas x_gpe0_blk; + struct ACPIgas x_gpe1_blk; } __attribute__((packed)); /* Firmware ACPI Control Structure */ @@ -186,11 +215,6 @@ } mode[6]; }; #define ACPI_UNSUPPORTSLPTYP 0xff /* unsupported sleeping type */ - -extern struct ACPIrsdp *acpi_rsdp; /* ACPI Root System Description Table */ - -void acpi_init_addr_range(void); -void acpi_register_addr_range(u_int64_t, u_int64_t, u_int32_t); /* * ACPICA compatibility --==_Exmh_294820930 Content-Type: text/plain; charset=us-ascii ... 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 --==_Exmh_294820930-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 2:25:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 0ACF037B43E; Fri, 29 Sep 2000 02:25:09 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8T9Otr33145; Fri, 29 Sep 2000 18:24:55 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: msmith@freebsd.org Cc: iwasaki@jp.FreeBSD.org, takawata@shidahara1.planet.sci.kobe-u.ac.jp, haro@tk.kubota.co.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: My system hang with ACPI kernel thread In-Reply-To: <200009281819.e8SIJhA01660@mass.osd.bsdi.com> References: <20000929023628R.iwasaki@jp.FreeBSD.org> <200009281819.e8SIJhA01660@mass.osd.bsdi.com> <200009290521.e8T5LUA03595@mass.osd.bsdi.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000929182311Q.iwasaki@jp.FreeBSD.org> Date: Fri, 29 Sep 2000 18:23:11 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 128 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Currently kernel thread seems broken, so mallocing storage in > > > > acpi_queue_event() never be freed. I think number of events at a > > > > point of tme is limited and we can have static storage for the events. > > > > The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd) > > > > would be a good example. > > > > > > I have a megapatch for acpi.c that I am nearly ready to commit which > > > converts it to use bus resources for all I/O allocations. I'll fix this > > > in there, if you like. > > > > I'm interested in your patch. Can I see it? > > Sure. I'm not 100% sure it's going to work right, so please feel free > to tell me I've broken something... I've just tried the patch, GREAT! it seems working for me perfectly w/o any functional changes, much better than before. I'll do testing more. I have some comments; # most of them is not related with your patch :-) but I'd like to # consult with you. Can we separate the code which uses FreeBSD specific APIs and structs into a other file or arrange them at one place? Because I'm going to merge NetBSD porting effort, I want to avoid having too many #ifdef __FreeBSD__. The patch is available at http://www.imou.to/~AoiMoe/UNIX-at-Random/acpi/acpi-freebsd-netbsd-changes-2000-09-24.diff.gz Because of above reason, /* * Debugging, console output * * XXX this should really be using device_printf */ extern int acpi_debug; #define ACPI_DEVPRINTF(args...) printf("acpi0: " args) I don't use device_printf() here. # Also we don't have more than 2 instances of acpi :-) static void acpi_trans_sleeping_state(acpi_softc_t *sc, u_int8_t state) : /* XXX should be MI */ /* XXX should always be called with interrupts enabled! */ ef = read_eflags(); disable_intr(); for this, I referred the comments in ACPI spec 7.5.2. // Required environment: Executing on the system boot // processor. All other processors stopped. Interrupts <-- // disabled. All Power Resources (and devices) are in // corresponding device state to support NewState. I don't know much about IA64, I'm not sure {read|write}_eflags() inline functions will be available on IA64. Should we replace them with save_intr() and restore_intr() ? because seems more general. Also we need to consider SMP. There is no hack for it so far. # I think APM BIOS Call need to be executed on the system boot # processor too. acpi_soft_off(void *data, int howto) : /* XXX Disable GPE intrrupt,or power on again in some machine */ acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &vala); acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, &vala); This still give no effect on my PORTEGE. I think this should be done in earlier phase. Maybe we'd better to have acpi_disable_events() and call this at shutdown_pre_sync (or some such) for shutdown -p, also call this in acpi_set_sleeping_state() for power button/acpiconf -s 5. acpi_intr(void *data) : #if 0 /* Clear interrupt status */ val = enable; /* XXX */ acpi_io_gpe0_status(sc, ACPI_REGISTER_OUTPUT, &val); /* Re-enable interrupt */ acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, &enable); acpi_debug = 0; /* Shut up again */ #endif GPE1 too, right? :-) acpi_attach(device_t dev) : sc->iores[i].rsc = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->iores[i].rid, 0, ~0, 1, RF_ACTIVE); ^^ I didn't understand clearly for long time, but this give us more flexibility w/o problems if we call bus_set_resource() and set count correctly, right? #ifndef ACPI_NO_ENABLE_ON_BOOT acpi_enable_disable(sc, 1); acpi_enable_events(sc); acpi_intr((void *)sc); #endif Should we remove them and have acpi_enalbe="YES" in /etc/rc.conf just line APM ? And last thing, how about header file name and location? some poeple suggested that /sys/dev/acpi/acpi.h should be renamed to acpivar.h. And /sys/sys/acpi.h should be moved to /sys/dev/acpi.h (installed in /usr/include/dev/acpi/acpi.h). We didn't care and are not interested in this matter at all so far, but it seems quite reasonable for me and doesn't hurt anything. And *real* last thing :-) msmith> the code in machdep.c. Everything will move to acpi_machdep.c I'll also msmith> be deleting , as it's not necessary (and never was). I think better to wait deleting until IA64 porting. I'm not sure if this file really unnecessary or not. Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 6: 7:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 95CC637B423; Fri, 29 Sep 2000 06:07:35 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8TD7Rr87912; Fri, 29 Sep 2000 22:07:27 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: msmith@freebsd.org Cc: haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.freebsd.org Subject: Re: ACPI megapatch In-Reply-To: <200009290916.e8T9GmA04415@mass.osd.bsdi.com> References: <200009290916.e8T9GmA04415@mass.osd.bsdi.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000929220517P.iwasaki@jp.FreeBSD.org> Date: Fri, 29 Sep 2000 22:05:17 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 58 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks a lot mike, these are mostly acceptable for me. > Here's the latest ACPI megapatch: > > - Move all the register I/O into a separate file Agreed. > - Made all the I/O spaces use proper bus resources > - Allocate the resources in machine-dependant code I prefer previous patch because most of the code in i386/acpi_machdep.c can be shared with IA64 I think. > - Map ACPI-used memory in machine-dependant code Agreed. > - Create a machine-dependant "acpiprobe" device which just knows > how to find and set up ACPI for the machine-independant code I think only machine-dependant sub-routines should be in acpi_machdep.c, the rest common code should be moved back to dev/acpi/acpi.c. The first half of acpiprobe_identify() is trying to find rsdp, so renaming it to acpi_find_rsdp() (returns struct ACPIrsdp * or NULL), moving the rest of acpiprobe_identify() to dev/acpi/acpi.c:acpi_identify() and calling acpi_find_rsdp() from acpi_identify() would be better for me. acpiprobe_mapmem() seems machine-dependant, so just renaming (acpi_mapmem() ?) would be enough. acpiprobe_facp(), I think, is MI, should be moved dev/acpi/acpi.c and renamed (acpi_find_facp() ?). In summary, my suggestions are - i386/i386/acpi_machdep.c acpi_find_rsdp() and acpi_mapmem() - dev/acpi/acpi.c acpi_identify() and acpi_find_facp() > - Remove all the ACPI #ifdefs from non-ACPI code > - Minor style and commenting fixes Completely agreed. > Issues outstanding: > > - Need to remove superfluous headers > - Need to decide the correct split between and > in terms of functionality. I'd like to move and rename them as I said in my previous mail, -> shared by both kernel and userland programs -> shared within kernel code (acpi stuff and related drivers) That's my rough understanding, but I could be wrong :-) Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 6:41:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from tokyonet-entrance.astec.co.jp (tokyonet-entrance.astec.co.jp [202.239.16.2]) by hub.freebsd.org (Postfix) with ESMTP id 1B43237B42C; Fri, 29 Sep 2000 06:41:46 -0700 (PDT) Received: from mushroom.astec.co.jp (mushroom.astec.co.jp [172.20.10.50]) by tokyonet-entrance.astec.co.jp (8.9.3+3.2W/3.7W2000/09/18) with ESMTP id WAA00135; Fri, 29 Sep 2000 22:41:39 +0900 (JST) Received: from localhost (tengu.astec.co.jp [172.20.26.39]) by mushroom.astec.co.jp (8.9.3+3.2W/3.7W-astec-mushroom1.0) with ESMTP id WAA18531; Fri, 29 Sep 2000 22:41:38 +0900 (JST) Date: Fri, 29 Sep 2000 22:41:39 +0900 (JST) Message-Id: <20000929.224139.70178011.tshiozak@astec.co.jp> To: acpi-jp@jp.freebsd.org, iwasaki@jp.freebsd.org Cc: msmith@freebsd.org, haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org Subject: Re: ACPI megapatch From: "T.SHIOZAKI" In-Reply-To: <20000929220517P.iwasaki@jp.FreeBSD.org> References: <200009290916.e8T9GmA04415@mass.osd.bsdi.com> <20000929220517P.iwasaki@jp.FreeBSD.org> X-Mailer: Mew version 1.95b37 on Emacs 20.6 / Mule 4.1 (AOI) X-My-Status: SuperAoiMoe Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Mitsuru IWASAKI Subject: [acpi-jp 691] Re: ACPI megapatch Date: Fri, 29 Sep 2000 22:05:17 +0900 Message-ID: <20000929220517P.iwasaki@jp.FreeBSD.org> > > Issues outstanding: > > - Need to remove superfluous headers > > - Need to decide the correct split between and > > in terms of functionality. > I'd like to move and rename them as I said in my previous mail, > -> > shared by both kernel and userland programs > -> > shared within kernel code (acpi stuff and related drivers) IMHO, it's desirable to use the name "acpi.h", because of conflict with the file dumped by /usr/sbin/config. I love : fooreg.h : device dependent and implementation independent structures, macros, and others. foovar.h : implementation dependent ones. -- Takuya SHIOZAKI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 6:44:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from tokyonet-entrance.astec.co.jp (tokyonet-entrance.astec.co.jp [202.239.16.2]) by hub.freebsd.org (Postfix) with ESMTP id DEF7F37B424; Fri, 29 Sep 2000 06:44:34 -0700 (PDT) Received: from mushroom.astec.co.jp (mushroom.astec.co.jp [172.20.10.50]) by tokyonet-entrance.astec.co.jp (8.9.3+3.2W/3.7W2000/09/18) with ESMTP id WAA00154; Fri, 29 Sep 2000 22:44:33 +0900 (JST) Received: from localhost (tengu.astec.co.jp [172.20.26.39]) by mushroom.astec.co.jp (8.9.3+3.2W/3.7W-astec-mushroom1.0) with ESMTP id WAA18653; Fri, 29 Sep 2000 22:44:31 +0900 (JST) Date: Fri, 29 Sep 2000 22:44:33 +0900 (JST) Message-Id: <20000929.224433.15224078.tshiozak@astec.co.jp> To: acpi-jp@jp.freebsd.org, iwasaki@jp.freebsd.org Cc: msmith@freebsd.org, haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org Subject: Re: [acpi-jp 692] Re: ACPI megapatch From: "T.SHIOZAKI" In-Reply-To: <20000929.224139.70178011.tshiozak@astec.co.jp> References: <200009290916.e8T9GmA04415@mass.osd.bsdi.com> <20000929220517P.iwasaki@jp.FreeBSD.org> <20000929.224139.70178011.tshiozak@astec.co.jp> X-Mailer: Mew version 1.95b37 on Emacs 20.6 / Mule 4.1 (AOI) X-My-Status: SuperAoiMoe Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: "T.SHIOZAKI" Subject: [acpi-jp 692] Re: ACPI megapatch Date: Fri, 29 Sep 2000 22:41:39 +0900 (JST) Message-ID: <20000929.224139.70178011.tshiozak@astec.co.jp> > IMHO, it's desirable to use the name "acpi.h", because of conflict Sorry, "it's desirable to avoid using ...". -- Takuya SHIOZAKI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 7:50:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 4F7EE37B42C; Fri, 29 Sep 2000 07:50:07 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8TEo4r21110; Fri, 29 Sep 2000 23:50:04 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: tshiozak@astec.co.jp Cc: acpi-jp@jp.freebsd.org, iwasaki@jp.freebsd.org, msmith@freebsd.org, haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org Subject: Re: ACPI megapatch In-Reply-To: <20000929.224139.70178011.tshiozak@astec.co.jp> References: <200009290916.e8T9GmA04415@mass.osd.bsdi.com> <20000929220517P.iwasaki@jp.FreeBSD.org> <20000929.224139.70178011.tshiozak@astec.co.jp> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000929234722R.iwasaki@jp.FreeBSD.org> Date: Fri, 29 Sep 2000 23:47:22 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > > I'd like to move and rename them as I said in my previous mail, > > -> > > shared by both kernel and userland programs > > -> > > shared within kernel code (acpi stuff and related drivers) > > IMHO, it's desirable to use the name "acpi.h", because of conflict > with the file dumped by /usr/sbin/config. > > I love : > fooreg.h : device dependent and implementation independent > structures, macros, and others. > foovar.h : implementation dependent ones. Thanks Shiozaki-san, I think `reg' is short for registers of the target chip, correct? In ACPI's case, PM1 register and some such and maybe definitions for ACPI tables. How about kernel/userland shareable stuff like ioctl? for example, usb(4) has this kind of definitions in dev/usb/usb.h, not in usbreg.h. Is this a special case violating the guideline? I think we can distinguish them like "usb.h" and , also we will stop generating acpi.h in kernel build directory. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 8: 7:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id E626337B424; Fri, 29 Sep 2000 08:07:43 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8TF7fr28318; Sat, 30 Sep 2000 00:07:41 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: iwasaki@jp.freebsd.org Cc: msmith@freebsd.org, haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.freebsd.org Subject: Re: ACPI megapatch In-Reply-To: <20000929220517P.iwasaki@jp.FreeBSD.org> References: <200009290916.e8T9GmA04415@mass.osd.bsdi.com> <20000929220517P.iwasaki@jp.FreeBSD.org> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000930000450D.iwasaki@jp.FreeBSD.org> Date: Sat, 30 Sep 2000 00:04:50 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 11 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In summary, my suggestions are > - i386/i386/acpi_machdep.c > acpi_find_rsdp() and acpi_mapmem() > - dev/acpi/acpi.c > acpi_identify() and acpi_find_facp() Here is a patch for your megapatch at http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff I'll be happy if you accept and commit this :-) Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 8:48: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200]) by hub.freebsd.org (Postfix) with ESMTP id ABE7837B422; Fri, 29 Sep 2000 08:47:58 -0700 (PDT) Received: from libr.scitec.kobe-u.ac.jp (skai0829.ppp.infoweb.ne.jp [202.248.14.237]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id AAA39537; Sat, 30 Sep 2000 00:45:55 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Received: from shidahara1.planet.kobe-u.ac.jp (localhost [127.0.0.1]) by libr.scitec.kobe-u.ac.jp (8.9.1/3.5Wpl7) with ESMTP id AAA20648; Sat, 30 Sep 2000 00:38:35 +0900 (JST) From: takawata@shidahara1.planet.sci.kobe-u.ac.jp Message-Id: <200009291538.AAA20648@libr.scitec.kobe-u.ac.jp> To: Mitsuru IWASAKI , msmith@freebsd.org Cc: acpi-jp@jp.freebsd.org, current@freebsd.org Subject: Re: ACPI megapatch In-reply-to: Your message of "Sat, 30 Sep 2000 00:04:50 JST." <20000930000450D.iwasaki@jp.FreeBSD.org> Date: Sat, 30 Sep 2000 00:38:34 +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000930000450D.iwasaki@jp.FreeBSD.org>, Mitsuru IWASAKI wrote: >> In summary, my suggestions are >> - i386/i386/acpi_machdep.c >> acpi_find_rsdp() and acpi_mapmem() >> - dev/acpi/acpi.c >> acpi_identify() and acpi_find_facp() > >Here is a patch for your megapatch at >http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff >I'll be happy if you accept and commit this :-) > I think it is better bus attachment code is in MD part than in MI part. And MD bus attachment code calls MI bus attachment code. For example,Current acpi_probe code rename to acpi_probesubr and call it from acpi_probe in acpi_machdep.c . And probe method and identify method should not be confused. Memory area check etc.... can be in MD acpi probe code. Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 9:11:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from caffeine.gerp.org (caffeine.gerp.org [216.80.26.45]) by hub.freebsd.org (Postfix) with SMTP id D8E7837B423 for ; Fri, 29 Sep 2000 09:11:39 -0700 (PDT) Received: (qmail 23990 invoked by uid 100); 29 Sep 2000 15:57:01 -0000 Date: Fri, 29 Sep 2000 10:57:01 -0500 From: "Kevin M. Dulzo" To: freebsd-current@freebsd.org Subject: IPX requires 'device random' Message-ID: <20000929105701.A20184@caffeine.gerp.org> Reply-To: kdulzo@gerp.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Operating-System: OpenBSD caffeine 2.7 CAFFEINE Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am not aware of the full status of IPX networking support in -current, but I migrated my -stable kernel config as best I could. Kernel compilation completes, but linking fails due to a rand_ function not being present ( I do not have the exact error handy, but can generate for anyone who wants it.) A simple 'device random' to compile the support in statically rectifies the problem. -- :Kevin M. Dulzo: eyes betray a soul and bear its thinking beyond words they say so many things to me --vnvnation To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 9:20:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by hub.freebsd.org (Postfix) with ESMTP id 4CAEA37B424 for ; Fri, 29 Sep 2000 09:20:15 -0700 (PDT) Received: from fmrl01.sul.t-online.de by mailout01.sul.t-online.com with smtp id 13f2tO-00057g-03; Fri, 29 Sep 2000 18:20:10 +0200 Received: from neutron.cichlids.com (520050424122-0001@[62.157.56.197]) by fmrl01.sul.t-online.com with esmtp id 13f2tM-1a2D32C; Fri, 29 Sep 2000 18:20:08 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 983C2AB99 for ; Fri, 29 Sep 2000 18:05:16 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id B777314ACE; Fri, 29 Sep 2000 18:02:08 +0200 (CEST) Date: Fri, 29 Sep 2000 18:02:08 +0200 To: current@freebsd.org Subject: setting device permissions for DEVFS Message-ID: <20000929180208.A821@cichlids.cichlids.com> Mail-Followup-To: alex@cichlids.cichlids.com, current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! What is the suggested best way to set permissions on devices in DEVFS? (I want to chmod 664 /dev/acd0c to let users in the group operator burn CD-R's). Do we already have a common way that I missed? Or is the best way to put it into rc.local (or similar)? Thanks Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 9:31:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from rccr1.rccr.cremona.it (rccr1.rccr.cremona.it [194.20.53.49]) by hub.freebsd.org (Postfix) with ESMTP id AC9E937B43C for ; Fri, 29 Sep 2000 09:31:23 -0700 (PDT) Received: from mailman.endymion.com (rccr1.rccr.cremona.it [194.20.53.49] (may be forged)) by rccr1.rccr.cremona.it (8.9.3/8.9.3) with SMTP id SAA25964 for ; Fri, 29 Sep 2000 18:31:26 +0200 Message-Id: <200009291631.SAA25964@rccr1.rccr.cremona.it> To: current@freebsd.org From: mirko.viviani@rccr.cremona.it Subject: procfs info. Date: Fri, 29 Sep 2000 18:31:26 +0000 X-Mailer: Endymion MailMan Standard Edition v3.0.2 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ciao. I need to know the exact format of the /proc/*/cmdline of FreeBSD. Actually I'm using 4.1 and I have discovered that at the end of cmdline file there are always 2 NULL characters. Is this a standard behaviour of FBSD cmdline ? From 3.0 is it changed or it will change ? Thanks. -- Bye, Mirko (NeXTmail, MIME) PS: please include my email when reply. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 10: 7: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id C3A9D37B422 for ; Fri, 29 Sep 2000 10:07:05 -0700 (PDT) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id MAA20880; Fri, 29 Sep 2000 12:07:01 -0500 (CDT) (envelope-from dan) Date: Fri, 29 Sep 2000 12:07:01 -0500 From: Dan Nelson To: mirko.viviani@rccr.cremona.it Cc: current@FreeBSD.ORG Subject: Re: procfs info. Message-ID: <20000929120701.A10189@dan.emsphone.com> References: <200009291631.SAA25964@rccr1.rccr.cremona.it> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <200009291631.SAA25964@rccr1.rccr.cremona.it>; from "mirko.viviani@rccr.cremona.it" on Fri Sep 29 18:31:26 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Sep 29), mirko.viviani@rccr.cremona.it said: > I need to know the exact format of the /proc/*/cmdline of FreeBSD. > Actually I'm using 4.1 and I have discovered that at the end of > cmdline file there are always 2 NULL characters. You sure? $ uname -v FreeBSD 5.0-CURRENT #69: Tue Sep 5 18:59:54 CDT 2000 dan@dan.emsphone.com:/usr/src/sys/compile/DANSMP $ hd /proc/curproc/cmdline 00000000 68 64 00 2f 70 72 6f 63 2f 63 75 72 70 72 6f 63 |hd./proc/curproc| 00000010 2f 63 6d 64 6c 69 6e 65 00 |/cmdline.| 00000019 $ uname -v FreeBSD 4.0-STABLE #6: Tue Aug 8 18:35:09 CDT 2000 zsh@emssrv5.emsphone.com:/usr/src/sys/compile/EMSSRV5 $ hd /proc/curproc/cmdline 00000000 68 64 00 2f 70 72 6f 63 2f 63 75 72 70 72 6f 63 |hd./proc/curproc| 00000010 2f 63 6d 64 6c 69 6e 65 00 |/cmdline.| 00000019 -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 10: 8:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 8325037B422; Fri, 29 Sep 2000 10:08:17 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8TH8Er65357; Sat, 30 Sep 2000 02:08:14 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: takawata@shidahara1.planet.sci.kobe-u.ac.jp Cc: iwasaki@jp.freebsd.org, msmith@freebsd.org, acpi-jp@jp.freebsd.org, current@freebsd.org Subject: Re: ACPI megapatch In-Reply-To: <200009291538.AAA20648@libr.scitec.kobe-u.ac.jp> References: <20000930000450D.iwasaki@jp.FreeBSD.org> <200009291538.AAA20648@libr.scitec.kobe-u.ac.jp> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000930020812S.iwasaki@jp.FreeBSD.org> Date: Sat, 30 Sep 2000 02:08:12 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Here is a patch for your megapatch at > >http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff > >I'll be happy if you accept and commit this :-) > > > > I think it is better bus attachment code is in MD part than in MI part. > And MD bus attachment code calls MI bus attachment code. > > For example,Current acpi_probe code rename to acpi_probesubr and > call it from acpi_probe in acpi_machdep.c . Hmm, I think you're talking about BI/BD. Most of ACPI code must be shared between IA32/IA64 (even bus interface code). Difference between them is very limited, we can put them in acpi_machdep.c. I like this model. NetBSD's pci code take this one (dev/pci/pci.c has MI code like pcimattach(), arch/*/pci/pci_machdep.c have a set of MD sub-routines for the specific machine architecture such as pci_conf_read().). I'm not sure this is correct or not, but it seems reasonable for me. > And probe method and identify method should not be confused. > Memory area check etc.... can be in MD acpi probe code. Yes, I think it's in acpi_machdep.c :-) if not, which one? Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 10:13:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 3AB1137B423 for ; Fri, 29 Sep 2000 10:13:18 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id KAA08186; Fri, 29 Sep 2000 10:12:29 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id KAA16764; Fri, 29 Sep 2000 10:12:28 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Fri, 29 Sep 2000 10:12:28 -0700 (PDT) Message-Id: <200009291712.KAA16764@vashon.polstra.com> To: current@freebsd.org Reply-To: current@freebsd.org Cc: mirko.viviani@rccr.cremona.it Subject: Re: procfs info. In-Reply-To: <200009291631.SAA25964@rccr1.rccr.cremona.it> References: <200009291631.SAA25964@rccr1.rccr.cremona.it> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200009291631.SAA25964@rccr1.rccr.cremona.it>, wrote: > I need to know the exact format of the /proc/*/cmdline of > FreeBSD. Actually I'm using 4.1 and I have discovered that at the > end of cmdline file there are always 2 NULL characters. I'm not seeing that on my 4.x-stable system from about a month ago: austin$ sleep 100 & [1] 67372 austin$ hd 67372/cmdline 00000000 73 6c 65 65 70 00 31 30 30 00 |sleep.100.| 0000000a As you can see, there's just a single NUL at the end. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 10:29: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from scully.zoominternet.net (scully.zoominternet.net [63.67.120.3]) by hub.freebsd.org (Postfix) with SMTP id B69BB37B422 for ; Fri, 29 Sep 2000 10:28:58 -0700 (PDT) Received: (qmail 24029 invoked from network); 29 Sep 2000 17:28:06 -0000 Received: from acs-24-154-25-35.zoominternet.net (24.154.25.35) by scully.zoominternet.net with SMTP; 29 Sep 2000 17:28:06 -0000 Date: Fri, 29 Sep 2000 13:28:06 -0400 (EDT) From: Donn Miller X-Sender: dmmiller@acs-24-154-25-35.zoominternet.net To: Alexander Langer Cc: current@freebsd.org Subject: Re: setting device permissions for DEVFS In-Reply-To: <20000929180208.A821@cichlids.cichlids.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 29 Sep 2000, Alexander Langer wrote: > What is the suggested best way to set permissions on devices in DEVFS? > (I want to chmod 664 /dev/acd0c to let users in the group operator > burn CD-R's). > Do we already have a common way that I missed? /etc/rc.devfs - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 11: 9:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 667E037B43C for ; Fri, 29 Sep 2000 11:09:47 -0700 (PDT) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8TI9WU95241; Fri, 29 Sep 2000 11:09:33 -0700 (PDT) (envelope-from jkh@winston.osd.bsdi.com) To: Makoto MATSUSHITA Cc: current@freebsd.org Subject: Re: sysinstall: Avoiding version checking of CD-ROM (patch included) In-Reply-To: Message from Makoto MATSUSHITA of "Fri, 29 Sep 2000 17:56:06 +0900." <20000929175606Y.matusita@jp.FreeBSD.org> Date: Fri, 29 Sep 2000 11:09:32 -0700 Message-ID: <95237.970250972@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > % ls boot/kernel/kernel* > zsh: no matches found: boot/kernel/kernel* That's a different problem - there should be a boot/kernel/kernel.ko file and I'm not sure why there isn't. I'll talk to David O'Brien about fixing it. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 11:49:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from rccr1.rccr.cremona.it (rccr1.rccr.cremona.it [194.20.53.49]) by hub.freebsd.org (Postfix) with ESMTP id DFF9B37B423 for ; Fri, 29 Sep 2000 11:49:36 -0700 (PDT) Received: from mailman.endymion.com (rccr1.rccr.cremona.it [194.20.53.49] (may be forged)) by rccr1.rccr.cremona.it (8.9.3/8.9.3) with SMTP id UAA28186; Fri, 29 Sep 2000 20:49:06 +0200 Message-Id: <200009291849.UAA28186@rccr1.rccr.cremona.it> To: John Polstra Cc: current@freebsd.org From: mirko.viviani@rccr.cremona.it Subject: Re: procfs info. Date: Fri, 29 Sep 2000 20:49:06 +0000 X-Mailer: Endymion MailMan Standard Edition v3.0.2 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You wrote: > > I need to know the exact format of the /proc/*/cmdline of > > FreeBSD. Actually I'm using 4.1 and I have discovered that at the > > end of cmdline file there are always 2 NULL characters. > > I'm not seeing that on my 4.x-stable system from about a month ago: Sorry, I just found a bug in the code. :( -- Bye, Mirko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 12:19:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from femail1.sdc1.sfba.home.com (femail1.sdc1.sfba.home.com [24.0.95.81]) by hub.freebsd.org (Postfix) with ESMTP id 2306737B61F for ; Fri, 29 Sep 2000 12:19:35 -0700 (PDT) Received: from beastie.localdomain ([24.19.158.41]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000929191923.UGLP6495.femail1.sdc1.sfba.home.com@beastie.localdomain>; Fri, 29 Sep 2000 12:19:23 -0700 Received: (from brian@localhost) by beastie.localdomain (8.9.3/8.8.7) id MAA76455; Fri, 29 Sep 2000 12:21:01 -0700 (PDT) (envelope-from brian) Date: Fri, 29 Sep 2000 12:21:01 -0700 From: "Brian O'Shea" To: mirko.viviani@rccr.cremona.it Cc: John Polstra , current@FreeBSD.ORG Subject: Re: procfs info. Message-ID: <20000929122101.U622@beastie.localdomain> Reply-To: boshea@ricochet.net Mail-Followup-To: mirko.viviani@rccr.cremona.it, John Polstra , current@FreeBSD.ORG References: <200009291849.UAA28186@rccr1.rccr.cremona.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <200009291849.UAA28186@rccr1.rccr.cremona.it>; from mirko.viviani@rccr.cremona.it on Fri, Sep 29, 2000 at 08:49:06PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Sep 29, 2000 at 08:49:06PM +0000, mirko.viviani@rccr.cremona.it wrote: > You wrote: > > > > I need to know the exact format of the /proc/*/cmdline of > > > FreeBSD. Actually I'm using 4.1 and I have discovered that at the > > > end of cmdline file there are always 2 NULL characters. > > > > I'm not seeing that on my 4.x-stable system from about a month ago: Hmm, but look at this: [panic:/root]# uname -a FreeBSD panic.localdomain 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Sep 16 16:24:39 PDT 2000 root@panic.localdomain:/usr/obj/usr/local/cvs up/current/src/sys/PANIC i386 [panic:/root]# hd /proc/0/cmdline 00000000 73 77 61 70 70 65 72 00 00 00 00 00 00 00 00 00 |swapper.........| 00000010 [panic:/root]# hd /proc/10/cmdline 00000000 69 64 6c 65 00 65 72 00 00 00 00 00 00 00 00 00 |idle.er.........| 00000010 [panic:/root]# hd /proc/11/cmdline 00000000 73 6f 66 74 69 6e 74 65 72 72 75 70 74 00 00 00 |softinterrupt...| 00000010 [panic:/root]# hd /proc/12/cmdline 00000000 69 72 71 31 34 3a 20 61 74 61 30 00 00 00 00 00 |irq14: ata0.....| 00000010 [panic:/root]# hd /proc/13/cmdline 00000000 69 72 71 31 35 3a 20 61 74 61 31 00 00 00 00 00 |irq15: ata1.....| 00000010 [panic:/root]# hd /proc/14/cmdline 00000000 69 72 71 31 31 3a 20 75 68 63 69 30 2b 00 00 00 |irq11: uhci0+...| 00000010 [panic:/root]# hd /proc/15/cmdline 00000000 69 72 71 36 3a 20 66 64 63 30 00 00 00 00 00 00 |irq6: fdc0......| 00000010 [panic:/root]# hd /proc/16/cmdline 00000000 69 72 71 31 3a 20 61 74 6b 62 64 30 00 00 00 00 |irq1: atkbd0....| 00000010 There seem to be lots of nulls at the end of the names of kernel threads (padding their names to 16 bytes). Not that it matters, but it's strange. -brian -- Brian O'Shea boshea@ricochet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 13: 5:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 999AA37B49B for ; Fri, 29 Sep 2000 13:05:23 -0700 (PDT) Received: (qmail 21848 invoked by uid 0); 29 Sep 2000 19:15:49 -0000 Received: from p3ee20a84.dip.t-dialin.net (HELO speedy.gsinet) (62.226.10.132) by mail.gmx.net with SMTP; 29 Sep 2000 19:15:49 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id TAA27602 for freebsd-current@FreeBSD.ORG; Fri, 29 Sep 2000 19:11:33 +0200 Date: Fri, 29 Sep 2000 19:11:33 +0200 From: Gerhard Sittig To: freebsd-current@FreeBSD.ORG Subject: Re: interesting problem Message-ID: <20000929191133.R5065@speedy.gsinet> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <20000929112032.A4293@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from gjohnson@gs.verio.net on Thu, Sep 28, 2000 at 09:45:13PM -0500 Organization: System Defenestrators Inc. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Sep 28, 2000 at 21:45 -0500, Tony Johnson wrote: > > Since I am complaining then I need to figure out what U have > done to make 5.0-CURRENT crash?? Well atleast U admit that U > do not know and U do not care. So anyone who is using FreeBSD > should also not care?? This is more screwed up then I thought > and people @FreeBSD have made this much harder then necessary. It seems you finally got it. Somebody thought about "what can I do to break _his_ system? I have some spare time and I feel bored ...". But it could be just as well the way the handbook told you: -CURRENT is the place where development takes place. Using -CURRENT you're supposed to know what you do and how to help yourself. What the participants in the past thread wanted you to do is to provide some more info to make them able to help you better. Claiming "you broke it somewhere - guess where - , fix it or I'll leave" will make you get answers like "feel free to choose the second". Chances are that the "broken code" works for other people. Only you and nobody else can provide the info what exactly breaks things for _you_ -- nobody else has the system to repeat and explore it. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 13: 6:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id E848437B495 for ; Fri, 29 Sep 2000 13:06:27 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8TK7aA06203; Fri, 29 Sep 2000 13:07:36 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009292007.e8TK7aA06203@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: tshiozak@astec.co.jp, acpi-jp@jp.FreeBSD.org, haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org Subject: Re: ACPI megapatch In-reply-to: Your message of "Fri, 29 Sep 2000 23:47:22 +0900." <20000929234722R.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Sep 2000 13:07:36 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I'd like to move and rename them as I said in my previous mail, > > > -> > > > shared by both kernel and userland programs > > > -> > > > shared within kernel code (acpi stuff and related drivers) > > > > IMHO, it's desirable to use the name "acpi.h", because of conflict > > with the file dumped by /usr/sbin/config. > > > > I love : > > fooreg.h : device dependent and implementation independent > > structures, macros, and others. > > foovar.h : implementation dependent ones. > > Thanks Shiozaki-san, I think `reg' is short for registers of the > target chip, correct? In ACPI's case, PM1 register and some such > and maybe definitions for ACPI tables. > How about kernel/userland shareable stuff like ioctl? for example, > usb(4) has this kind of definitions in dev/usb/usb.h, not in usbreg.h. > Is this a special case violating the guideline? > I think we can distinguish them like "usb.h" and , > also we will stop generating acpi.h in kernel build directory. Typically you would have: acpivar.h Data structures defined by implementation acpireg.h Data structures defined by interface acpiio.h Interface to userland Since we're all in agreement, I'll move to these. -- ... 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 Fri Sep 29 13:13:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 5790037B4D5; Fri, 29 Sep 2000 13:13:43 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8TKF6A06244; Fri, 29 Sep 2000 13:15:06 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009292015.e8TKF6A06244@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: msmith@freebsd.org, haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch In-reply-to: Your message of "Fri, 29 Sep 2000 22:05:17 +0900." <20000929220517P.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Sep 2000 13:15:06 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Thanks a lot mike, these are mostly acceptable for me. > > > - Made all the I/O spaces use proper bus resources > > - Allocate the resources in machine-dependant code > > I prefer previous patch because most of the code in i386/acpi_machdep.c > can be shared with IA64 I think. I'm not so sure about that. I suspect that the IA64 code is going to be using the 'generic address' structures and the x-fields in eg. the FACT. It won't be using the bios signature search either, or the int15 interface. Realistically, the code in acpi_machdep.c is very simple.a I also think that if I'm going to continue to use a private identify method to attach ACPI (IMO a good idea) then I want to keep its implementation as separate from the 'generic' ACPI code as possible. The pmap interface and one checksum routine is all that the current division uses, and that's fairly clean. > > - Create a machine-dependant "acpiprobe" device which just knows > > how to find and set up ACPI for the machine-independant code > > I think only machine-dependant sub-routines should be in acpi_machdep.c, > the rest common code should be moved back to dev/acpi/acpi.c. > The first half of acpiprobe_identify() is trying to find rsdp, so > renaming it to acpi_find_rsdp() (returns struct ACPIrsdp * or NULL), > moving the rest of acpiprobe_identify() to dev/acpi/acpi.c:acpi_identify() > and calling acpi_find_rsdp() from acpi_identify() would be better for me. > acpiprobe_mapmem() seems machine-dependant, so just renaming (acpi_mapmem() ?) > would be enough. > acpiprobe_facp(), I think, is MI, should be moved dev/acpi/acpi.c and > renamed (acpi_find_facp() ?). That would be possible, but as I mentioned above, adding support for the generic-address formats is going to make things *very* messy. I get a strong feeling that whoever was responsible for making sure that ACPI stayed sensible has quit or been fired. There are a lot of recent changes that are just plain *stupid*. -- ... 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 Fri Sep 29 13:15:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 27B7B37B4DE for ; Fri, 29 Sep 2000 13:15:08 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8TKGUA06256; Fri, 29 Sep 2000 13:16:30 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009292016.e8TKGUA06256@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: takawata@shidahara1.planet.sci.kobe-u.ac.jp Cc: Mitsuru IWASAKI , acpi-jp@jp.freebsd.org, current@freebsd.org Subject: Re: ACPI megapatch In-reply-to: Your message of "Sat, 30 Sep 2000 00:38:34 +0900." <200009291538.AAA20648@libr.scitec.kobe-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Sep 2000 13:16:30 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And probe method and identify method should not be confused. > Memory area check etc.... can be in MD acpi probe code. Can you explain what you mean here a bit more? The FACT lookup and resource establishment need to be done in the identify routine, not the probe routine... -- ... 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 Fri Sep 29 14:48:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 0A6E437B503; Fri, 29 Sep 2000 14:48:13 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8TLm9r13716; Sat, 30 Sep 2000 06:48:09 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: msmith@freebsd.org Cc: iwasaki@jp.FreeBSD.org, haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch In-Reply-To: <200009292015.e8TKF6A06244@mass.osd.bsdi.com> References: <20000929220517P.iwasaki@jp.FreeBSD.org> <200009292015.e8TKF6A06244@mass.osd.bsdi.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000930064646M.iwasaki@jp.FreeBSD.org> Date: Sat, 30 Sep 2000 06:46:46 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 32 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > > I prefer previous patch because most of the code in i386/acpi_machdep.c > > can be shared with IA64 I think. > > I'm not so sure about that. I suspect that the IA64 code is going to be > using the 'generic address' structures and the x-fields in eg. the FACT. > It won't be using the bios signature search either, or the int15 > interface. Realistically, the code in acpi_machdep.c is very simple.a > > I also think that if I'm going to continue to use a private identify > method to attach ACPI (IMO a good idea) then I want to keep its > implementation as separate from the 'generic' ACPI code as possible. The > pmap interface and one checksum routine is all that the current division > uses, and that's fairly clean. OK, understood. How about having MD sub-routine in the same interface (say acpi_set_resources() or acpi_create_instance() or whatever) for i386 and ia64? Then generic ACPI identify method calls suitable sub-routine depending on machine architecture. - i386/i386/acpi_machdep.c acpi_set_resources() (ex-acpiprobe_identify()) - ia64/ia64/acpi_machdep.c acpi_set_resources() - dev/acpi/acpi.c acpi_identify() this is quite simple, just do simple error checking and call acpi_set_resources() then return. Is this good for you too? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 14:51:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 5AD8637B503 for ; Fri, 29 Sep 2000 14:51:19 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8TLqaA52737; Fri, 29 Sep 2000 14:52:36 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009292152.e8TLqaA52737@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch In-reply-to: Your message of "Sat, 30 Sep 2000 06:46:46 +0900." <20000930064646M.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Sep 2000 14:52:36 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > OK, understood. How about having MD sub-routine in the same interface > (say acpi_set_resources() or acpi_create_instance() or whatever) for > i386 and ia64? Then generic ACPI identify method calls suitable > sub-routine depending on machine architecture. > > - i386/i386/acpi_machdep.c > acpi_set_resources() (ex-acpiprobe_identify()) > - ia64/ia64/acpi_machdep.c > acpi_set_resources() > > - dev/acpi/acpi.c > acpi_identify() > this is quite simple, just do simple error checking and > call acpi_set_resources() then return. > > Is this good for you too? It's closer. I just realised that we need a way of creating resources for SystemIO and SystemMemory AML objects as well. I think I've worked this out too; I'll try to get it worked out today and send you a patch this evening. I'm following your request to get the bus-dependant parts split out, but I do *not* think that we should be committing any of the NetBSD code to the FreeBSD source tree (this has been a failure in the past), or vice versa. Meanwhile, my laptop is getting very hot. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 18:32:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 8FD0137B502 for ; Fri, 29 Sep 2000 18:32:13 -0700 (PDT) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id SAA26494; Fri, 29 Sep 2000 18:31:57 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id SAA04287; Fri, 29 Sep 2000 18:31:57 -0700 (PDT) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id SAA18953; Fri, 29 Sep 2000 18:31:56 -0700 (PDT) From: Don Lewis Message-Id: <200009300131.SAA18953@salsa.gv.tsc.tdk.com> Date: Fri, 29 Sep 2000 18:31:56 -0700 In-Reply-To: <20000929113047.B4293@wantadilla.lemis.com> References: <20000929113047.B4293@wantadilla.lemis.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Greg Lehey , FreeBSD current users Subject: Re: Repeated panic out of chgsbsize Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sep 29, 11:30am, Greg Lehey wrote: } Subject: Repeated panic out of chgsbsize } In the past couple of days, I've had a couple of panics out of chgsbsize: } } (kgdb) bt [ snip ] } #12 0xc01cbac9 in panic (fmt=0xc0356920 "reducing sbsize: lost count, uid = %d") at ../../kern/kern_shutdown.c:553 } #13 0xc01c8d7b in chgsbsize (uid=50, diff=-17520, max=9223372036854775807) at ../../kern/kern_proc.c:206 } #14 0xc01ee6aa in sbrelease (sb=0xcdc091f4, so=0xcdc09180) at ../../kern/uipc_socket2.c:453 } #15 0xc01eb9fb in sofree (so=0xcdc09180) at ../../kern/uipc_socket.c:261 } #16 0xc0221e0b in in_pcbdetach (inp=0xce1c3aa0) at ../../netinet/in_pcb.c:542 } #17 0xc022c462 in tcp_close (tp=0xce1c3b60) at ../../netinet/tcp_subr.c:711 } #18 0xc0229bf6 in tcp_input (m=0xc0e96500, off0=20, proto=6) at ../../netinet/tcp_input.c:2012 } #19 0xc02247ee in ip_input (m=0xc0e96500) at ../../netinet/ip_input.c:756 } #20 0xc022484b in ipintr () at ../../netinet/ip_input.c:784 } #21 0xc0309195 in swi_net_next () That version of the per-uid accounting implementation has some race conditions between the kernel top and bottom halves. I'd recommend upgrading to PRE_SMPNG. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 18:33:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id D193F37B502 for ; Fri, 29 Sep 2000 18:33:41 -0700 (PDT) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 21A581925D for ; Fri, 29 Sep 2000 20:33:41 -0500 (CDT) Received: (from nectar@localhost) by hamlet.nectar.com (8.9.3/8.9.3) id UAA69348 for freebsd-current@freebsd.org; Fri, 29 Sep 2000 20:33:41 -0500 (CDT) (envelope-from nectar@spawn.nectar.com) Date: Fri, 29 Sep 2000 20:33:41 -0500 From: "Jacques A. Vidrine" To: freebsd-current@freebsd.org Subject: Fwd: [cvs commit: src/lib/libc/net hesiod.c] Message-ID: <20000929203340.D69244@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , 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-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If you have machines running -CURRENT from September 9 - September 29, _and_ you created an /etc/nsswitch.conf with any of `passwd: dns', `group: dns', `passwd_compat: dns', `group_compat: dns', then you are vulnerable to a local attack. So upgrade :-) (or just apply the small patch) -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org ----- Forwarded message from Jacques Vidrine ----- Date: Fri, 29 Sep 2000 05:56:34 -0700 (PDT) From: Jacques Vidrine To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/lib/libc/net hesiod.c nectar 2000/09/29 05:56:34 PDT Modified files: lib/libc/net hesiod.c Log: Ignore HESIOD_CONFIG and HES_DOMAIN environmental variables for set-user-ID and set-group-ID programs. Suggested by: Danny Braniss Revision Changes Path 1.2 +13 -3 src/lib/libc/net/hesiod.c ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 19:28:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 8D8F537B503 for ; Fri, 29 Sep 2000 19:28:48 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id E130E288D4; Sat, 30 Sep 2000 09:28:45 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id CEC382877A; Sat, 30 Sep 2000 09:28:45 +0700 (ALMST) Date: Sat, 30 Sep 2000 09:28:45 +0700 (ALMST) From: Boris Popov To: kdulzo@gerp.org Cc: freebsd-current@freebsd.org Subject: Re: IPX requires 'device random' In-Reply-To: <20000929105701.A20184@caffeine.gerp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 29 Sep 2000, Kevin M. Dulzo wrote: > I am not aware of the full status of IPX networking support in -current, > but I migrated my -stable kernel config as best I could. Kernel compilation > completes, but linking fails due to a rand_ function not being present ( I do > not have the exact error handy, but can generate for anyone who wants it.) A > simple 'device random' to compile the support in statically rectifies the > problem. Yes, 'device random' is required for now. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 20: 6:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 2A42437B503 for ; Fri, 29 Sep 2000 20:06:34 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8U37NA42511; Fri, 29 Sep 2000 20:07:23 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009300307.e8U37NA42511@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch In-reply-to: Your message of "Sat, 30 Sep 2000 00:04:50 +0900." <20000930000450D.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_12416069040" Date: Fri, 29 Sep 2000 20:07:22 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multipart MIME message. --==_Exmh_12416069040 Content-Type: text/plain; charset=us-ascii Ok. Based on all the suggestions, received today, and some more ideas besides, here's the latest megapatch. - Move all register I/O into a new file - Move event handling into a new file - Move headers to acpivar/acpireg/acpiio - Move find-RSDT and find-ACPI-owened-memory into acpi_machdep - Allocate all resources (except OperationRegions in AML) using real resources. AML fix will now be easy though. - Remove all ACPI #ifdefs - Minor style and commenting fixes - Removed unnecessary #includes Please test this; there are lots of opportunities for error in these changes. In particular, I am afraid that I may have broken I/O from AML bytecode. Hopefully with this committed I can finally get to work on the thermal management. 8) --==_Exmh_12416069040 Content-Type: application/x-gzip ; name="acpi.diff.gz" Content-Description: acpi.diff.gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="acpi.diff.gz" H4sICO9X1TkAA2FjcGkuZGlmZgDkXHtz27ay/1v6FGg6TSTrYVHyI7bTtE6spJ46icdy2vS2 GQ5FQhZriVRJyo9z4vPZ7+4CIMGXHraTuXNuWtsSHovF7m8XC2DJY8/hN/vM9r3R5sid8LD6 48P/Vc9eDxhS22ebYz+MNkfh5sS3rUln074KN8PA3gxvw81k0OZVNeBR4PIr17tgAfwJXd9j RnvL2Kk67mjEWnPWCug7E2y2Wi2N60q30+lsdvY2uz3W7e53jf3eXkV0bzQahQ33GLTa3t3f 2qr+/DNr7W43d1kDfu+xn3+usu8dfrVpWTb+mA4fzi/adsWfRcCWNWFQWGWpFm54ubDBzHYz 9QyKqi1qY89c+gUtKrY/9yKG36qNXGXSP19vun5qhIIW/Ip7Ua4RSzea+dc8CHiotatk200n +GPCz5RPV2ho+9Op7+UaHgvwZab5DRGYGbkUhsZWCoXGFpOsIgqzWooRtss62/tbvf3tXoVI IBLLGvc6rNOlxgbBsbfV3O2wBvzp7QpAup49mTucvUDGL3ng8Ul7/DJbMZyHBaWIfyxupItd 3wbNFFQEfOj7UQEh+LEjMW61la6aWhOQMFZpFVfTzatpvmw2tWZUmiVCCB1bnjPhATSoVDY3 2MgPWP+3/vvzXw7fH530z8yz/tvjwXn/jG1sZvvHjFfirmevzNMPv/fPPrx5k+kwteyx6/FN G/i+1Ec76p8c/lFAfe65YeRAS5b9p8Z6Mzj/cHraP8r3vYzGAbeKOsu+sgELo/lolO9vR7cz nlFVdgJZNSZjgrpYvl8eLKoG7N+fBzYvgEAwtbxCABCi00yk0B7wi0XVV1awqBq8W3bQtC1p +gv9UWST/oqbp91XeoplvmtJK+5dLW1yZU384d8Za8g186xpVuy5NjMrCPkyQjA3qapWEerJ 2eMXh6MtKtkdvj49Nl99HJiD08PXffP4A8oR0LO5UW2xDapmaL4snA9B6xGfVhtQfj7mIWcu fA2ZbXmeH7EhfPfIUZpCIUNuW3NoFY35LbMCrHYj15q4/+IOERnesndHsFgDm0MOzFBTqU03 ZORgrIg77SoT1unwEUxF8Dx4d3hqvjv8ZA6O/6dfgYUfZh1GwdyOqN5ynID9u9qquF5UAScD Xj48gK+yCdZUrqamPxqFPDKjyswyh1bID7LlV+nyEJiHUvxDRXMT6Pe6UIT2ikV3LGJ/5jn8 DHV3B4JJK3JtduW7TqUi5IUCNlE6NSytH5Q3CviEAzu5dhrHWutZdFXTqtjMWt7nKpql+lxZ JfyMAs5rUpya1jdCGzo0REWlEuuCmuCnTGUQOjO2QbX48UAD371ANkzjDOlIcM0Cf4gLPcIe gQYW5ILLIyi+HluBZUc8kKVMQI7FM5csF02ntXA6igDiUAZcQVRQ7Ab/EDw2C5gh18ZkD8f0 Z9wDpVE//Hyg1cHaECJCsY4+65UQAEQTWUmfDyj4MLrdZq/LGs/3ms8p+LiTWmCJDwBvDosh sHS8+YGRyN65oc0nE8vj/jxk88iduNEtG809G2O+kKWNloQTL+Xm8fvTj+eVTln1h4/nWG+k gCdkrhgBe5nNo1psgMz1UR1NtErNLtkGuOE5b7KkBI03g+kMaX8eLaDN7kWce9ZwwnHngH9r CYSRTGg3GUQyYNugWCaaFlJxfbBSw8TyebiQiOsLdmXUofFs6fxuDBeNIzj5+uNAwBoF/mSl gSr3GaK76hAZ5ZZTNCN3yoNHIncx450VlboOxdXUtzrFVYG3DsV780iukhyU9EQlbqhFbihx t0wuH05k2mNuX4bzaU0LHKAcSMLveuI5E67FXsV0oD7H8qIOI/hSMMfsuNhMI5NwK8kEJeOS F9/ebfb2WMPodJrdLvlxWsJyLEWB5YVmOOF8BsshqbRI/iTx5+jSsEHh5LA9RgoUjrANx4rA IJHpsX8d+YVqx6DiMYbmN9yeRxxCnCI0rkHg2rpciUACN1oPaecapsGVEIdQw+ZhKE5g8uSL HaawLTPl02TZcHGXTkEXo9jqwAlq2lq0UokZFqEt38UGS4UV+cKDOEt1FKNYwQUZK8Z0gEf2 CowUmOABQF1FWQXGyT0HfWyJ/FbRr+tAV3d0W3MC9wrWdOgpPjVlVEXxcACNCg0Og0Vei1vC h8JmVhTBlirbrpHjZmGwTNgiaPVxvkxs48uwRTIxRRsp5GJLi6xAtQu1hlV1AkHHnBcYEaOb +N4dQSgm9lZH/Vcf3yqSlThEpQ7sR2bADIsK2fd8EnLcWX6XkNEmkafUKaLUIUqe446QVJoS IGbwx+D1+QlEkOc10aXJPhwfmYcfzz80WUKoyaDVm5PDt+bZ7032VK8wmuzJE+U193ab6DS7 PRn7SpwWbXyZDMRRltWWtCc3om2ACU71gtfq1UZhOe3XqrDtZJV459CW21I55Tvip9t73uxt A0M7vaY4Ccx3aDSoOUspXTKUbCXr1Zba/1Zc3Jmmt7W0glYQBzWXOGAue8FyY0Fxo1GX+2UL GuqbwzpJyIQfwH0t6Rv96X5uyx21DNqU78o0UuFypZKpkPtuGJBYFZsrgYPTM9T9k8OjozN2 dvj+bZ/9cIP/14CPGXdY5+aHm/pf3hM5cglbRZw05W63cgeb9cxeXZev2oULEYPlsI4u6XXl SjTnXrEYrxbwq3gtw1RLmFFmMon+qg39y+KDAwFeNUeC6vMtvEMxnhsKqQGP5oEHEEEpphG6 wqAFJw/5QXudXrO3AwbShTBH3N3cZc+rzrS96ipbVWnYmpYhMlXL4NAtXYBouYV6PVb1PZyA bns3qKTknGjmhwgz2DaSTdKBSm3j7Wn/xuy///NzPTOYRjsVBNdBw/+O7SYd8DdZSQWiReDz Brq3DOQA+IHPMAv8AkiuwUcAbGi3XmI0ag5957b1kohMuAfC3JKovZEYq9wxdPuiEBx2OPbn E4ddc0bhNaMoH7tGvv8TCbqSDMpaBSMZyZHbjVhZCOWSPyhC3tmXL6wmpM2+A07Y06cs+WrU JZcCkgkFJeibzzXUY8GpBCwWpB4yLvpEXo8+PGW1/9QM9uIFgxnUYYyEB1l2sGwMcbShD6Ib pwkanuAZpwbGZScey88jBBqHEBWGMwvjFOsCz4+GISk9KZe7jAhqxmnUoiAEcqATyCN3bEyE wjFUCa5E4/DajewxqxEXpBAbnbqxL5aTCYIgHh0DFdOowQAA+nDcZB2xMgyh4vJA9e2W9+0u 69sr77uV74vtngKybjqdEf0roLi1FsW4L0Ra1nwS7WsL22+0rL2pPSnSeX0fYk4YBWI4FCUs bgmL0goT4gLoGwq6QnMrg6zs7OvbokxMbCP2k4+HuoSP68CF/V8KcOSZwco7N+DDS8GXJdEt I1FMpHdPIgsY7zbJQ7GXL5mxU18wga3CsbdyY98brxI+ZYDVQVoSYa1/UCqANzftsRVUFIju AUR1jl95A3PE1UgcyMiIDj4BzlKr1UrIxNatl+EUdslT5yBexiTvKrKexC01IWRX11wzKaTE 6pejm/SAsxBDOEAwHgxqcmF2kU5+cDD8qMkwm6moQ1Iv0etaR9e6t4nPRVAE6SNmdTyix1vq bk7utpUuKyvoErvGAqbz76uIQpdN1k005/oYgRREDnUtIss48JikRTSHk8umdt6jYnnsHc8p duw4Ztx/qPrLwRaPNsyNNkxGq9DWQcdXoSmvzvo6jGaJr8LpAoCmwRXjs8n0rSDiKkGThh7B fxwqLgbw+gfWjwPgVZzRtwQwazCxZ/6WOFaDaocKjwjsJVN6FHwXzOAhiJdo/KqIv9/V2Zwn iM9XfTWXbXuE+EdDO9Ijt6SmlEa5nM3jgDwz1oMgvZjvh0F5KZ/LcaswtQi4MecxZtaA7b1v fL8KLrt5XH6XrkvEL6eHZylx5i4dm9w9Cqa7KfVpqlsZXeUUlum9m9e7CCGVvtfR8P1u4B9V vZ2bLdJTr9saulEocxAfrCIzmgbLNKSh5NOnTwyPHFq+N7nVobJAE1J4D1bDAzIXSjWx1v4r ZWjxMWUq3vlOq/xGZqbGuqeNlXZfrFZdGY+j2ftlZ/x/0GwcKz5IwWVUVtBzNvJ7gJ7vm9fz FZbK+LagRM/GN9Sz8TALLu6+VLP5XeyDNPvIFvxfpNkHW/BCKivo+R4WLK85F2W8ybwRPauG kiyqK+S9YdqbuHOVp6nQbArs2JfDkbh/3dndae6wRtfYlbev8aVvDduiTjp19hPrsH3WP37/ 2+GJugpuAO94GfsLnbpSBvbR4Ogcy9JZatUVUu2QSXqMb2evaeCDU0YP2EJ+4gwObRzEbBvl QsI79sRzBjNuu4ArOhe/HvMAiui5g/cfT06aeH+J6eR/z8OIRcEtpslEPgu5zN/BLG6RDgbD yIyj4B8AgM8c33tGfbCD40OD22gs+8cPODSpn5SdFUKh7wlyIQ49tq6AKT+45A72mTLAXjuf 0Fe9d5KhkN5zo2mANntdQ2a/5K1c2LJeMSDTDylvqUKLOaA3d1hVF2YiXQG0BFt2PeYAcv0r DsKZ+g5vxnPlWCbEBEUeh3l7/rUwejR3UA1AC1Wj2zdp4Ucmbo6TI3Z1+R38k1TalPx2oHkX aaUsb6UUprCRP/cccXPRWHGerKJ8oHR7epEpaehNEd1MzEvY1/PuFuYj9bZ3FuD5DOzm/xie M+BM/M3CzFUx5a1dQF+jB55F5pHk7phwwjiVYeBfck/ohFVi19My6PtdgpXvJFZQ3SjnQMgZ /6A2c0WskiTO1LCo9RKXqhbDZ3c+vDFhfPOXo7M6LF7o4v1RckFKQ+cgRBwTsn9wmKQtL0vo M/WaRQENmMrreMrE+AImJKCdraaxBRLa6zaNrhRRJWf5ZOsibxmPYZhEtxJSRzlilSszoKw2 prJxRS6leB5RPBRT2KAdp8Hl/dD9MouVL3/+fLdpABC2wJcbCvxCocTZS/nglzk4Pzzvm4NO nVYqdCyUf8p+P/wV6gaUVzK8ZXgDhmxbzPe4TDwpuCxYmAaCp0/0d1iPj/dqVM6+MFEOCqPu p+8MU3KAjDXuMxi5GhpEjFFMGrWPCBbWgBnMfD6b+BegDJFKWEmCGGybtSbs0JrPmOgScny+ StBqsifUQ2XrPQFDD9nUumXyKavAn0PIEoJEmRg2tsVyjgwJSHGBaVoiJ0GdmbKkNDvXA9Vl WFa5koT1jJuUPldVUZoAJewK2ImEZ0aP0LPhPIpALOg+yQJUgUiHpozbbRC23SY/KeSVypjW J3n6+9mr8/dm/z3ALC4cnJyKQuEW9ro76De3tjty8Qaq4nUCUrCUhHhwoC+Y/w3QlzkE0snJ AzAhkZ1dzEjc2jNSubOFbilmJ/Yn27mkRfRsDc2/3efhBRVOi8JKOJmZ0e2MzuPlx6HMRO7s PG92d8DPb4Of3ylObUw9dlCYn7r4yYN1HjdY/UmDeLfIKNFYLcNyAF2VGq6/xKMVNpCoFet5 1lIWdMgvxaKFEB0EJkTIiTNSku0e5vEayf1HgbKLMdOitHfqiKpC7wlB2QhjI3zoORSaA/cZ TNA5OBaf+l5TNSQPK3iTmZND8ChWGGLk7zM3Ug1DjLasiEIuJIaPxDKHw8Z0irlcwgnN/Ilr 37Zln81kNv/M+VyKL5kGvWbBPP/jtG++Of7UPwLLlLlqKnFYv88p02nslsp0GjdYVafZDnmd ihZfR6dGWqdris8oFB/6Yj0ffEF6rcgMF3KqKYF3MPWUEk/deh1TXUmA1G1qhZd6bX11rt+e 9olnl8S2lEVDscgKeTTKeDQegceqvC538bylJGN4UfJR5rknlTKmMg9lgpOlkpnwTlN+6sSf KBE56aMlCST397GbVEJJ95HrKi2fB+qEjR5LwW+6u66AuxYbZ9z6sowrr+MssIt6aMaKn2+h U7MB7jxE3QRkK0/PkkakZlo7B+N5xCAYlFdX9JAbuptT8ifvLM+64FO0MoMNaEpxen0oWm7S 2aB0Cz8mDkDllVGpkqq6J18rPkgErT6qm+CY27ewj7XnQSDcATAXzGcRQ9jFPOpDypO38iET PKiPuSGPRDKciu/EcU5LtGbWheV68dAUOmmuU1Gvi8x1zGTX/GY8INXq0ZtSXaLnD7822a0/ p7UgnEFcpPSYd5mJqFFCAXt9eHLSP5I+sypy99WcrMlEE+MF93hg4eGiXFJUwB4rGPPiY+8N dMF1H7466ZuvjiFsS4XxMRCWd1lJYaXBvZrSa9oaJpORIiidSBlPZbNY2P5h+xM1hbMYVsk0 8tvZZSISHhSCugXgXughCNP6MbxmfQiQSet0Hsx8WHj7wiQ6OY+RdRidRJadrGvQLzOX+obO 6g6B5TyCfp221CXkRlruB1ihI+gkpt55ZFPXRPfYto5c/0fN4CB5+I2uagLt4R8nIf9ThlTn ppOKkVbTQ24Xnhp7HTPvxFkTaStajLj8+Cub54oTyyBsRWOM5aiMcqFN5lfxrE0aiaCMAptc fb02YkvBIRYv0Vl7XH2JTo9y72XZSKzReHxr/Forr6FZo/H41rjyunvP9dYoN8R1juPWMsRV 5pSB1nqrYglgzngY4WFhNigXS4njw/5+yuN7lXFy2SOA3G63tUUrfcojLvlW2Yxkd0iuFyUn W/jQK2axxe8pkG+nYxv4Gzct5gRcBrNmcvuUe58B7lnodNe0gouaNYvvHpMm4h0EYt9T2YAh 0QF00p2Qq6JmxuJm0MqbT0ll6k1xn46O3x6fn394//Fdza6Dtbuh4164EXzBS+oaFrbYs86z OttntWeHz9gL2GrZddy8QhV8efbmmd4SWjSY0cHmnXqSixDeCLIoqNZL/P1n9zPtgYuqep/F 06lM8Qzz0jnNUNlgeEdLz/RWSpoBxYNC3wO7Z2iKd1DwP90/iRGbCx/wjc97JXsvxFa+rLk6 pUnU+eVHudcXBLKnMimdxm3VaOWPBNdTKcaFs313OPhVvA+AZhuzlHwkI1C3Yp3yI4Mlr0HJ niDkDTC98x9NrIswvVQNgIcZg70D6wu3leys37g33GFvOFACnyGrX2GKaW2rvdvutY12ty6o oGAcvJChEdjI5eDy/ZEkQWePRzy0A5cSadg5kaptt7vt7Xr7frvjkg25mGM2EQg+yqmLBVc0 khsnvEc36S0dp7+fma8+IrTrMomEgBLvmr8U3Y4caE2G5U3ulow9ODldeWztEqZs7FSTu1WF G68+pccd6jBT4QevPejDOZ4hJ6fHDt53xrAQS404KZWv2sU4RPT8C8/XQF/+jAtkdeE/xFaM jNLTHREY4ntVZ7PJrYmvWLTssUlZE6Y//JvbYDYi9+DJXzRO2zx50syvN+psD0VSCq30cWfM iKXVGZm64UGyHq8ehCvC9Vzcu3LfoX4ELNb3WUBL7UQpQkZFudfwPM7J2FrWvJzKWjvxnOBW 2FqXy/zeo67hxXISU88oPEBk+qMOK5DJ9JXJ+St2LFm/Fr+TSyxfteyxMlblr6XJ1HOrrbz9 lq1ouPgORiUrsoJ3q6pXq9KlZ29vp4mvc9nZ6Ta3DP0NTKk3hWWTToCSPbEgAo7Uybf4fqBd 32IOUkt6m7VeJ5Ykv8ImwpcvFaCPShbxGwaoffKKgUyCyr6Ko9BDiZdIiVsn3GAWJLOgHzzq /3b8ug8qH3x8168Fvh+Zw3mYBD6ZB/ozV1f7xeXdkvJeSbl4TYCasmRp8HEA0eRRhqfCdwRk 3kWhUpCIoIJHQf7QGu9sq5K44lL5zx67E+eg2sDPqq5S0Uu1ZEh8P29lQ710OFlWxdVt/Grq sRVi/hvetAKIHQYbfkzuajLxGuGAWoBrxydwbuWZ4JBzzARhz3Baz9RrfF0PpgwTxHdaQyAO E8MNpOdfJ2EYRSki6xhfJBynPOIVgZwQbGwck6ZUE7KA9RV7PMGrW3GzphIcG+J98+KvmNk1 f3bFY24vfCEKJt5jB7PDXejYv25qWX+0w20rIpviAzK6EkOUD0LL36j2BMfaj0dXg6ocyxTb dymdyORH7vnzizFGtyoNEjfLmCeLCbLsGu/H/bl4SbF6p7044MLkx0y0q70qTQWnuYxFkv5C mR5CyKHDBfhBgVAZiRa4PC0QXk0oWL4eEEWIBbV6PVZ6ViIaLFgeta9BphHXXmxNR18cEDeE XfuY4d4hFkkGcKQ8oIovsDg8OjJf/3J8chQr0+gYaY2mE3ElCqSKYwTYFI3iO7v/t70v707k SPb9u/wp0p4ZNzQgUYB22zMIoW6eJaEB5Lanj09dBKjFbbYLaHvjvp/9RUQulVsVSI3Hc+Z1 25IgMzIyMzJyj4wfb2YShrqhN0xwY9GTFSodvtEogs4sYKEoi83LmUcPgDg+Ro3mZbPVIccW KrW4gI9ZohHw+hxbf4/Zkf0rcrObvIbrOKvN0VPgeDCeQn+BiQim7z6aIGKdrbYn1kANxKh3 OVehuLiQP8yad90RV6PYW7mjSS9vvlygjZR2C/LOarej7KyY0O6wZK6kzb40w1f2d/DFwF5p TxhlkQR8jjM1/4jGJXiOH/DMh31ueocLBLF/xgE0Bg1AjSeshLj34T051GE8G8H4PXraEmU6 2MmXKlCo8n5+T7xj4BlzR5090764fvFzoylMjHO8ANTnqgKhgMaceLzJUeHOG5jvmB9A8309 FXtb7FhQWyOok1xT8NNoESHcSREEQqytICRX+7/VmXHXb/yeD/T4f4vk7bJ1GlVrncZPdafz 2qahWmvLuiFr1W8tGameDCJqntfP+TBOdRILV1hSnDei2vkJxmgtH1cKF2BOnbAqaA8o/COY 5wnC0F90TiDD3kM2C+eh2F/N1e1GjkTulApIq1H9p84Gi2W5SHEipTMOEpJcFZoksZcIeQOR CzwlP5Ylf0nRk8p+vXbZPzlCF1udNcVeu9i42NWDdE/Rxcv7VLGL9KvELkq+WbGvV3bmiL3k iD1Z6qWNC72UUu6SLnOjzIx2tmsUOOqctzZa3vhNfcUqlbgpZTNxU5o0gnh0Rz3jTdabN5f1 4kZ1Jn4bnnAmL/toQoHD1QUON13gMKnAYcKgcjGFfeCwx68+1W1eWlOIB15irZfzrPXovZUx g4rVnp8Tn174My1YCnqnavHCbNVMjfl8q/GBWTq3BhN/gS1GTEz3xmzffltt1dEUif2WNPl7 Xll5Jn8levXOI2mVFK8A4odYognuZtz+kuoiSp9nkGeLm3ieN9o1ueYGOqTRqsm3Y2Ij6eGq pPQ5nFOlseDrTEiyjhT4UpEjMpR38IXGfjl+nBp4oe0yi9u7ZX/6MMGdIL4jVotg9C3Li91+ e9U5ab67iKCA0Vm13cnyDWC8l1VuqY/o4ZcQTISLyXH34wAPyTLcEXoPPi4eSPnh/x34vbtb lLsEpfWUGPrDMOrP70O618EoUbcKPQTer8Rv0rBhyGJh2Iv95xM3PSZe+VMF4j7fRof18ZW3 uKuQ3vD1ri+A7qIe7Xn5Pk93i6+1M8XJ0LiKYuiz27xWvbhodlgNOk+nzjpv4e+J3PB88r2l 46LA93llkMXubr5UJFm4Z1spCAD8LEuOaXIPrN4vovBE06aNDWIwNncD8ltW7qKGfO6z/ZOr 0f+8+rNyTZ7TTPWnkDO6HZ9rjys5yYry8XmBTwx2WfU4Mxc1odiRIRWBPxb6JFpFFVL16Vh+ jJdvOejOqX8lDBnWkHBkcnXYrdEcOFQbI7X4Eh/1233Wv33eLeILd9Cug3A/X9nT8LlOWjCo t6Lz5snVWZ06QZ5NBo93CwmDII5OjQNy3uexEPxZ0Y9cyenpL10jzrAT4qO/6WI5eoLiTPGa /2Y+HbOL+rtatXWCSLY9OvjY4g+RGPedzhx7fvekHWdoRMrjn+gignwT5LyLjVXpXz/gcWr/ EU/wR1P+QnW+jL+RV2Jmm6pQ2YLX3UFsOrJQhwwgQ2AoRtYBjZw4F2bEq19Ilc0zWJ3Wzy/x 70XzXbXRESdOGUygddxZdzLsCZ8PmlgO0WjslTbJUijfYFOuMGoN8GUYZi9hBUUoSAzPDOf0 XICu2mej2+GHW36E2e5UG2d/jxoX7XqrE+GXDA2ClAEoAqIIDCKugpDwMcPP8PlzTY1U3eCk oo7E10jGkY0wAhJlFPJleaasOFwDAcPnu+YOmt9y5YVz+sQ2hG3QYsm499/J3Ri+3r//FXL5 56viq/yrEH5K8FOGnwr87MDPLvzsvTJ8ML7ah7AD+KnCzzH81ODnBH7q8HP6Kl8IP1Fe3Mcw 2pIMlrfTPmUU32///PM3VIcJrlvxcpxfhAcgjXsyAzu5G4+fxL36w+1wNMiE0trAbk1xGYDy Eg172mi1O3o72cc5eqsGwZKeOhkqcInqKmbBwf03yjM5ynA5nHBn26aljs7yk7+gonit+nnz p3r0FsaT6Oqik6Z9Bld+m5bRFF9UJ76Zch4EHYqy8TNL1Ry6rcFfen/pSRAQqRYZrR9ts+Ij mnKRt+xfLUKNjscLOWGbDif3U1hO8Ryj6yeyktPLUETAGWhxkSatlPV/n1J+bzYqPe3SMvgu 7sH8Pkrr0LjnynJ1CfD1/feMLLri1Jyj12KrKEy1IJ3I+HkG2aITUy/+NonJCmMAgwfPMLtG kU1KYdPxm0LTWLsQvpoYvI0OqUtYb6AUuzm3NKvta9eQ60ojixS5rpDWuu9ZvNJyh0J1Ic0j aTGOAxKfybPyIsreD/wV/imLhnin0oE9Sg+mb9idwErpbtJ9QNcq4lZSuPdZiHvA4XLLOrbQ L/j44z5lzfAB36di+oy9aNNOL4301rbTWIotPAhgCZP262eUI752xw92Mh7nLz++mbEFiEs4 NNNn3bvldCzWvv3BYyy0PoLAyKWeFAOFaqdWCP8lNiRqb6Miad48bdXr6Zsd/25Hl7ZSJLH7 4EUxCgI8Oal7MSKqMhS7ya88NjULsQfGJpOXLpvb8XoufNJ2vFLda9PJBBYxpN1ybY53nvBh MRjd43WybKzkQzexasfFulilC19p3BuPEHn/kTZ/KCXe1lac8CjHfdK5KUmL007SeCm+dXPM e6/L9CsDKx9zE2wRXItt6PdsPu5OqF9AqXighxnXDpvHsvvBYgAhiallB4lFJzWQ9z01hXgG jYDubmFJCrvXxkWjIzaT7UbUvjqOxBYxapyc1Smw2TqBYbh68UveM86IMYL+a2BHPmQxVD38 2rr96vvP//dVq9aG8XU0OGTbt7BT3b5ZbONualTc7t0vthfz3vbiabFt5Zy//wqqPoeVL5pb zuHPAtfp4VZY/Ko/vLlhhTtWmONXJopaKBTs4gelYrG4XTzYLu2x4s5hpXy4UwmIRS6XSyQu F1mxdLhTPCzt8319PtzdZblins6LYDNeICcftensaQ5rsCW9PwgPDg5Yp/uxO5nOh+xdd9mF OXHAvltC0AN8+9vidtjvonlduDVDeLPl1qI33Po4vR4U7ra6va3/nv2QwDbPsGTsfLhc3M3v WONdtV39scG+Gz50F92Pw7+dwgx53D7Zms4/cBbV0YgRCzIjGczvB/3YBVlr0B/C9mx4fUcH 9njnje6ChhMmRgsMuR5OuvMntHkdg5bAmv8WTajw7/RuSWzG07469c+Tu7IZerdYotnVbD69 H/bJHZ5wgnEzhU7+gC0Ja+H+UDk/pISwyD2kL+GWVboFTtSiWGS9MUaXaKAX+I6HrC6up/cY JURGXODfZApzEwwe5LCDHsIAnzhnqqJZLPR1R7Ygc5IUK7lFgSw1sciiQF37d73B71Uaxisq WfWnvTt84d+VbbcNzTJF0zYG8/FgPuyOFrH4qd3IykirSKwJnbeNNms3Tzvvqq06g8+XreZP jZP6CTv+BSLrDCbqt80Wq16csFrzotNqHMPM3Wqz//qvahvoX73CKK5xF7+w+s+XMKm2GaRo nF+eNYAPMG5VYXdZb+NJf+3s6qRx8SbPgA3Dmeyscd7oABmigUJ+3EOek5Q1T9l5vVV7C1+r x42zRucXKtJpo3OB+Z1iEdlltdVp1K7Oqi12edW6bLY5O6zZSaNdO6s2zusnWwyKAVkz2qOy 9tvq2ZleU/jfqOhxHcqIdzPEizKCip40WvVaB2sUf6qB3KB4ZzDoXtZrDfxQ/xmWq1AeGHo5 33b971dABJHE7qR6Xn0D1cuskAy0Su0K9utYYhAFDPPtTqNzBUuAN83mSZt4QQbtegtNP9tH 7KzZJqFdtWEOOKl2qlQAYHOKb93x8/EVzB0oO1hY1Futq8tOo3mRJU5vm+9AOFDeKiQ/IUE3 L6jaIKdm6xdkjDKhdsizd2/rEN5CsZLkqiiONkiw1iF2GinkC0LtaPVlF/U3Z4039YtaHWOb yOldo13PQrM12kjQ4Fm/q/7Cq3lFIsAWg9Lxj5oO56ldWeOUVU9+amDxBTGoQ7shVKd5yj3q XdXeiiZQPSL4sxhKD1nirEQzEPPMK2y8GGN/qz/O2J+V16c/DW8miNWL67iIFnT0620UP3zz RMUA1uTaozVQYyA3IlB4w/EpG/kUgtFeLOppBXkGm7AI1Kb1S8ZHk4XBaPJxoZ/XiWeEAT0j lC+gWHTZel8slH7lBlHKPxbtCwf8ieVJEVeZJ2WbZDJ4XEaCjryKwpjXHcGSUIxOkI4eRgtZ 8CWvMG0+KQZBMSkuDIIwKa4UBKWkuHIQlBPiri5+vGi+uwhKOztazd/ZVcIj2KjXnVGF8Ats j2bda+7a11OZd9Uf67XqZQTDEA4lnipJCu6SwlMvSWCUMCmb+mn16qwThMrfGhPm3uIpL71k WQ4WS/mO5St0DSscTNNxqdjP96mGb+qXiJApEve3xfPkvhCLfXr6ejZ/iO67o/elXyn5YEQu aWgmJ2nOur2P3Q/cySNHOEX14UrrOLKp3cJMD3k1iTnr4EG7R8Rog4LnjY1WLShStfFjGiWU JAgDo4kTKX8OSpKyyAr4p0QJtrkD1jGs8OWT39Q+CXucm3X6JdJ5+qaHMnjN/x5JUXpph5Ob aXq+SLHGaODv+s3TU1wcwizhSPESJhO8OW83r1q1etS8cHTbpjg9xf5hE7Vwqw4dN3BHI6oT HmNn8olCz8I67QYXXu81dr8erZ0aVBpTH8UKqyHAt0lY+PTTMypz+6R/xvc9JH2mHQpk6aBd XL8wcaZ+ZAnA472M2cOIc+zObFlrFPUaK8VZ8kNf1Rn5/EhX3l8VsEZYJJzE3Cvxf1onTOLE KSJPWfDnSDxKpHRyiw9jxHS+VDdO8gb8yEc5nP+PIhTXs/idYzG/jq+BjYywtov+kh6M6NdR Kly4w/f7yY9d4lup+iY33b229L+vvRvyBkbaBKgIXE+s5t2aekvpBIcqmBjJYdsgMx6I2eOJ UTY5MvsCtYTo0CB4rR1dcdkndyU+ujhhokut7IN2UgiVSUWn0hOLTkV/UKk1bRXqKDVczDlt euQl+i6sVgbziXpkFvDUeKQj3KHIcUE4JPR5X8AjFcGH1DR+RWukdS/M/b4cvpK+oJh08hm/ fluVE6oULE6emVcQZwOJs0fJ61Gf7KgkdmN7gNntwtuNfH33IS2NaiKnhRSPZ7SREpyV+JmC S28es4YvcVBrNAW+BhcrOrxlGncnw9ndiJ8MJDVJvLjD59wOfr0aNTTIEZmpNuWRgURSFs81 KtHZn8j31Xnc6iygBIwDeagzC1zOLrUn9DD+jEZP+JL+bkEnJ/r7GLOIyoGK9OFoLvjUOTsU Cl24ZAP1FA5TFQ/ZN1jeRdZJqK4EVMo+rLeYetZE+WV92WSPPjFuWcA9lPCH6LjI+drZFWJV fIe00XC61dvwOW3Mlx+1XmgheMxK2+LJ3WgUnM6HrD2YsdIBC3cPi7uHJb45pgNWlcggOzgs Fw+Le5wMz1fxYDUX5ss7ZHiZw/PV3O9zvupn+6zz1VzS+SpEUOQGzldzmzlfzennq7mNnK/m NnG+mtvU+eoGSiPPV3MbPF+VmrCh89Xcxs5Xc5s9X81t8Hw1t9nz1dwGz1dzGztfzW32fDW3 0fPV3ObOV3P2+aroEep89c8cSSr3Ve5Pw0lvdAcjzzfT2TLih6zfaMHf4SHsDEb18dbtD3Y4 blR84dd3CwrVw8fd3i3M2d44Yz6dDz5YLI3o++5cpBcYWfzhuHiBhK/ZRd2EcXAES6oRLhY4 QgFNiRbUmX+VBDML/zC9uYG1ogvZbLj3J/PZ3D/ltT7s2mBH3v2AG/HrBeHoxOHi0fwSYm4x RrPiBMbc6Ny8SYcf18BCvShG5oulMBXVEuCtOOW8uPVEyn07Jlc+OrAadO9N5oThIeYDZRKW Arz4ZFwRZiBLWKUubvNCQPxqXdl8EINSMoPSWgzKyQwqCQyQ+Fty1Vi8oX8etpXns1UMlO8O z5sIn3ZlD0GLIKthn7SEIYYdt4iTNh2iIEUzH/7Ii6sah4GBUApcR7MF/t5/gGpz4fByHf3O qh5XBAGRBh4tJ3/03ID0JlnjbT6usut8/JzKn8NpZT1YjpXyhB/DfvgBtg7ZlDpVvCVxOwqV 5MW9RWis1V2kfZXRL1b1guE0Gg9hk+8eYKRAeaL3A3pmI456jI7SHS2dToOftc4RqzpQQpVj ZU+F35SPR61RA4tKOcrcvuVc9WGDioxmTzK/ZFay/Cu5/aaz0+2gvI3llJILMWaamMoukJWQ D35qGKCvWgOLIxRxFZbaypxUb6N9ji2hjy7iGOevtlWwlhk79EaKIpijoOx08Thke3jgI5Z8 g51KxwcvSVqMOxm9F+AnzqoKvFKOqaRPaBaUKo9V3G2Jm172ntGthLUxl78GkptLAsmlJ3dd H0huzgTJ1VwtcJzcXGD1fprvptL2PB8bnkqPFmbQMQ8qxnqYKEtTHD5UWmVlnSTK54MNG6r8 B4lSqsl6ouRov+tKMwXjV1RdSlMs/dGdxnDBug8fH7pzdOcpkPduBwzdlHZ+ucST2QUdwuDj ZPQxM50A3fIBnY4h3fJhGrsv4EcjVSRYDuaxRz0855nw440xnVwh5pSbzWKAGyXuOofvQdxW l44On9HstPIxscdE2LXQhaTmT5iTElTiM2crx28JfzUjJ5pY0XQfI4Gs3XrTmONh5Hl5GJNb HAy7BQ6vAgwj0aI/k/EEOUl12pmst9eaG/0yUQ2aUN612B1b7K6T2H1a3fGkUqqel2c2wjYv sNK7pGGt9EIF/30GNeVbRdt4EAW+wQrImIFekEO/1qHTLYddm+sXJb3N9NXOM3Upkc+qpi65 Te0AqacuvHSXqy9r4c1IEl3emAIwYIZFNdJEISqRIge10zDrrz+025SSBzFG9jOVXDmX59P2 H6/l+OTvs1U8iUm6fustk9KuSW36/AXZ/19tyhdzn9+sXj5rtGzK8jC1ZV+ya/n9Wjb8d2vZ cBO91ctkZZumbqBWtOm/U2/9d2zTjfTWJD6/S29NtY0x8ZghXm/o6QRdPznncOrImLtEHSyO DL9pDb6FQ9sdcdt+M5wvlmTXg83116/0t8hI9p3wQuYDd4HWR/iZfekuCbLzubbTm4AK4i/J YoD350ZRRFnoRXshzS2IeGqbXODQW2BPiblvO73IcmUocJhgU30rrNiVjyH9kB1YamfshjAO lRKuDX1A7ek7oDbKbDNeA93Ax/gTPxyku5cM//At+1+OvoMv/LPsN5bhioeYRyqc0I6ONi4D Hchrs0JI5SyWwF67J2lJt3Hrp7VfqWpFSHyuume8Vt1jdtGdV6taZMLz1T339aovEX/GWt47 LO+SmVVpLx/usBz+2SfXVNwfFPNfwRe0CPMSniVcwhfMcO6MyXM7/3EwnwxGHk7yaj6JD7Oz 4GX9Ie2a342RtuWerPD9tpOR9QIs2TJgPcMBXeAawXi0Tfg849F4YEvZoeLniEjl6xjD6cbf bSu2ujkgBTzTGhDTWMaApYPDcNc1Biz/MbaAX6wAv1gBfrEC/GIF+MUK8F9qBagZ1Dea8h1s EDWamVeXr9C7s0MjX9PGRCWXqF3vtM8u6XUv0r3jhGWyncgmrCtpGv8d5k/OV59AecgzZ1BK ZNvTh4ehx56+8gfZ03+ZQ7/MoV/m0C9z6Jc59F85h24LdIxhj1X7fRhNF+KtIj5N5wbp6jnz h+6CGfZoXZ5C2I/hG2tjKo3eVNvRef0cpIouOdy4RhPdcbjhl7UG+uJwI+rnx/UT6MBB2RPZ PodmD4KKJ4qev0MZHvdu9PKrg+Tr4TJ6GPaXsfWvE81N/qz4hfq+W4nlgafELEJf1zQmDaIo k8EH0YO+uOJFsPjpdMna9GTaAG++nJL9ji16AoXjsuf+iRfDDxOCjn6//+uRHo746PHX6WD8 ftcg0AtN581Y6HVK7CksR5q2irroLxNKWvnVzJmbOGglu9e/9m4HvY9WXYZ9qzYQtrweQfC+ xRsibH7oWHE6d0oB4ZxSak278Y968zRqn3SityctVt7FY2NRQbogGTz2BrMl4/cu2wYzDHsf /nq0LSCbx4PxNbRmjNzc6y6W3AvKaomn43tjVlld+OouyLxPQFcD0Ww5N2uNXgmMUFRo+BPB umcwsjsyAWnDWHrePKmfRZcN9JeyTXgOkz7asF3WCtUOg3AqT0rSKqYNMe353Wg5nEFFqjKZ rqK0pgtV4cJdxF/nqC1mPQRSmFENzW7UDddMX1XEonI9nC7mg/+xuzcVo2TmqIOAOTHXiTEK wcqTJiGmlBQhkY7McAkb5ISGRug+z1VaTjrhsfGRHl5KCKei2MHyeskODP2B8gLIkXzZVIBZ NLoflaJRd+kJL7vhN6O7xW0kb0ydcOh5fTPf/t3yCQd6N9CdHPrdp6g7mo+NwPF04gb2YD17 N38yyzDsznrRNeLsdue9W2uApspXcBwxezJi23u7JmHcvztuXPx0wnsX/4xXt73pfD7oEdDD 3Qxv5cTok8oEPl+137KSxoqENgB+COi6SGOB67moFgYVTF0LGV0ycFcE65XhMjr76awUXV2y fWJRMlggFuwCYe/b55epXN61IlhudmB1F9IQzt1EwWC7hMSwJVwox2jcX3oaM7SkFMzKJJU2 +mB4ITNYjUStTi3YJQnBJ8aduHAoonUkBGmidiUIS/uSQ687kVwIyaNdEeJK4dI5b0U/Vc+i +s8dVtohGYkgVJxyCe9iU5Kf1H6MatXLYCckidSgBKLwuI37qG5YzRUk6Te6D/7gdPllpO6+ naFg53057g202HqMbobzMfrljnrL+ciO5G53nNwfI3v89hFcryIwRnM/h3SC0op4fYh3ovWR 3hcpB/w1VhhcgnyRURMa3PZtANBv0cvWdfCrD6PwB0GnAOCa6I5ac8pxjaYMo5Hc189unxbD XnfExKoa4kfTBxaeH3/9NecAPG+34J+yeNCGSqgY+bGJ7gc9a0KMRqCd3AkZavjNcDDinQ1D drZKW7tbIXszml5D3mdA6vaBN2fNY+g3Z03oAQiYjjs5Zx+j0TTfXcBereQZzD2lsHtbW4xA leNGEz7z8b3NO9qCiWDYevMqmHPI+0rx1zX0gDaMx2gkjk7+SBc0cMR4p+g42guFaxd6yAzE LFPZ2tsqg/z4IrVSOMjDL0S3QCbAYgmTxyB+34D5CZwAArPmj5bmnJ0uDm63c3ke0qhVvwhw N1csFkMPxZvjs5iiVPRQwNxw3LkgIqAJiz4aGPI1mpKXBsdhmVPFS1E9OxMH09Fxo9NGwr1S uEIUsv7TyejJL4Tj86gN3HgVQ1/G76o/cpLi4z6dBCe1oOz1dhuWVBuGYdYtBb06qDVSmgIp oJytsxNJUfJQYGO1ztqCouLLRbxtQJKw50hZkoiClERlXZq6YpV5zAZB5hGNX0KEkvSLpkPn k0Ia5VgaJaXMFzBfPw2WKR2kpMQr+FRiPuUUPvNpD4Y80AjlIuAYRy3JZSfmUqEOtkO/d5M5 8vUKXxIQmhKBMjjjTVs4NW0XA/fIRkWGgXtuoyJLgXt2oyLLQeCc3ajISuCe3qjIHYjc4Q4Y bsg17o/11kX9TA1f8aSFHUkcVnBPY5fCQ11mbwuG96x85rTSo90/4+mVzMji/eJohg4Xoy5Z lJULOIBjX90SJmUO4TURyo61JfpT8AlvGQb8SOOTvbC/umhfXSKKHigt6GyA75yRy90kXiJK T2DkHEs1tnIwUasSMHp3OeR+ZkXFpQQb1V0Qt3LTCPM5sBTwV7Bj3z+KIyFTI/pqVXztbbWl xcMUP0eYMOQb7voSSoorm4LMIClhueRLyOOv7HjEhxPpdiu+dILgShLEJDwIE19UESQiwgCN hR3NY+N4LZWEF+ocQyOiQP6EVoncVReKn9rjP6wFTEGWS6mCNKKfJ0jp9CwWJI104rkk8lgY 4vVwazSj6skJ3uoc+UrNRyAYf67acsVMfatOB4B0t8UtS0EI10+Me4yDVSOtoNQ7zHgJZY5s V7UaZJzpoq115mv4m3UWf42zq1ZdUHSzBot61PwRy5jRCpkl/yHFokFW67Rghq13rloXuLW7 qnvThG4asbL151Fy6Tv11nnjAi/NfQnKngQtLIyPuOISn1bP2gnUOy71Sf2y89ZPveuTDl4u 4Q2Bh37PoK+ew3qu1Wq2/Mz3HeLLaiup3AcO8XH1JGpe1ponfhlWnQQXTaCvt6oX/rIfOwkE Nfnz9SapJSZJVp4TJ83VBaLMNKpnjX/UT3ATVD3zJayvSFhtvfElO12RrH5Gt4mepGHRFeHV eb3VqEXNn+qt07PmO18Nw9BJhpbIzYuILjK9SUpu616dntZbKUnKHu2p/Vh9U09JU3HSnDTw kjs6/iX6R73V9Cba8WreRfXcr6nhris1oAXt60SnzSu/8oVux6Hb2AtQBS+923fifumjN7tP cqcMzW4DXYbPJLgpa3sTHNsJsLZtaIsE8dRsennp6SM2OwvKvd14A8MmjPRe+rpDj46L6wl1 PXWoa2/rtR/bV+de+lLRoYcBC2rbwQw89KGHfxVvxRPoSx7+nbeJmlYqO/R4we+nrTi0YjL3 k+9YraR010e86xDXf260O35iU9NTCE0V52Owl9DUbfQwFTWP/0+9lsC36pKTy3g/taneYlRK G/5KpoJDFB5qpSU48SQAWaekqDsCR0sZGsf9E3PJVHUoTRsH5PNG+7zaqb31JSmb2i72V14h lU1Fb4OS+zW2bGq4GKh9hKZqdxrnCY1fNvVaoHcIEm8CXbMx8rz6syJfhx6mwFT6XXdf2Vz0 2U13PBw9sZu7SU8ZvG1rW3TOG1Yo7ZPTq4saDP9njQtoZy2DABmdd2fng/F0/iQQLPNiCZ5n /PtrPKfkvvuR/GqSlICfZ9LOiJM2JvsZa6GPNHyHI0nC3SQa3AVwmnLJRxOXqXm3dHLipdp3 CN38OGW465C62ZpVtSXZGnT7l71h7ebD8dNykJFi5H+Z9WGfkWCTebybzvsreIS7q5icPKzm Ah+8XN6hR6r167OCxVrVWcFjvdpkjf2pvxvIrhKfB/ADLREuoCrocGrcnUXyNiRzPxamSJHw g0a+1m1bIZES8Wkj+I6WHtRXkJS26/zYi2xsFndj1Y+8DAnGQpUEvumF0HSWPylD7+cqT9uE 6bWfHHlaJkQJlPP1SfH5aMa2jUmg7SexNQ4a9BbyGYHTY63fwQic89WNwHnIM43AKZH9jqpy WCk7RuClP8oI/NlO1U0WInHvtjsYsTYBq33HAdbWSgnxwy8G5l8MzL8YmH8xMP9iYL4xA3Pu 9dAPSelexbmQlLm1ISnVfZ0NQsc9aBggcJqRURIkpU6yHiSlua8yISkT4kL3LtWEpEyIK7s3 qT5Iyrjm7+wqrYKktJm7kJRJFAqSMonAKOGmICnJpfzLIClznwdJSbe3pOvPhKS0654MSZlE 6UJSJlMmQFLmXEjKXGqfFJCUK/ulAUkZ900PZQxJKUSZBkmZkq8BSZk8GqwBSWlK0QdJmU5B kJT2nV8yJGXusyAp102tICmVwvL7TBuS0h2VJSRlbiUkZc6EpDQF4IekTKRRkJSJFARJmTMg Kc26NbabChgyftrkv5LVXFg7g5vuNdhpfN1/sDNi655UnSFb94vqGL9ofjMDe5yMPUoGwa4n Dj31BMGePwYGjH1PzGmj1e6ctur14MATC0u8ZhAUfHUnpUZjElNphtNIiV4zplE4nQi12RMa g16a6AWZ+CLN9n0oDQoZwYPtwCEV1HjMlyoclTRnWlt4YElzFixpzoIlzVmjmF5ByxW66Jie WnN00pyFTprzoZNqydVBzNw1bNbQSRMc0MZO4LzopHoqhU6a86GTegJNdNJcMjqp81iFw5A6 r1Vk8NBAJ9XJLHRSs1GegU6qEnrQSXOpo2oqOunq4TgRnTS3Gp00Z6OTappOlifSdpfGPmnz pZtDmq7EAtui0nKyhaOdg9f4fCyDIw+Xz/XPn8LzxY7qU3i+zEu06wSdu6L25/JiX9SJHF/m +DiB3Wf4EU7j+DK/mMkcX+o9NY3ji8uod1ATPpj3zQ3BB+c2CR+cS4MPTs/p2fDBOS98cLyE E8a8lLspMhOF9/m4uInnE772eQZEcUqSRIhiRw0cLVgTotgvnJdCFOf8EMUpNfzspkiFKE5o ks92w+ruh8Zq956UKXCci6szRALyiuX5wMa5GHlYNt+kj+N4EpM1GkeIhi+Y1tPYHshnHhkr LVFXs5gUFsTrFLGAMmlN3MPZuDtji7trvigzVyjCOPa8esnNGBr/qAfhrrazwHh8EkbLdZQR 5DkfDvRlIMYE2h1lMOvGXmb18HsznN9+qq2HtuAUe9ngE1uy924JpQG/EopVVi4e4WnBJeFX o0SDH4/krXGil4jY8YLebFIph0vKKpp3Jx8G6trXpVT+LTRq9YSSoWCEbtF37lI57kYoEktb hbr2l/HFsn2nyuC3XhqtMfgoQpfdy3v9ipnNuiuT3C9nRpL7rvm47W4RG2Rvmf05Lnl3uez2 btWWbmV/ff3QnSyH/UcCYFMT5l2ETwuwM84JpJB/E16o/Y1vXdfPUhoNKjsejBWBqmEyCLq8 rXoWCDoehC2G4+GoO3fFZQCiW8eN6wOi2wk3BIjuXMyb7k//GLe/VhkS/f6WDb+/ZWYU3HT6 a7GMvf6GLCwfFsPDcDdAhqbX36RUwu3v/uFOiQwBKqX8HsvRb3T6u6YvXvjpLRMivO5+1/SO C9xuJikmZcx12Iupe91ouuhzBmTFwdDQJtkeJ0l1cKD8o1VHliFRdUqG6pSYUXCv6sjYWHVA CUJUndJegAy9quOk4qpTKR7uhKQ65VI+LLIc/tkRHqPpGSOUEg8kYN6fw8gEbSR9SSfAOX+m J2mpWjr/zTh6XokCvZ4X5jQqIeQVVLhC1/w5D8v7u9v0S8wUvdv+YPYvVdukIqyvtWbJUW+T eCoFLJZYuIMGT+UdpbYrE4kBrwiJSGvD/A5aPnGNRbunQpJ10cZNk24g5TWMU5SSJZkfQYTo Sp9tfkR+3cv5sMJy+Cfcld10Q+YBzDYPwLIX0Dyg0T9ktmaAFlQYb5Z9+J+FlcOwdAhDiJAs qz/O2J+RhzIvOGSrFQ6Vi3lUxGWb4s9+M5Dyhmd4fYJS5TWT3o+37212EIYLXcUuzcI6Ibd4 OiysZZ36nGFz3I8kxr0beT/2CS6O3d9NiJr1ttEz11qD7goP+jnXn95rAeFiLbsJkCVeyJOn E7F1w1Bn6U5bNplCXiv3PubZ6969COdXWsM8e4I9tQjj73Rf9zlqD4bQSh7/Qe8ZoFsobuBw O2Ct9gm77LSY8rmyJSm3RQY3iJnCy4no8CA0dLmyIDaZYp59I1l8k2f7eRbu5lkxm+VYP19J 6LwMQZlr5WEfBrDYZ/fD+fKuO2Iz4ZxwOeVwL4afGEIFQrF+zzxmv5k7SDpbzqNllhyWXKI9 e6f5E/6RBc8KyWCtM717ZKSONl5nkRHsbT4i5jxsvwh6Hv58J3H0rDyzEJnLCQyTjyz3Pevd vx/+KrJAnBRH6Kfd4QgliXWTG1jWnw4Wk1d4GrTs3frEDsy/RilSTnKrg6U4ZMdd4b4Pq0xg 0YqvRAi3BC/Khn9Si0cMYSu3nE7ZFPZy0CKwjwMJLJYP0/ny9kmVlLZ9DwO56aP8iUVcsOtR t/cRr5+2P0ynfbKvvB24OsabFtV2VXtyUPcdWSFUekyaeZ0BHjm2m2UF9qr4CoF80DVMjsmY PRlzFMuXUn/H9khP6Qu0ZVgsuiQHB95GwCpKOWX+srW/ANJiuA3/QwLCd+rPUtpCaDaP45pl 4vmewvDB7We6MwZbanT6OIXJl6/hFtyGF810IaA7R7PSLndmNPlArhum1BTcmBe4jAbc4ve8 wS12P06mD2gYe0fB4y3G2r3uJG5CkRtlvhCHln3idv1kMJJFJLwmyJXv4hhdn3ugf/WDBjUk ik6GQ/bNHC1q7sc3R04U3mANHpcQ2TMj+bgEnIPX+FtE6ic6wX3XHDPVaHT9fwfzaeZbyDBv dXlVmmw8dnmPwrLeoRalqQmRFkuNiw4uGOr7+EDS6AVQp63JDGS8oBFIVA8TIuISnXlmsUCY L5JhiXsw4OYZvh44rsKyKieAly7xZW/7beO0k80qUUBKGHTx7QRPaLy1wHwQ82h8swU/EULR qy/9YVw9RXD9qJWyz42nVGSXIh+xkkd6eB/D6Xyz3XhjxPQwxhS+alLqQjgsUx1wsIPdwQjG AnROw5sNa8TJEDGO/fYb08vydZwpdnVqc4HoxG0YUd0L0wc0o+Pt9dcY6AxLUPiB3KDgnPZY LCN7J7TCRwilIb4jUJ6IH3/yz6PB5MPyNq+xk4ByNEbwsydsqVjqNCX41O0cNAV7pXJvRpmK UeK2ez+AoWEwUXf43L0Gn2/FsYulkDRbatOhOmrekgfj8UR43yUt1TSKDk/hB5ZMmTjlEmbK LXFonmdWuALUs8LFYTpqQDcePj+5u1Na0v0xu1KedfLx2755/rbPRFnNfSgPDOSepRziWFGu cJwt4GFuQA3qg+3SAaJyAXWZP7kph3jSBr/VLqyGozU2a3/QHWEJ1TMEPu1P2OP+LrusCaOW xZbcxMTr/m/cQ5RvhosuhSQerGBpdop0eFM5EMWJSSH59mwyc484RIRCqsLNCbuguekHVkw6 lhFbEEIME+fA3JNdp9rqBMXHATkyseLwMoi7+IIovm2v7OdLu7Bzr5RFialzyyUAlAvFz5di l5PLxJUYg97MuMra5RcduCA6sFo3qRB1cYMrMu73jybbW1hxLNy1u0y3zT+8dOkuF50FFjxr oc5z1wr9Oet1wcy/YldZvGjZXuAtaazdRXaf5Af5FwTQuInX7NAM+BZEGCcx7sYU+FnLdcrh mSt2SqMq9j2uFdHZd/Gxi0r53ffQVhG01Xcw7WFAMRa4KvYnXfelBqAr4PvB/Hq6GGDReN2B 8Wg6/Uji5W+UaDGoNIn8G5kK3yQyKr1GdjO9m/QPeQ2c4fiPPSdcfURYCUNjVIbvLOmE0D3n K5VYqXxYPjjcKQaclzk6e1LAAL13WAphjOYD9B4N0HtqgA7Qw+4h+1vmT9k49d5WhWWOB/OP g9HgKct2t8vbByEN52mHVtYxGNTMU242W+iHVemjPKzarZDJ7NEKoROuZXf0EcNpFC0WoXa5 gwPnukeexAxn9rWOe/Lji7yDjcDqwx1PylnvOoI9BMRyJOLe9dYtE1R9GOi6OPtt3y0GkDV1 A5fFB/Lhip04IQ9OsJBzX1jikx/+tWc/miiX8y6/GPDwgt5Ge5AXzoG6MQVuW0A5WBRdZjJ4 3UoIv7hHMMj61yN6DSOsheecnvZrSCqmx939PGgVzI+7FdG4gXm1nqelKCwB31++/UUswMmi gQWgJriGfEI6NP5lAbmOZPwMAM2NC7HJRSEITOOBIzOIL6LjQGVEgEGfmNwQBva+QsbAuiVY cw8oCUXFFK34jiQknJ1yKQ/9LBfulCp5cQqO/okZehfGGTVtW8gC3hnFAgUlB4JjgciLSp01 43FrA+uXnXLlpBLuFDnG9iuMeUW8qG3M7SXw28DeEvl+3sbSVWm/tQlOkUKrQX+4vKNh/1HW xtmZMrrlhz8J+1I9wtqYFgJrZyraQJjzrLdnBf5rbVpZsMauFYgkCjFXsB3ofWVUsIrqfehi RXWArLbZ5HGvM5oBaTYjz9u+1Xei0MqVbD6BFyehdrAajBxH4w5TWImPuku1lWYNfFuFShg8 ez8NSZINivQKFgJuJZOyqy4gILfUoJyUupbv15RvyGX9YQorXHqZOb+boJIaixs+5MbzzL98 fWMXIHGJY247xa7zVlvb2JzEYqWyTSC4h5X9w3IYIJ94cZOQRG5AK7vS1KMU7udBR/GPGAM1 Sx9MG+5G1Cv03gNNvUCHIUI9j5xE5ZKXnrQV/5C3UXtKw8GId05YRfWW0/nC7LKDD/wJ5muO xWi880Jn1nxolkOq8dpLmUCBbmoekOmGBfTKMkJcY7TOOROVujaSKATCttAMlPNgHKxbGFqu 2pnpq12oNx4EkRFOtHia9G7/pSt3J+9EpUa36rpaw3dmFBrV22EXq2mFFYuH5fLhDmp2KPyY pNDTsn1n9zA8ILU+CMv5A1jThnjDLU4GaLs0Hvbm07sZvorIfDsZPEQc8x6/0ziPAw5+ue+O euOZTQITgv7luyydrOFQi0sCdfegZ5JlD2hPfA0N+dCd9xcs85dRf+svxd1RnxV+YOoLXUYg EzpSVplsLe9B89FC2wi6wzBJbZZRpXCDMVXsngiTmzQ4V6ovdCzC0EMRn6FhDJ7hSEuEsCvP +PmzgqeoWabUN14C/wv1Ns70WbYoYhSOU6tTP9A3GHnLRX7qx61OHDJpZ7JTPCyVhJ1JuQyj LTraAZ0s+C1NNuJhJ4HtegYshSQzlAI35diEGUphM15wCroXnMJGvOAUNuEFp7ApLzgbKI30 glPYoBccqQkb8oJT2JgXnMJmveAUNugFp7BZLziFDXrBKWzMC05hs15wChv1glPYnJlbwTZz K9hmbjjZwHB04DFv27Xs0Ape8zZ91tIM2ozZx2WERwkFYTIdRO1f2tzj8dtIHUdYofYB1XDa 6025US1OUeuglRZctNJCAlqpFo5opfFXiVZaCAy00oKDVlpIQTTiJU57NFOwHqX4S1r51cyZ UK30kt3rXwVaqVEXgVZqhMVopTpviVaq8dPQSnVKiVYanys9E61UZ/YMtNLVEl8TrVQKX0Mr 1YsUo5XqoTFaacGLVlownpI8C600LWkKWqmhohKttOBDK9XrodBKtWpo7/PccIVWqkVoaKVa qIZWqudoot1ZMdeJMRq+nZMmIaaUFBFD2enhMYadFRoaoQ5aqRWuUEmN8FJCeIxWqgXHaKVm YOgPlEfbPrRSXQF0tFInvOyG62ilnnCBVqrlG6OV2oECrVQPVmilWmCMVqoFKrRSV8MrhMFo 9FaOSOrpQ89HJE1nshYiaRKLtRFJExk8C5E0kctLEEmTmL0IkTSJ2fqIpEkcnodImsRlTUTS pOTrIZKuM5WthMXUprH2yxYQBixmAa+dCp8Ni1kwYDELgT3hW7CYxsibBItZSIHFNBvCD4uZ TCNhMd0RxVMKu8mfA4tZ8MJirtQDWuAnwWLKZfbnw2IWXgCLWTAc9vhgMV0KGxbTpXBhMV0a FxbTpbFhMV2KBFjMdFHYsJguWxsW06WwYTETW3BtWEwzDx8spkthw2K6FDYspicXGxbTT6LD YhZ8NImwmAmiSYfFLJjgkwk8VsNi+vl8Diyml2MiLKY53liwmAmRHBYzIZLDYiZEcljMhEgO i5kQyWExC2Z0oyk9sAZRo5l5dfkqz8KsQyP9uMZEJZcI9APUg3JDunecsMwv4MQ5Q1/D45Tj 5nPwOAv6jMqdLvjxOD3mJivxOH2EXjzOgo7HWfhkL2tfhMcJ8tmkuw9gp2MXJLj6MGhSnXxo /j001x7G/IcFc3BEC8IOTcMRLaShWBYSUSpXxXMUy5i5hWLpJrRRLBXF0ECxdBMODRRLFW/h iLrpLBzRQkySgCOq4r04olr6FPjLggdH9D+tBUxBenBEdUG6OKJrC9LBEeVTg40jmsZNxxH1 lJoP2QJHlHOnvvVcHFF1tGtMBR4cUXu1bOGI6ixScUR1snVxRJ00K3BEHfpVOKJughQcUYc4 FUfUoU7FEfVIJxVHVKdfiSNqE6fiiNrEK3FE7QQrcUTtBGvgiCYlScMRtdOsjSOanjARRzQ9 WSqOqCPC9XBE7WRr4Ig6rbsaR9TVntU4onaatXBEfZqXhiPqSG0dHFE70SocUVfG6TiiOn0q jqhOuBaOqJVgJY6oRZ+OI6oTr4MjatOn44ja1KtwRG36VTiiLv90HFGXfzqOqE2fhiNq067A ETVbaQWOqE2ciiNqaGIajqhOmIojamS/GkfUIU/FETXkthaOqJ5iLRxRN8EqHFFb4KtxRPUU a+KIGsVKxxE1SNNwRHXCVBxRo/HTcER1wrVwRM2F42ocUZN+NY6os6/04ohqJgz9FC83WgZr 44jKvfEqHFHIfSWOaGENHNHCGjiiWpnScURNwlQcUZM0FUe04EryBTiiKTzWxxFNYfIMHFGH y/NxRNNYrIsjmsZjbRzRtTw1FYzzgBilUh0XrY0jalvxpOCIFobr4IhatjapOKLGudVqHFEP eQKKp5/xuqSJOKIe2iQc0YJx0GC0kBau2WRh5P8D4sc04cttAQA= --==_Exmh_12416069040 Content-Type: text/plain; charset=us-ascii ... 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 --==_Exmh_12416069040-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 22:48:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 3F00C37B502 for ; Fri, 29 Sep 2000 22:48:20 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8U5nbA26807; Fri, 29 Sep 2000 22:49:37 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009300549.e8U5nbA26807@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch In-reply-to: Your message of "Fri, 29 Sep 2000 22:05:17 +0900." <20000929220517P.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Sep 2000 22:49:36 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Iwasaki-san pointed out, I left acpi_event.c out of the previous megapatch. Rather than resend the entire thing, you can fetch the complete patch from: http://people.freebsd.org/~msmith/acpi-20000929.diff.gz Regards, -- ... 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 Fri Sep 29 23:20:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.sanda.gr.jp (ns.sanda.gr.jp [210.232.122.18]) by hub.freebsd.org (Postfix) with ESMTP id 9C7DC37B503; Fri, 29 Sep 2000 23:20:10 -0700 (PDT) Received: from ever.sanda.gr.jp (epoch [10.93.63.51]) by ns.sanda.gr.jp (8.9.3/3.7W) with ESMTP id PAA54708; Sat, 30 Sep 2000 15:20:08 +0900 (JST) From: non@ever.sanda.gr.jp Received: from localhost (localhost [127.0.0.1]) by ever.sanda.gr.jp (8.8.8/3.3W9) with ESMTP id PAA16226; Sat, 30 Sep 2000 15:20:08 +0900 (JST) To: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG, non@ever.sanda.gr.jp Subject: Re: [CFR] ncv, nsp, stg SCSI drivers In-Reply-To: Your message of "Wed, 27 Sep 2000 15:25:42 +0200" <48378.970061142@critter> References: <48378.970061142@critter> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000930152007K.non@ever.sanda.gr.jp> Date: Sat, 30 Sep 2000 15:20:07 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 16 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Poul-Henning Kamp Date: Wed, 27 Sep 2000 15:25:42 +0200 > Use a normal timeout ? I changed to use timeout() and now they do not change clock.c. Updated files can be obtained from, http://home.jp.freebsd.org/~non/scsi_low-20000930.tar.gz (added files) http://home.jp.freebsd.org/~non/scsi_low-20000930.diff.gz (diff to current) http://home.jp.freebsd.org/~non/scsi_low4-20000930.diff.gz (diff to stable) You will need the tar.gz file and one of diff.gz file. Or you can obtain the diff from, http://home.jp.freebsd.org/~non/scsi_low-20000926-20000930.diff.gz // Noriaki Mitsunaga To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Sep 29 23:32:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from tkc.att.ne.jp (tkc.att.ne.jp [165.76.16.7]) by hub.freebsd.org (Postfix) with ESMTP id 928E137B66D for ; Fri, 29 Sep 2000 23:32:21 -0700 (PDT) Received: from work.mzaki.nom (59.pool0.ipctokyo.att.ne.jp [165.76.244.59]) by tkc.att.ne.jp (8.8.8+Spin/3.6W-CONS(09/21/00)) id PAA25686; Sat, 30 Sep 2000 15:32:13 +0900 (JST) Date: Sat, 30 Sep 2000 15:32:11 +0900 Message-ID: <86lmwafl04.wl@tkc.att.ne.jp> From: Motomichi Matsuzaki To: Alexander@Leidinger.net Cc: current@FreeBSD.ORG Subject: Re: config(8) weirdness In-Reply-To: In your message of "Sun, 27 Aug 2000 15:16:01 +0200 (CEST)" <200008271316.e7RDG2i02168@Magelan.Leidinger.net> References: <868ztilx3p.wl@tkc.att.ne.jp> <200008271316.e7RDG2i02168@Magelan.Leidinger.net> X-Mailer: Wanderlust/2.2.12 (Joyride) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. At Sun, 27 Aug 2000 15:16:01 +0200 (CEST), Alexander Leidinger wrote: > > Can anyone success compiling kernel with the following config? > > > > # ATA and ATAPI devices > > device ata > > device atadisk # ATA disk drives > > #device atapicd # ATAPI CDROM drives > > device atapifd # ATAPI floppy drives > > #device atapist # ATAPI tape drives > > #options ATA_STATIC_ID #Static device numbering > > #options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices > > > I've the same problem. This is obvous BUG of config(8), newly introduced 'count' feature. In /sys/conf/files.i386 : dev/ata/atapi-all.c count atapicd dev/ata/atapi-all.c count atapifd dev/ata/atapi-all.c count atapist On the current implementation, the first line is only effective, i.e. same as: dev/ata/atapi-all.c count atapicd #dev/ata/atapi-all.c count atapifd #dev/ata/atapi-all.c count atapist Then, atapi-all.c will be copiled only when atapicd is enabled. To exchange the lines of files.i386 takes effect as a symptomatic therapy. But..., fix for config(8) is needed. -- Motomichi Matsuzaki Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 0:39:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.iafrica.com (smtp02.iafrica.com [196.7.0.140]) by hub.freebsd.org (Postfix) with ESMTP id B4D4337B502 for ; Sat, 30 Sep 2000 00:39:48 -0700 (PDT) Received: from [196.7.18.138] (helo=grimreaper.grondar.za ident=root) by smtp02.iafrica.com with esmtp (Exim 1.92 #1) id 13fHFB-00020N-00; Sat, 30 Sep 2000 09:39:37 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e8U7dai08847; Sat, 30 Sep 2000 09:39:36 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200009300739.e8U7dai08847@grimreaper.grondar.za> To: kdulzo@gerp.org Cc: freebsd-current@FreeBSD.ORG Subject: Re: IPX requires 'device random' References: <20000929105701.A20184@caffeine.gerp.org> In-Reply-To: <20000929105701.A20184@caffeine.gerp.org> ; from "Kevin M. Dulzo" "Fri, 29 Sep 2000 10:57:01 EST." Date: Sat, 30 Sep 2000 09:39:36 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I am not aware of the full status of IPX networking support in -current , > but I migrated my -stable kernel config as best I could. Kernel compilation > completes, but linking fails due to a rand_ function not being present ( I do > not have the exact error handy, but can generate for anyone who wants it.) A > simple 'device random' to compile the support in statically rectifies the > problem. I'm aware of this, and I have an uncommitted fix. Please be patient :-). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 0:52:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id 10DF137B503 for ; Sat, 30 Sep 2000 00:52:33 -0700 (PDT) Received: from castle2.jp.FreeBSD.org (castle2.jp.FreeBSD.org [210.226.20.120]) by updraft.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id QAA26568; Sat, 30 Sep 2000 16:52:31 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by castle2.jp.FreeBSD.org (8.11.0+3.3W/8.11.0) with ESMTP/inet id e8U7qSX37322; Sat, 30 Sep 2000 16:52:30 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: current@freebsd.org In-Reply-To: <95237.970250972@winston.osd.bsdi.com> References: <95237.970250972@winston.osd.bsdi.com> X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.2 (Molpe) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 14 From: Makoto MATSUSHITA To: jkh@winston.osd.bsdi.com Subject: Re: sysinstall: Avoiding version checking of CD-ROM (patch included) Date: Sat, 30 Sep 2000 16:51:09 +0900 Message-Id: <20000930165109J.matusita@jp.FreeBSD.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG jkh> there should be a boot/kernel/kernel.ko file and I'm not sure why jkh> there isn't. This is because 'release.3' target (in src/release/Makefile) does not know that the kernel should go to into ${RD}/trees/bin/boot/kernel. Note that we cannot change 'doKERNEL' target, which is also used by other places (see 'doMFSKERN' target). Other modules and boot stuffs were installed by 'make distribute' (of src/sys/Makefile), in a procedure of 'release.2' target. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 3: 1:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by hub.freebsd.org (Postfix) with ESMTP id E91C437B502; Sat, 30 Sep 2000 03:01:08 -0700 (PDT) Received: from fmrl01.sul.t-online.de by mailout02.sul.t-online.com with smtp id 13fJS1-0004Dt-00; Sat, 30 Sep 2000 12:01:01 +0200 Received: from neutron.cichlids.com (520050424122-0001@[62.157.56.207]) by fmrl01.sul.t-online.com with esmtp id 13fJRo-07PllwC; Sat, 30 Sep 2000 12:00:48 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id C48ABAB99; Sat, 30 Sep 2000 12:01:34 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 8B3DC14A5C; Sat, 30 Sep 2000 12:00:37 +0200 (CEST) Date: Sat, 30 Sep 2000 12:00:37 +0200 From: Alexander Langer To: Donn Miller Cc: current@FreeBSD.ORG, imp@freebsd.org Subject: Re: setting device permissions for DEVFS Message-ID: <20000930120037.A4899@cichlids.cichlids.com> Mail-Followup-To: Alexander Langer , Donn Miller , current@FreeBSD.ORG, imp@freebsd.org References: <20000929180208.A821@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dmmiller@cvzoom.net on Fri, Sep 29, 2000 at 01:28:06PM -0400 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Donn Miller (dmmiller@cvzoom.net): > > What is the suggested best way to set permissions on devices in DEVFS? > > (I want to chmod 664 /dev/acd0c to let users in the group operator > > burn CD-R's). > > Do we already have a common way that I missed? > /etc/rc.devfs Ah, thanks :) Can we add this to UPDATING, please? Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 7:29:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 1924D37B503 for ; Sat, 30 Sep 2000 07:29:11 -0700 (PDT) Received: (from uucp@localhost) by rina.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W-rina.r-0.1-11.01.2000) with UUCP id XAA97646; Sat, 30 Sep 2000 23:29:08 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W) with ESMTP/IPv4 id XAA71215; Sat, 30 Sep 2000 23:24:01 +0900 (JST) Date: Sat, 30 Sep 2000 23:24:00 +0900 Message-ID: <14805.63360.137164.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> From: Seigo Tanimura To: n@nectar.com Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, current@freebsd.org Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior In-Reply-To: In your message of "Thu, 28 Sep 2000 11:55:55 -0500" <20000928115555.D42464@spawn.nectar.com> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20000924100812.A23848@spawn.nectar.com> <200009281350.WAA23538@bunko> <20000928115555.D42464@spawn.nectar.com> User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) Organization: Carrots MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 28 Sep 2000 11:55:55 -0500, "Jacques A. Vidrine" said: >> It would also be helpful for us to (semi-)automatically update old >> binaries installed by ports. (I have been trying this for a couple of >> days) Jacques> Personally I don't want sysinstall or make world to touch my ports. Jacques> But a tool to do this would be great. Completely automatic update of installed ports is acutally difficult because we cannot get to know the language or required toolkit from the name of a binary. (eg emulator/wine and japanese/wine, timidity++-xaw and timidity++-tcltk) We can still detect and enumerate the ports that possibly installed old binaries, and decide which of the ports listed up to update. http://people.FreeBSD.org/~tanimura/tools/oldports is a shell script to scan the binaries installed by ports and to list up the name of the ports that installed binaries using libc.so.3 or earlier. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 11:10:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-27-149-77.mmcable.com [24.27.149.77]) by hub.freebsd.org (Postfix) with SMTP id 3382237B502 for ; Sat, 30 Sep 2000 11:10:28 -0700 (PDT) Received: (qmail 13371 invoked by uid 100); 30 Sep 2000 18:10:18 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14806.11402.323948.403889@guru.mired.org> Date: Sat, 30 Sep 2000 13:10:18 -0500 (CDT) To: Alexander Langer Cc: current@FreeBSD.ORG Subject: Re: setting device permissions for DEVFS In-Reply-To: <20000930120037.A4899@cichlids.cichlids.com> References: <20000929180208.A821@cichlids.cichlids.com> <20000930120037.A4899@cichlids.cichlids.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alexander Langer writes: > Thus spake Donn Miller (dmmiller@cvzoom.net): > > > What is the suggested best way to set permissions on devices in DEVFS? > > > (I want to chmod 664 /dev/acd0c to let users in the group operator > > > burn CD-R's). > > > Do we already have a common way that I missed? > > /etc/rc.devfs > Ah, thanks :) Does it possibly belong in /etc/defaults/rc.devfs, to slurp in /etc/rc.devfs (if it exists) at the end? ; Sat, 30 Sep 2000 11:18:07 -0700 (PDT) Received: from fmrl01.sul.t-online.de by mailout00.sul.t-online.com with smtp id 13fRCt-0007Ae-00; Sat, 30 Sep 2000 20:17:55 +0200 Received: from neutron.cichlids.com (520050424122-0001@[62.157.56.207]) by fmrl01.sul.t-online.com with esmtp id 13fRCn-0cC9BoC; Sat, 30 Sep 2000 20:17:49 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 7C02AAB91; Sat, 30 Sep 2000 20:18:42 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id BAAF414B09; Sat, 30 Sep 2000 20:17:38 +0200 (CEST) Date: Sat, 30 Sep 2000 20:17:38 +0200 From: Alexander Langer To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: setting device permissions for DEVFS Message-ID: <20000930201738.A17165@cichlids.cichlids.com> Mail-Followup-To: Alexander Langer , Mike Meyer , current@FreeBSD.ORG References: <20000929180208.A821@cichlids.cichlids.com> <20000930120037.A4899@cichlids.cichlids.com> <14806.11402.323948.403889@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14806.11402.323948.403889@guru.mired.org>; from mwm@mired.org on Sat, Sep 30, 2000 at 01:10:18PM -0500 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Mike Meyer (mwm@mired.org): > Does it possibly belong in /etc/defaults/rc.devfs, to slurp in > /etc/rc.devfs (if it exists) at the end? No - instead we should add something like devfs_permission{0,1,2,etc} (and maybe ownership) to rc.conf, which can be modified there and then rc.devfs sets them - similar to the ifconfig stuff. Opinions? Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 11:18:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16]) by hub.freebsd.org (Postfix) with ESMTP id 5219437B502; Sat, 30 Sep 2000 11:18:55 -0700 (PDT) Received: from fmrl03.sul.t-online.de by mailout00.sul.t-online.com with smtp id 13fRDn-0002x2-00; Sat, 30 Sep 2000 20:18:51 +0200 Received: from neutron.cichlids.com (520050424122-0001@[62.157.56.207]) by fmrl03.sul.t-online.com with esmtp id 13fRDg-1lkiGGC; Sat, 30 Sep 2000 20:18:44 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 1DE41AB91; Sat, 30 Sep 2000 20:19:38 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 020B114B09; Sat, 30 Sep 2000 20:18:43 +0200 (CEST) Date: Sat, 30 Sep 2000 20:18:43 +0200 From: Alexander Langer To: Donn Miller Cc: current@FreeBSD.ORG, imp@FreeBSD.ORG Subject: Re: setting device permissions for DEVFS Message-ID: <20000930201843.B17165@cichlids.cichlids.com> Mail-Followup-To: Alexander Langer , Donn Miller , current@FreeBSD.ORG, imp@FreeBSD.ORG References: <20000929180208.A821@cichlids.cichlids.com> <20000930120037.A4899@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20000930120037.A4899@cichlids.cichlids.com>; from alex@big.endian.de on Sat, Sep 30, 2000 at 12:00:37PM +0200 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Alexander Langer (alex@big.endian.de): > Can we add this to UPDATING, please? Discard this statement. The absence of a well-working DEVFS made me forget that it existed before :-) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 11:35:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-27-149-77.mmcable.com [24.27.149.77]) by hub.freebsd.org (Postfix) with SMTP id 8CD8A37B502 for ; Sat, 30 Sep 2000 11:35:49 -0700 (PDT) Received: (qmail 13873 invoked by uid 100); 30 Sep 2000 18:35:48 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14806.12932.647387.503859@guru.mired.org> Date: Sat, 30 Sep 2000 13:35:48 -0500 (CDT) To: Seigo Tanimura Cc: current@FreeBSD.ORG Subject: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior In-Reply-To: <14805.63360.137164.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20000924100812.A23848@spawn.nectar.com> <200009281350.WAA23538@bunko> <20000928115555.D42464@spawn.nectar.com> <14805.63360.137164.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Seigo Tanimura writes: > On Thu, 28 Sep 2000 11:55:55 -0500, > "Jacques A. Vidrine" said: > >> It would also be helpful for us to (semi-)automatically update old > >> binaries installed by ports. (I have been trying this for a couple of > >> days) > Jacques> Personally I don't want sysinstall or make world to touch my ports. > Jacques> But a tool to do this would be great. > Completely automatic update of installed ports is acutally difficult > because we cannot get to know the language or required toolkit from > the name of a binary. (eg emulator/wine and japanese/wine, timidity++-xaw > and timidity++-tcltk) We can still detect and enumerate the ports that > possibly installed old binaries, and decide which of the ports listed > up to update. Ah - there's *two* meanings for "old" here. If you were talking about binaries installed by out-of-date ports, that's easy: weekly_status_pkg in the periodic subsystem will do that for you. However, I believe you were talking about binaries that may have been built from a current port against an out-of-date system. Frankly, I'm not really interested in *detecting* such things. A tool that would 1) save tarballs of *all* installed ports; 2) uninstall them all; then 3) rebuild and install them all, with a report about failures would make me happy. That way, I'd know that all the ports were built against the current system, which would make me feel much safer. ; Sat, 30 Sep 2000 11:53:13 -0700 (PDT) Received: (qmail 38113 invoked by uid 100); 30 Sep 2000 18:53:12 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14806.13976.356085.876527@guru.mired.org> Date: Sat, 30 Sep 2000 13:53:12 -0500 (CDT) To: Alexander Langer Cc: current@FreeBSD.ORG Subject: Re: setting device permissions for DEVFS In-Reply-To: <20000930201738.A17165@cichlids.cichlids.com> References: <20000929180208.A821@cichlids.cichlids.com> <20000930120037.A4899@cichlids.cichlids.com> <14806.11402.323948.403889@guru.mired.org> <20000930201738.A17165@cichlids.cichlids.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alexander Langer writes: > Thus spake Mike Meyer (mwm@mired.org): > > Does it possibly belong in /etc/defaults/rc.devfs, to slurp in > > /etc/rc.devfs (if it exists) at the end? > No - instead we should add something like devfs_permission{0,1,2,etc} > (and maybe ownership) to rc.conf, which can be modified there and > then rc.devfs sets them - similar to the ifconfig stuff. > > Opinions? Well, I like your idea better than mine (though device_chmods="first second etc" then chmod_first, chmod_second, chmod_etc would be better names), but meant to ask - is there some reason that /etc/fbtab can't be used for this? Possibly with some beefing up (/etc/defaults, for instance)? Of course, it needs to handle symlinks. I'd rather fix the symlink for /dev/scanner than reconfigure sane when I add a new device. Possibly device_links, or more work on fbtab? ; Sat, 30 Sep 2000 12:06:32 -0700 (PDT) Received: from C992631-A.pinol1.sfba.home.com (C992631-A.pinol1.sfba.home.com [24.12.58.155]) by shale.csir.co.za (8.9.3/8.9.3) with ESMTP id VAA69431; Sat, 30 Sep 2000 21:06:18 +0200 (SAT) (envelope-from reg@shale.csir.co.za) Received: (from reg@localhost) by C992631-A.pinol1.sfba.home.com (8.11.0/8.11.0) id e8UJ67k09252; Sat, 30 Sep 2000 12:06:07 -0700 (PDT) (envelope-from reg) Date: Sat, 30 Sep 2000 12:06:07 -0700 From: Jeremy Lea To: Mike Meyer Cc: Alexander Langer , current@FreeBSD.ORG Subject: Re: setting device permissions for DEVFS Message-ID: <20000930120607.C349@shale.csir.co.za> References: <20000929180208.A821@cichlids.cichlids.com> <20000930120037.A4899@cichlids.cichlids.com> <14806.11402.323948.403889@guru.mired.org> <20000930201738.A17165@cichlids.cichlids.com> <14806.13976.356085.876527@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14806.13976.356085.876527@guru.mired.org>; from mwm@mired.org on Sat, Sep 30, 2000 at 01:53:12PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On Sat, Sep 30, 2000 at 01:53:12PM -0500, Mike Meyer wrote: > Well, I like your idea better than mine (though device_chmods="first > second etc" then chmod_first, chmod_second, chmod_etc would be better > names), but meant to ask - is there some reason that /etc/fbtab can't > be used for this? Possibly with some beefing up (/etc/defaults, for > instance)? > > Of course, it needs to handle symlinks. I'd rather fix the symlink for > /dev/scanner than reconfigure sane when I add a new device. Possibly > device_links, or more work on fbtab? Can mtree not be used for this? Seems like the quickest and cleanest solution to me... -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 12:10:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from tkc.att.ne.jp (tkc.att.ne.jp [165.76.16.7]) by hub.freebsd.org (Postfix) with ESMTP id DE0D337B503 for ; Sat, 30 Sep 2000 12:10:11 -0700 (PDT) Received: from work.mzaki.nom (59.pool0.ipctokyo.att.ne.jp [165.76.244.59]) by tkc.att.ne.jp (8.8.8+Spin/3.6W-CONS(09/21/00)) id EAA03307; Sun, 1 Oct 2000 04:10:10 +0900 (JST) Date: Sun, 01 Oct 2000 04:10:09 +0900 Message-ID: <86bsx5g0ha.wl@tkc.att.ne.jp> From: Motomichi Matsuzaki To: freebsd-current@freebsd.org Subject: PR i386/21657: nexus without initialization causes booting failed In-Reply-To: In your message of "Fri, 29 Sep 2000 22:50:01 -0700 (PDT)" <200009300550.WAA15176@freefall.freebsd.org> References: <200009300550.WAA15176@freefall.freebsd.org> X-Mailer: Wanderlust/2.2.12 (Joyride) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Caution! If your machine is in P5 generation of i386 architecture, -current kernel would not boot up. See details on PR 21657. -- Motomichi Matsuzaki Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 12:27:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 38BCD37B502; Sat, 30 Sep 2000 12:27:22 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8UJREr22387; Sun, 1 Oct 2000 04:27:14 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: msmith@freebsd.org Cc: iwasaki@jp.FreeBSD.org, haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch In-Reply-To: <200009300307.e8U37NA42511@mass.osd.bsdi.com> References: <20000930000450D.iwasaki@jp.FreeBSD.org> <200009300307.e8U37NA42511@mass.osd.bsdi.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Message-Id: <20001001042705H.iwasaki@jp.FreeBSD.org> Date: Sun, 01 Oct 2000 04:27:05 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > Ok. Based on all the suggestions, received today, and some more ideas > besides, here's the latest megapatch. > > - Move all register I/O into a new file > - Move event handling into a new file > - Move headers to acpivar/acpireg/acpiio > - Move find-RSDT and find-ACPI-owened-memory into acpi_machdep > - Allocate all resources (except OperationRegions in AML) using > real resources. AML fix will now be easy though. > - Remove all ACPI #ifdefs > - Minor style and commenting fixes > - Removed unnecessary #includes > > Please test this; there are lots of opportunities for error in these > changes. In particular, I am afraid that I may have broken I/O from AML I did test it, S1, S5 transition, PowerResource On/OFF and GPE handling by kernel thread, everything seems OK! I think nobody has objections for your commit. I also have something to commit (SleepOp/StallOp, acpi_disable_events()), I'll do it after you. > bytecode. Hopefully with this committed I can finally get to work on the > thermal management. 8) Cool. On some machine, thermal management requires Embedded Controller I/O. Anybody working on this? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 12:57:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 5675F37B503 for ; Sat, 30 Sep 2000 12:57:14 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8UJwWh00606; Sat, 30 Sep 2000 12:58:33 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009301958.e8UJwWh00606@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch In-reply-to: Your message of "Sun, 01 Oct 2000 04:27:05 +0900." <20001001042705H.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Sep 2000 12:58:32 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Please test this; there are lots of opportunities for error in these > > changes. In particular, I am afraid that I may have broken I/O from AML > > I did test it, S1, S5 transition, PowerResource On/OFF and GPE handling > by kernel thread, everything seems OK! > I think nobody has objections for your commit. I also have something to > commit (SleepOp/StallOp, acpi_disable_events()), I'll do it after you. Ok, thanks. I do it in a moment. > > bytecode. Hopefully with this committed I can finally get to work on the > > thermal management. 8) > > Cool. On some machine, thermal management requires Embedded Controller I/O. > Anybody working on this? Yeah. I just discovered that I need this. I haven't look at how operation regions are handled, so I'm not sure how hard it's going to be to implement the hooks necessary for this. There is another major problem here too. Some complete idiot in the ACPI team decided that the "right" way to implement hysteresis for the temperature settings was to have the system send a Notify(zone, 0x80) to the thermal zone and then have it re-parse it's AML to discover new settings. This means that you need to keep a pointer to the *original* location of the AML for at least some methods inside a thermal zone, if not the entire zone itself. My laptop does this too. 8( I haven't looked at the ACPICA code yet, but it wouldn't surprise me if all the embedded controller stuff is already supported there. How bad do you think it's going to be to make it work? You've already looked at the modifications that the Linux people have made - were they just bug fixes, or are there serious problems with the code? -- ... 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 Sep 30 13: 4: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (beachchick.freebsd.dk [212.242.34.253]) by hub.freebsd.org (Postfix) with ESMTP id 09EAB37B502; Sat, 30 Sep 2000 13:04:00 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.0/8.9.3) with ESMTP id e8UK3wN11058; Sat, 30 Sep 2000 22:03:58 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jeremy Lea Cc: Mike Meyer , Alexander Langer , current@FreeBSD.ORG Subject: Re: setting device permissions for DEVFS In-Reply-To: Your message of "Sat, 30 Sep 2000 12:06:07 PDT." <20000930120607.C349@shale.csir.co.za> Date: Sat, 30 Sep 2000 22:03:57 +0200 Message-ID: <11056.970344237@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000930120607.C349@shale.csir.co.za>, Jeremy Lea writes: >Hi, > >On Sat, Sep 30, 2000 at 01:53:12PM -0500, Mike Meyer wrote: >> Well, I like your idea better than mine (though device_chmods="first >> second etc" then chmod_first, chmod_second, chmod_etc would be better >> names), but meant to ask - is there some reason that /etc/fbtab can't >> be used for this? Possibly with some beefing up (/etc/defaults, for >> instance)? >> >> Of course, it needs to handle symlinks. I'd rather fix the symlink for >> /dev/scanner than reconfigure sane when I add a new device. Possibly >> device_links, or more work on fbtab? > >Can mtree not be used for this? Seems like the quickest and cleanest >solution to me... You guys are overlooking something about DEVFS: devices may appear post-boot. We need a generic "devd" which finds out that devices have appeared, set their perms (if needed/wanted) and executes any commands needed (getty, mount, etc etc) by the device. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 13:47:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from matrix.buckhorn.net (matrix.buckhorn.net [63.151.7.244]) by hub.freebsd.org (Postfix) with ESMTP id 1C12737B66E for ; Sat, 30 Sep 2000 13:47:41 -0700 (PDT) Received: from buckhorn.net (nebula.buckhorn.net [63.151.7.242]) by matrix.buckhorn.net (8.9.3/8.9.3) with ESMTP id PAA37708 for ; Sat, 30 Sep 2000 15:42:39 -0500 (CDT) (envelope-from bob@buckhorn.net) Message-ID: <39D6516C.40A16EFE@buckhorn.net> Date: Sat, 30 Sep 2000 15:47:40 -0500 From: Bob Martin Organization: InterNet Unlimited X-Mailer: Mozilla 4.73 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: FreeBSD Current Subject: rpc.statd hangs on boot. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Using current cvsup'd the morning of 8/29, I discovered that rpc.statd doesn't fork on boot up. I don't know if it's in the rpc.statd code, or in the new version of rc.network I installed with mergemaster. I've worked around this by adding an ampersand to the boot command in rc.network. Is this just something with my system? A new make world with the same sources didn't solve the problem. Bob Martin -- As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 14:52:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 002AA37B502; Sat, 30 Sep 2000 14:52:13 -0700 (PDT) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8ULqAr43935; Sun, 1 Oct 2000 06:52:10 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: msmith@freebsd.org Cc: iwasaki@jp.FreeBSD.org, haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch In-Reply-To: <200009301958.e8UJwWh00606@mass.osd.bsdi.com> References: <20001001042705H.iwasaki@jp.FreeBSD.org> <200009301958.e8UJwWh00606@mass.osd.bsdi.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001001065134S.iwasaki@jp.FreeBSD.org> Date: Sun, 01 Oct 2000 06:51:34 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 46 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > > Cool. On some machine, thermal management requires Embedded Controller I/O. > > Anybody working on this? > > Yeah. I just discovered that I need this. > > I haven't look at how operation regions are handled, so I'm not sure how > hard it's going to be to implement the hooks necessary for this. Some VAIOs, ThinkPads require this too, luckily my PORTEGE doesn't. I can test the thermal management code earlier :-) > There is another major problem here too. > > Some complete idiot in the ACPI team decided that the "right" way to > implement hysteresis for the temperature settings was to have the system > send a Notify(zone, 0x80) to the thermal zone and then have it re-parse > it's AML to discover new settings. This means that you need to keep a > pointer to the *original* location of the AML for at least some methods > inside a thermal zone, if not the entire zone itself. > > My laptop does this too. 8( PowerResource code keeps pointers to the PowerResource objects, then finds a pointer to methods of the object dynamically. Can we do it in similar way for thermal management? > I haven't looked at the ACPICA code yet, but it wouldn't surprise me if > all the embedded controller stuff is already supported there. How bad do > you think it's going to be to make it work? You've already looked at the > modifications that the Linux people have made - were they just bug fixes, > or are there serious problems with the code? I didn't read closer, but I couldn't find any embedded controller stuff in both linux-2.4.0-test8 and acpica-unix-20000901 except for definitions in header files. Subsystem/Include/acinterp.h:AcpiAmlEmbeddedControllerSpaceHandler in acpica, drivers/acpi/include/interp.h:acpi_aml_embedded_controller_space_handler in linux. I guess this function will be implemented in interpreter/amregion.c in future. Last time I compared only few files and found many differences between them not only for naming. I think these two used the same code originally, but enhanced separately. Now that it's difficult to compare them... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 15:44:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 3131D37B502 for ; Sat, 30 Sep 2000 15:44:24 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8UMjmh01156; Sat, 30 Sep 2000 15:45:49 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009302245.e8UMjmh01156@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: haro@tk.kubota.co.jp, takawata@shidahara1.planet.sci.kobe-u.ac.jp, current@freebsd.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI megapatch In-reply-to: Your message of "Sun, 01 Oct 2000 06:51:34 +0900." <20001001065134S.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Sep 2000 15:45:48 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>> Cool. On some machine, thermal management requires Embedded Controller I/O. >>> Anybody working on this? >> >> Yeah. I just discovered that I need this. >> >> I haven't look at how operation regions are handled, so I'm not sure how >> hard it's going to be to implement the hooks necessary for this. > > Some VAIOs, ThinkPads require this too, luckily my PORTEGE doesn't. > I can test the thermal management code earlier :-) Swine. 8) >> There is another major problem here too. >> >> Some complete idiot in the ACPI team decided that the "right" way to >> implement hysteresis for the temperature settings was to have the system >> send a Notify(zone, 0x80) to the thermal zone and then have it re-parse >> it's AML to discover new settings. This means that you need to keep a >> pointer to the *original* location of the AML for at least some methods >> inside a thermal zone, if not the entire zone itself. >> >> My laptop does this too. 8( > > PowerResource code keeps pointers to the PowerResource objects, then > finds a pointer to methods of the object dynamically. Can we do it in > similar way for thermal management? Well, yes, but you have to go back and re-parse the actual AML. I'm not even sure if it's safe to assume that the thermal zone is in the same place in the bytecode (it should be, I guess). >> I haven't looked at the ACPICA code yet, but it wouldn't surprise me if >> all the embedded controller stuff is already supported there. How bad do >> you think it's going to be to make it work? You've already looked at the >> modifications that the Linux people have made - were they just bug fixes, >> or are there serious problems with the code? > > I didn't read closer, but I couldn't find any embedded controller > stuff in both linux-2.4.0-test8 and acpica-unix-20000901 except for > definitions in header files. > Subsystem/Include/acinterp.h:AcpiAmlEmbeddedControllerSpaceHandler in acpica, > drivers/acpi/include/interp.h:acpi_aml_embedded_controller_space_handler in linux. I went reading through the ACPICA documentation to work this out. They acually have a very nice technique where they attach the I/O handlers to a point in the namespace, and then when something attempts I/O, they travel back up the namespace to the root, looking for the first matching I/O handler. This means that when your EC driver finds an embedded controller, you just attach your I/O handler to the EC object. Then anytime someone tries to do I/O to the EC, your handler gets called. I can write the driver easily enough, but I don't know how I/O is currently handled in the AML interpreter. The more I look at ACPICA, the more I like the idea of using it, presuming that it actually works... > Last time I compared only few files and found many differences between > them not only for naming. I think these two used the same code > originally, but enhanced separately. Now that it's difficult to > compare them... Hmm. I guess I should spend some more time looking at this. I don't mean to devalue all the work that's been put into the current AML code, but ACPICA has already solved a lot of the problems that we haven't even touched yet (Notify, locking, etc...) -- ... 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 Sep 30 16:35:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id E737E37B66E for ; Sat, 30 Sep 2000 16:35:52 -0700 (PDT) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id SAA11938 for current@freebsd.org; Sat, 30 Sep 2000 18:35:51 -0500 (CDT) Date: Sat, 30 Sep 2000 18:35:51 -0500 From: Alan Cox To: current@freebsd.org Subject: kthread_create() Message-ID: <20000930183551.A2132@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know if it's by design or by accident that kthread_create specifies RFFDG to fork1? It seems odd to ask for the file descriptor table to be copied and not shared. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 16:47:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by hub.freebsd.org (Postfix) with ESMTP id 2577937B66D for ; Sat, 30 Sep 2000 16:47:19 -0700 (PDT) Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp (Exim 3.12 #7) id 13fWLe-0002j5-00; Sat, 30 Sep 2000 23:47:18 +0000 Received: from [204.1.90.43] (helo=power) by dfw-mmp1.email.verio.net with smtp (Exim 3.15 #4) id 13fWLe-0007Cu-00; Sat, 30 Sep 2000 23:47:18 +0000 From: "Tony Johnson" To: "Gerhard Sittig" , Subject: RE: interesting problem Date: Sat, 30 Sep 2000 18:47:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20000929191133.R5065@speedy.gsinet> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I must admit that I have been less then tactful about this thread. I apologize for this. This is my last response to this because once again this has gone on far too long. As far as this response goes. I sense "selective reading." I never said anything abut leaving FreeBSD, even though some developers like Alfred want this, with his "piss off" comments. Mr Nickolay Dudorov said, I must say that (at least in my configuration) there IS the connection between 'trap 12' while booting CURRENT builded (with build+install-world and build+install-kernel) at 27.09 and 28.09 AND disabled in BIOS IDE controller. My system is based on Abit's BP6 motherboard with two Celerons 366. If I disable in BIOS conf. menu standard IDE controller and try to boot the system with the (ATA) disks on the HPT366 controller I receive 'trap 12' after 'atapci0: Busmastering DMA not enabled' message. After enabling primary IDE controller in BIOS without any disks or CDROMs on it I successfully boot this -current system and write this message from it. -current builded at 24.09 successfully boots and works on my system with primary and secondary IDE controllers disabled in BIOS. Unfortunately I have no time to spend on debugging this situation. If somebody ( sos ?) wants the screen shot of the trap message I can send it to you (with the results of the 'nm'-ing the kernel ?). N.Dudorov It appears that I am not the only one who has seen this. Don't call this an unsubstantiated comment... It's not just me. Guys/gals, stop telling me to just use 4.0 and fix the problem. How do I "help myself" fix a problem with boot floppies?? Noone seems to have an answer to this question, except for "piss off" by Alfred, use 4.0 by pretty much everyone, and "forget your damn irq's" by Alfred. Maybe you are coming in at the tail end and you did not re-read all the info that was said here. Please go back and reread in an "unselective" manner. I know "I" didn't break anything , as I do not alter /usr/src in any way. This is definitly an election year... -----Original Message----- From: owner-freebsd-current@FreeBSD.ORG [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Gerhard Sittig Sent: Friday, September 29, 2000 12:12 PM To: freebsd-current@FreeBSD.ORG Subject: Re: interesting problem But it could be just as well the way the handbook told you: -CURRENT is the place where development takes place. Using -CURRENT you're supposed to know what you do and how to help yourself. What the participants in the past thread wanted you to do is to provide some more info to make them able to help you better. Claiming "you broke it somewhere - guess where - , fix it or I'll leave" will make you get answers like "feel free to choose the second". Chances are that the "broken code" works for other people. Only you and nobody else can provide the info what exactly breaks things for _you_ -- nobody else has the system to repeat and explore it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 17: 1:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id DC7BD37B502 for ; Sat, 30 Sep 2000 17:01:38 -0700 (PDT) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 466671C6B; Sat, 30 Sep 2000 20:01:38 -0400 (EDT) Date: Sat, 30 Sep 2000 20:01:38 -0400 From: Bill Fumerola To: Tony Johnson Cc: Gerhard Sittig , freebsd-current@FreeBSD.ORG Subject: Re: interesting problem Message-ID: <20000930200138.X38472@jade.chc-chimes.com> References: <20000929191133.R5065@speedy.gsinet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from gjohnson@gs.verio.net on Sat, Sep 30, 2000 at 06:47:17PM -0500 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Sep 30, 2000 at 06:47:17PM -0500, Tony Johnson wrote: > It appears that I am not the only one who has seen this. Don't call this an > unsubstantiated comment... It's not just me. I didn't quote anything else of your message because this is the obvious problem: No one questioned if you had a problem, no one questioned if you were or weren't the only person to have a problem. However, if you're not willing to get good debugging information in the way that the developers ask for then we have a branch made just for you. -current helps those who help themselves. -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 18:51:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta03.mail.mel.aone.net.au (mta03.mail.au.uu.net [203.2.192.83]) by hub.freebsd.org (Postfix) with ESMTP id DFDEC37B66C; Sat, 30 Sep 2000 18:51:28 -0700 (PDT) Received: from camtech.net.au ([203.55.242.129]) by mta03.mail.mel.aone.net.au with ESMTP id <20001001015122.HLFU5527.mta03.mail.mel.aone.net.au@camtech.net.au>; Sun, 1 Oct 2000 11:51:22 +1000 Message-ID: <39D69940.FC359516@camtech.net.au> Date: Sun, 01 Oct 2000 11:24:08 +0930 From: Matthew Thyer X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johnson Cc: Greg Lehey , Thomas David Rivers , bright@wintelcom.net, freebsd-current@FreeBSD.ORG, kris@FreeBSD.ORG Subject: You should be running -STABLE (Was: Re: interesting problem) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony Johnson wrote: > > Since I am complaining then I need to figure out what U have done to make > 5.0-CURRENT crash?? Well atleast U admit that U do not know and U do not > care. So anyone who is using FreeBSD should also not care?? This is more > screwed up then I thought and people @FreeBSD have made this much harder > then necessary. > Learn the lesson now and save us all from reading your messages in the future. First: If you run FreeBSD-CURRENT, you must take the time to read at least 2 mailing lists being freebsd-current and cvs-all. I'd recommend archiving them as well and definitely have your own source repo. Second: Dont try to antagonise the list. Do you think that everyone is actually aiming to produce a broken by design system ? Third: Investigate you own problem. If you can fix it you have provided a service to others who have the same hardware. You may have to spend time doing a search of your email to identify the likely commit that caused your problem... keep release CD's around for quick testing of boot floppies. Keep a source repo so you can checkout kernel floppies from around the exact change to the GENERIC kernel that broke your system. There should never be time deadlines on you doing this because YOU SHOULD NOT USE -CURRENT FOR A PRODUCTION SYSTEM. It really doesn't take long for new technologies like softupdates, ACPI, ATA-100 to get into the -STABLE stream and then into a release. FreeBSD is a volunteer project with a development model that lets anyone 'listen in' on whats happening at the head of the development tree. If you are prepared to use the head of the tree, you do need to fix your own problems or at least provide the list with an exhaustive list of your configuration and the behaviour you see under everything you've tried (removing hardware, changing cards, flashing BIOS, hacking CODE! yes you can do this too!). If you dont have time to do this, run -STABLE or the last release. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 20:19:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id 55DCD37B66C; Sat, 30 Sep 2000 20:19:17 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.1/8.11.1) id e913JGr67675; Sat, 30 Sep 2000 20:19:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14806.44340.887777.120946@horsey.gshapiro.net> Date: Sat, 30 Sep 2000 20:19:16 -0700 (PDT) From: Gregory Neil Shapiro To: freebsd-current@freebsd.org Cc: cvs-committers@freebsd.org Subject: sendmail related changes X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There are some sendmail related changes I would like to make in the next few days. Some may be controversial so I am sending out this mail first. I would appreciate feedback on any of these items. If I don't hear any major objections, I'll go ahead with the changes. 1. Use sendmail's version of vacation sendmail's version of vacation is completely backwards compatible with the existing version. It also contains new features and bug fixes that are not in the current FreeBSD version. This will take care of PR bin/15227. 2. Copy cf config building tree into /usr/share/sendmail/cf I've been getting many requests to provide the cf tree in the installed system so users can configure sendmail without installing the FreeBSD sources. I can't see any reason not to do this. It will also cut down on support issues for sendmail.org. This will take care of PR bin/19790. It can also be used to close PR bin/13759 and bin/19897. 3. mail.local no longer installed setuid root Since 8.10, the open source distribution of sendmail no longer installs mail.local as a setuid binary. To accomplish this, users needed to configure sendmail to call mail.local as root. This is done by a one line configuration tweak. This tweak isn't necessary if the config already uses FEATURE(local_lmtp) as is recommended (freebsd.mc already does this). We (sendmail.org) decided that one less setuid binary on the filesystem was worth the possible support burden for upgrading users. As it turns out, nobody reported any problems. I think we should do the same for FreeBSD's installation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 21: 3: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CE82837B502; Sat, 30 Sep 2000 21:02:57 -0700 (PDT) Received: from localhost (8aysyv@localhost [127.0.0.1] (may be forged)) by green.dyndns.org (8.11.0/8.11.0) with ESMTP id e9142p546013; Sun, 1 Oct 2000 00:02:54 -0400 (EDT) (envelope-from green@FreeBSD.org) Message-Id: <200010010402.e9142p546013@green.dyndns.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Gregory Neil Shapiro Cc: freebsd-current@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: sendmail related changes In-Reply-To: Message from Gregory Neil Shapiro of "Sat, 30 Sep 2000 20:19:16 PDT." <14806.44340.887777.120946@horsey.gshapiro.net> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Oct 2000 00:02:50 -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gregory Neil Shapiro wrote: > There are some sendmail related changes I would like to make in the next > few days. Some may be controversial so I am sending out this mail first. > I would appreciate feedback on any of these items. If I don't hear any > major objections, I'll go ahead with the changes. > [....] Without reservation, I'd say each one of these is a great idea! Just registering my support, especially for installing the cf tree. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 21:23:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailout1.hananet.net (mailout1.hananet.net [210.220.163.34]) by hub.freebsd.org (Postfix) with ESMTP id E415237B503 for ; Sat, 30 Sep 2000 21:23:37 -0700 (PDT) Received: from gnomaniac.myhome ([211.108.30.117]) by mailout1.hananet.net (Netscape Messaging Server 4.15) with ESMTP id G1QHJ203.G2V for ; Sun, 1 Oct 2000 13:23:26 +0900 Received: (from cjh@localhost) by gnomaniac.myhome (8.11.0/8.11.0) id e914MQE73371; Sun, 1 Oct 2000 13:22:26 +0900 (KST) (envelope-from cjh@kr.FreeBSD.org) X-Authentication-Warning: gnomaniac.myhome: cjh set sender to cjh@kr.FreeBSD.org using -f To: current@freebsd.org Subject: Today -current broken on build From: CHOI Junho Date: 01 Oct 2000 13:22:06 +0900 Message-ID: <86u2axjimp.fsf@gnomaniac.myhome> Lines: 18 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have cvsup'ed today, build stopped with the following error: ===> usr.sbin/amd/amd ... cc -O -pipe -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd -I. -I/usr/src/usr.sbin/amd/amd -I/usr/src/usr.sbin/amd/amd/../include -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/include -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd -DHAVE_CONFIG_H -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:66: redefinition of `struct callout' *** Error code 1 Stop in /usr/src/usr.sbin/amd/amd. *** Error code 1 -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho KFUG Web Data Bank FreeBSD, GNU/Linux Developer http://people.FreeBSD.org/~cjh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 21:46:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id CC60337B502; Sat, 30 Sep 2000 21:46:23 -0700 (PDT) Received: (from uucp@localhost) by rina.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W-rina.r-0.1-11.01.2000) with UUCP id NAA72422; Sun, 1 Oct 2000 13:46:21 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W) with ESMTP/IPv4 id NAA27829; Sun, 1 Oct 2000 13:41:28 +0900 (JST) Date: Sun, 01 Oct 2000 13:41:27 +0900 Message-ID: <14806.49271.166621.26482Z@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> From: Seigo Tanimura To: mwm@mired.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, ports@FreeBSD.ORG, current@FreeBSD.ORG Subject: (Semi-)automatic update of installed ports (was: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior) In-Reply-To: In your message of "Sat, 30 Sep 2000 13:35:48 -0500 (CDT)" <14806.12932.647387.503859@guru.mired.org> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20000924100812.A23848@spawn.nectar.com> <200009281350.WAA23538@bunko> <20000928115555.D42464@spawn.nectar.com> <14805.63360.137164.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <14806.12932.647387.503859@guru.mired.org> User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) Organization: Carrots MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cc'ed to -ports] On Sat, 30 Sep 2000 13:35:48 -0500 (CDT), Mike Meyer said: Mike> Seigo Tanimura writes: >> Completely automatic update of installed ports is acutally difficult >> because we cannot get to know the language or required toolkit from >> the name of a binary. (eg emulator/wine and japanese/wine, timidity++-xaw >> and timidity++-tcltk) We can still detect and enumerate the ports that >> possibly installed old binaries, and decide which of the ports listed >> up to update. Mike> you. However, I believe you were talking about binaries that may have Mike> been built from a current port against an out-of-date system. Mike> Frankly, I'm not really interested in *detecting* such things. A tool Mike> that would 1) save tarballs of *all* installed ports; 2) uninstall Mike> them all; then 3) rebuild and install them all, with a report about Mike> failures would make me happy. How do you rebuild a port automatically if you want to hack the configure parameter or make variables of the port? -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Sep 30 21:52:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-27-149-77.mmcable.com [24.27.149.77]) by hub.freebsd.org (Postfix) with SMTP id 76BCD37B503 for ; Sat, 30 Sep 2000 21:52:34 -0700 (PDT) Received: (qmail 18836 invoked by uid 100); 1 Oct 2000 04:52:28 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14806.49932.529722.3304@guru.mired.org> Date: Sat, 30 Sep 2000 23:52:28 -0500 (CDT) To: Seigo Tanimura Cc: ports@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: (Semi-)automatic update of installed ports (was: Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior) In-Reply-To: <14806.49271.166621.26482Z@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> References: <20000906151431.A26152@hamlet.nectar.com> <14798.4853.288090.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20000924100812.A23848@spawn.nectar.com> <200009281350.WAA23538@bunko> <20000928115555.D42464@spawn.nectar.com> <14805.63360.137164.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <14806.12932.647387.503859@guru.mired.org> <14806.49271.166621.26482Z@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Seigo Tanimura writes: > On Sat, 30 Sep 2000 13:35:48 -0500 (CDT), Mike Meyer said: > Mike> Seigo Tanimura writes: > >> Completely automatic update of installed ports is acutally difficult > >> because we cannot get to know the language or required toolkit from > >> the name of a binary. (eg emulator/wine and japanese/wine, timidity++-xaw > >> and timidity++-tcltk) We can still detect and enumerate the ports that > >> possibly installed old binaries, and decide which of the ports listed > >> up to update. > Mike> Frankly, I'm not really interested in *detecting* such things. A tool > Mike> that would 1) save tarballs of *all* installed ports; 2) uninstall > Mike> them all; then 3) rebuild and install them all, with a report about > Mike> failures would make me happy. > How do you rebuild a port automatically if you want to hack the > configure parameter or make variables of the port? Since that information isn't currently stored, you have to do it by hand :-(. Of course, you also have to *guess* what port corresponds to an installed package, as the information about which ports collection a package came from is lost as well. It's not clear that the port names are globally uniq, either. If it were easy, I'd've done it myself :-). ; Sat, 30 Sep 2000 22:20:15 -0700 (PDT) Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp (Exim 3.12 #7) id 13fbXr-0002R0-00; Sun, 01 Oct 2000 05:20:15 +0000 Received: from [204.1.90.43] (helo=power) by dfw-mmp2.email.verio.net with smtp (Exim 3.15 #4) id 13fbXq-0004Nk-00; Sun, 01 Oct 2000 05:20:14 +0000 From: "Tony Johnson" To: "CHOI Junho" , Subject: RE: Today -current broken on build Date: Sun, 1 Oct 2000 00:20:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <86u2axjimp.fsf@gnomaniac.myhome> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Run 4.0 or piss off... -----Original Message----- From: owner-freebsd-current@FreeBSD.ORG [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of CHOI Junho Sent: Saturday, September 30, 2000 11:22 PM To: current@freebsd.org Subject: Today -current broken on build I have cvsup'ed today, build stopped with the following error: ===> usr.sbin/amd/amd ... cc -O -pipe -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd -I. -I/usr/ src/usr.sbin/amd/amd -I/usr/src/usr.sbin/amd/amd/../include -I/usr/src/usr.s bin/amd/amd/../../../contrib/amd/include -I/usr/src/usr.sbin/amd/amd/../../. ./contrib/amd -DHAVE_CONFIG_H -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:66: redefinition of `struct callout' *** Error code 1 Stop in /usr/src/usr.sbin/amd/amd. *** Error code 1 -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho KFUG Web Data Bank FreeBSD, GNU/Linux Developer http://people.FreeBSD.org/~cjh 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 Sep 30 22:33:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id BB61C37B66C for ; Sat, 30 Sep 2000 22:33:10 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e915YTh01221; Sat, 30 Sep 2000 22:34:29 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200010010534.e915YTh01221@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Tony Johnson" Cc: "CHOI Junho" , current@freebsd.org Subject: Re: Today -current broken on build In-reply-to: Your message of "Sun, 01 Oct 2000 00:20:04 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Sep 2000 22:34:29 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Run 4.0 or piss off... Actually, no. This message contains useful diagnostic information, and can be used to resolve the problem. > -----Original Message----- > From: owner-freebsd-current@FreeBSD.ORG > [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of CHOI Junho > Sent: Saturday, September 30, 2000 11:22 PM > To: current@freebsd.org > Subject: Today -current broken on build > > > > I have cvsup'ed today, build stopped with the following error: > > ===> usr.sbin/amd/amd > ... > cc -O -pipe -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd -I. -I/usr/ > src/usr.sbin/amd/amd -I/usr/src/usr.sbin/amd/amd/../include -I/usr/src/usr.s > bin/amd/amd/../../../contrib/amd/include -I/usr/src/usr.sbin/amd/amd/../../. > ./contrib/amd -DHAVE_CONFIG_H -I/usr/obj/usr/src/i386/usr/include -c > /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c > /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:66: redefinition > of `struct callout' > *** Error code 1 > > Stop in /usr/src/usr.sbin/amd/amd. > *** Error code 1 > > > -- > +++ Any opinions in this posting are my own and not those of my employers > +++ > CHOI Junho > > KFUG Web Data Bank > > FreeBSD, GNU/Linux Developer > http://people.FreeBSD.org/~cjh > > > 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 > -- ... 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