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 <freebsd-current@FreeBSD.ORG>; Sun, 24 Sep 2000 00:25:46 -0700 (PDT)
Received: by maulwurf.franken.de
via rmail with stdio
id <m13d6AS-001b6GC@maulwurf.franken.de>
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 <tanis@gaspode.franken.de>
To: "Kenneth D. Merry" <ken@kdm.org>
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 <kris@FreeBSD.org>
To: Adrian Chadd <adrian@freebsd.org>
Cc: Boris Popov <bp@butya.kz>, freebsd-fs@freebsd.org,
freebsd-current@freebsd.org
Subject: Re: Fsck wrappers, revisited
In-Reply-To: <20001223114150.A38052@roaming.cacheboy.net>
Message-ID: <Pine.BSF.4.21.0009240137090.94665-100000@freefall.freebsd.org>
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 <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sun 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 <adrian@FreeBSD.org>
To: Kris Kennaway <kris@FreeBSD.org>
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> <Pine.BSF.4.21.0009240137090.94665-100000@freefall.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <Pine.BSF.4.21.0009240137090.94665-100000@freefall.freebsd.org>; 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
<adrian@freebsd.org> 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 <current@freebsd.org>; 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 <Gerhard.Sittig@gmx.net>
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 <current@freebsd.org>; 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 <tanimura@r.dl.itc.u-tokyo.ac.jp>
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 <tanimura@r.dl.itc.u-tokyo.ac.jp>
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 <pwd.h>
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@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 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 <current@freebsd.org>; 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" <n@nectar.com>
To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
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 <current@freebsd.org>; 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 <morganw@chemicals.tacorp.com>
To: current@freebsd.org
Subject: sound breakage
Message-ID: <Pine.BSF.4.21.0009241316210.13415-100000@volatile.chemicals.tacorp.com>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; Sun, 24 Sep 2000 20:24:44 +0200 (CEST)
Date: Sun, 24 Sep 2000 20:24:44 +0200 (CEST)
From: Blaz Zupan <blaz@amis.net>
X-Sender: blaz@titanic.medinet.si
To: freebsd-current@freebsd.org
Subject: .indent.pro for KNF?
Message-ID: <Pine.BSF.4.21.0009242019310.48724-100000@titanic.medinet.si>
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 <imp@village.org>
Cc: The Hermit Hacker <scrappy@hub.org>,
Bruce Evans <bde@zeta.org.au>, freebsd-current@FreeBSD.ORG,
freebsd-smp@FreeBSD.ORG
Subject: Re: 'interrupt-level buffer overflows' for sio device?
References: <Pine.BSF.4.21.0009080008090.527-100000@thelab.hub.org> <200009080314.VAA50701@harmony.village.org>
From: Dag-Erling Smorgrav <des@ofug.org>
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: <xzp7l817ij1.fsf@flood.ping.uio.no>
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 <imp@village.org> writes:
> In message <Pine.BSF.4.21.0009080008090.527-100000@thelab.hub.org> 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 <bright@wintelcom.net>
To: Dag-Erling Smorgrav <des@ofug.org>
Cc: Warner Losh <imp@village.org>,
The Hermit Hacker <scrappy@hub.org>, Bruce Evans <bde@zeta.org.au>,
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: <Pine.BSF.4.21.0009080008090.527-100000@thelab.hub.org> <200009080314.VAA50701@harmony.village.org> <xzp7l817ij1.fsf@flood.ping.uio.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <xzp7l817ij1.fsf@flood.ping.uio.no>; 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 <des@ofug.org> [000924 11:27] wrote:
> Warner Losh <imp@village.org> writes:
> > In message <Pine.BSF.4.21.0009080008090.527-100000@thelab.hub.org> 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 <bright@wintelcom.net>
Cc: Warner Losh <imp@village.org>,
The Hermit Hacker <scrappy@hub.org>, Bruce Evans <bde@zeta.org.au>,
freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG
Subject: Re: 'interrupt-level buffer overflows' for sio device?
References: <Pine.BSF.4.21.0009080008090.527-100000@thelab.hub.org> <200009080314.VAA50701@harmony.village.org> <xzp7l817ij1.fsf@flood.ping.uio.no> <20000924113008.N9141@fw.wintelcom.net>
From: Dag-Erling Smorgrav <des@ofug.org>
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: <xzpn1gxd48d.fsf@flood.ping.uio.no>
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 <bright@wintelcom.net> 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 <freebsd-current@freebsd.org>; 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! <attila@hun.org>
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 <freebsd-current@freebsd.org>; 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" <obrien@freebsd.org>
To: Blaz Zupan <blaz@amis.net>
Cc: freebsd-current@freebsd.org
Subject: Re: .indent.pro for KNF?
Message-ID: <20000924171048.A18141@dragon.nuxi.com>
Reply-To: obrien@freebsd.org
References: <Pine.BSF.4.21.0009242019310.48724-100000@titanic.medinet.si>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.BSF.4.21.0009242019310.48724-100000@titanic.medinet.si>; 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" <n@nectar.com>,
Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>,
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" <n@nectar.com>
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 <brian@Awfulhak.org>
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 <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org>
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 <current@FreeBSD.ORG>; 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 <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200009250033.UAA42928@khavrinen.lcs.mit.edu>
To: "Andrey A. Chernov" <ache@nagual.pp.ru>
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
<<On Sun, 24 Sep 2000 08:34:40 +0400, "Andrey A. Chernov" <ache@nagual.pp.ru> 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 <freebsd-current@FreeBSD.ORG>; 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 <blaz@amis.net>
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."
<Pine.BSF.4.21.0009242019310.48724-100000@titanic.medinet.si>
References: <Pine.BSF.4.21.0009242019310.48724-100000@titanic.medinet.si>
Date: Sun, 24 Sep 2000 19:07:33 -0600
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In message <Pine.BSF.4.21.0009242019310.48724-100000@titanic.medinet.si> 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <leifn@neland.dk>
To: freebsd-current@freebsd.org
Subject: Breakage in make world: pam_ssh
Message-ID: <Pine.BSF.4.21.0009250345120.5234-100000@arnold.neland.dk>
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 <kris@FreeBSD.org>
To: Leif Neland <leifn@neland.dk>
Cc: freebsd-current@freebsd.org
Subject: Re: Breakage in make world: pam_ssh
In-Reply-To: <Pine.BSF.4.21.0009250345120.5234-100000@arnold.neland.dk>
Message-ID: <Pine.BSF.4.21.0009241917130.99214-100000@freefall.freebsd.org>
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 <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sun 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 <leifn@neland.dk>
To: Kris Kennaway <kris@FreeBSD.ORG>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Breakage in make world: pam_ssh
In-Reply-To: <Pine.BSF.4.21.0009241917130.99214-100000@freefall.freebsd.org>
Message-ID: <Pine.BSF.4.21.0009250700380.42925-100000@arnold.neland.dk>
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 <freebsd-current@FreeBSD.ORG>; 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" <winter@jurai.net>
To: attila! <attila@hun.org>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: 'device random' required in conf file?
In-Reply-To: <200009241927.e8OJRul21281@hun.org>
Message-ID: <Pine.BSF.4.21.0009250140370.23690-100000@sasami.jurai.net>
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 <freebsd-current@FreeBSD.ORG>; 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 <jruigrok@via-net-works.nl>
To: Blaz Zupan <blaz@amis.net>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: .indent.pro for KNF?
Message-ID: <20000925080519.B60278@lucifer.bart.nl>
References: <Pine.BSF.4.21.0009242019310.48724-100000@titanic.medinet.si>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0009242019310.48724-100000@titanic.medinet.si>; 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
<jruigrok@via-net-works.nl> 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <Parallel I/O> on ppbus0
unknown: <PNP0303> can't assign resources
unknown: <PNP0f13> can't assign resources
unknown: <PNP0501> can't assign resources
unknown: <PNP0700> can't assign resources
unknown: <PNP0401> can't assign resources
unknown: <PNP0501> 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 <freebsd-current@freebsd.org>; 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" <winter@jurai.net>
Cc: attila! <attila@hun.org>, freebsd-current@FreeBSD.ORG
Subject: Re: 'device random' required in conf file?
References: <Pine.BSF.4.21.0009250140370.23690-100000@sasami.jurai.net>
In-Reply-To: <Pine.BSF.4.21.0009250140370.23690-100000@sasami.jurai.net> ; from "Matthew N. Dodd" <winter@jurai.net> "Mon, 25 Sep 2000 01:41:30 -0400."
Date: Mon, 25 Sep 2000 08:57:15 +0200
From: Mark Murray <mark@grondar.za>
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 <freebsd-current@FreeBSD.ORG>; 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 <mark@grondar.za>
Cc: "Matthew N. Dodd" <winter@jurai.net>, attila! <attila@hun.org>,
freebsd-current@FreeBSD.ORG
Subject: Re: 'device random' required in conf file?
References: <Pine.BSF.4.21.0009250140370.23690-100000@sasami.jurai.net> <200009250657.e8P6vFn13720@grimreaper.grondar.za>
From: Dag-Erling Smorgrav <des@ofug.org>
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: <xzp8zsg284w.fsf@flood.ping.uio.no>
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 <mark@grondar.za> 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 <freebsd-current@FreeBSD.ORG>; 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: <xzp8zsg284w.fsf@flood.ping.uio.no> 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 <mark@grondar.za> 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 <freebsd-current@freebsd.org>; 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 <tacho@orbitel.bg>
To: Kenneth Wayne Culver <culverk@wam.umd.edu>
Cc: freebsd-current@freebsd.org
Subject: Re: -CURRENT crashes under heavy disk activity
Message-ID: <20000925141811.A56557@thing.orbitel.bg>
References: <Pine.GSO.4.21.0009221533250.26685-100000@rac3.wam.umd.edu>
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: <Pine.GSO.4.21.0009221533250.26685-100000@rac3.wam.umd.edu>; 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 <leifn@neland.dk>
To: Kris Kennaway <kris@FreeBSD.ORG>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Breakage in make world: pam_ssh
In-Reply-To: <Pine.BSF.4.21.0009241917130.99214-100000@freefall.freebsd.org>
Message-ID: <Pine.BSF.4.21.0009251412180.27531-100000@arnold.neland.dk>
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 <freebsd-current@freebsd.org>; 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 <culverk@wam.umd.edu>
To: Stanislav Grozev <tacho@orbitel.bg>
Cc: freebsd-current@freebsd.org
Subject: Re: -CURRENT crashes under heavy disk activity
In-Reply-To: <20000925141811.A56557@thing.orbitel.bg>
Message-ID: <Pine.GSO.4.21.0009251048180.13192-100000@rac4.wam.umd.edu>
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 <freebsd-current@freebsd.org>; 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 <tacho@orbitel.bg>
To: Kenneth Wayne Culver <culverk@wam.umd.edu>
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> <Pine.GSO.4.21.0009251048180.13192-100000@rac4.wam.umd.edu>
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: <Pine.GSO.4.21.0009251048180.13192-100000@rac4.wam.umd.edu>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; Mon, 25 Sep 2000 17:57:45 +0200 (CEST)
Date: Mon, 25 Sep 2000 17:57:44 +0200 (CEST)
From: Falko Dressler <fd@bsd.rrze.uni-erlangen.de>
To: freebsd-current@freebsd.org
Subject: bug in ccard.c (pccardd code)
Message-ID: <Pine.BSF.4.10.10009251754070.96250-100000@bsd.rrze.uni-erlangen.de>
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 <current@freebsd.org>; 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 <jdp@polstra.com>
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: <Pine.BSF.4.21.0009251412180.27531-100000@arnold.neland.dk>
References: <Pine.BSF.4.21.0009251412180.27531-100000@arnold.neland.dk>
Organization: Polstra & Co., Seattle, WA
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In article <Pine.BSF.4.21.0009251412180.27531-100000@arnold.neland.dk>,
Leif Neland <leifn@neland.dk> 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 <kris@FreeBSD.org>
To: Leif Neland <leifn@neland.dk>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Breakage in make world: pam_ssh
In-Reply-To: <Pine.BSF.4.21.0009251412180.27531-100000@arnold.neland.dk>
Message-ID: <Pine.BSF.4.21.0009250940230.82505-100000@freefall.freebsd.org>
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 <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current 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 <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
To: Adrian Chadd <adrian@freebsd.org>
Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org
Subject: Re: Fsck wrappers, revisited
In-Reply-To: <20000923114434.A4419@roaming.cacheboy.net>
Message-ID: <Pine.BSF.4.21.0009260346491.12315-100000@besplex.bde.org>
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 <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
To: Adrian Chadd <adrian@FreeBSD.ORG>
Cc: Kris Kennaway <kris@FreeBSD.ORG>, freebsd-fs@FreeBSD.ORG,
freebsd-current@FreeBSD.ORG
Subject: Re: Fsck wrappers, revisited
In-Reply-To: <20000924105645.A7573@roaming.cacheboy.net>
Message-ID: <Pine.BSF.4.21.0009260352030.12315-100000@besplex.bde.org>
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 <freebsd-current@FreeBSD.ORG>; 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 <freebsd-current@FreeBSD.ORG>; 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 <imp@village.org>
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: <Parallel I/O> on ppbus0
: unknown: <PNP0303> can't assign resources
: unknown: <PNP0f13> can't assign resources
: unknown: <PNP0501> can't assign resources
: unknown: <PNP0700> can't assign resources
: unknown: <PNP0401> can't assign resources
: unknown: <PNP0501> 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 <freebsd-current@FreeBSD.ORG>; 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 <fd@bsd.rrze.uni-erlangen.de>
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."
<Pine.BSF.4.10.10009251754070.96250-100000@bsd.rrze.uni-erlangen.de>
References: <Pine.BSF.4.10.10009251754070.96250-100000@bsd.rrze.uni-erlangen.de>
Date: Mon, 25 Sep 2000 11:37:50 -0600
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In message <Pine.BSF.4.10.10009251754070.96250-100000@bsd.rrze.uni-erlangen.de> 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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <DougB@gorean.org>
X-Sender: doug@dt051n37.san.rr.com
To: current@freebsd.org
Subject: linuxulator files with invalid ownership
Message-ID: <Pine.BSF.4.21.0009251158150.6744-100000@dt051n37.san.rr.com>
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 <current@freebsd.org>; 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 <current@FreeBSD.ORG>; Mon, 25 Sep 2000 21:12:26 +0200
Date: Mon, 25 Sep 2000 21:12:26 +0200
From: Szilveszter Adam <sziszi@petra.hos.u-szeged.hu>
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 <freebsd-current@FreeBSD.ORG>; 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 <sos@freebsd.dk>
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 <current@freebsd.org>; 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" <obrien@freebsd.org>
To: Mike Meyer <mwm@mired.org>
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 <freebsd-current@freebsd.org>; 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: <k?joch@yahoo.com>
Message-ID: <00ee01c027af$6f68e7c0$4800a8c0@wsjk02.kmjeuro.com>
From: "Karl M. Joch" <k_joch@yahoo.com>
To: <freebsd-current@freebsd.org>
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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.org>; 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: <s9d08880.054@mbakercorp.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Tue, 26 Sep 2000 11:27:26 -0400
From: "Joseph Wright" <jwright@mbakercorp.com>
To: <freebsd-current@FreeBSD.org>
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 <freebsd-current@FreeBSD.ORG>; 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 <tpnelson@echidna.stu.cowan.edu.au>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Weisgerber <naddy@mips.inka.de>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: -Current + X 4.0.1 = mouse problems
References: <Pine.BSF.4.21.0009221611400.62775-100000@dt051n37.san.rr.com> <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 <DougB@gorean.org> 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 <freebsd-current@FreeBSD.ORG>; 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 <gshapiro@gshapiro.net>
To: "Joseph Wright" <jwright@mbakercorp.com>
Cc: <freebsd-current@FreeBSD.ORG>
Subject: Re: Majordomo Problem
In-Reply-To: <s9d08880.054@mbakercorp.com>
References: <s9d08880.054@mbakercorp.com>
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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.org>; 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: <s9d0d0e3.095@mbakercorp.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Tue, 26 Sep 2000 16:36:18 -0400
From: "Joseph Wright" <jwright@mbakercorp.com>
To: <freebsd-current@FreeBSD.org>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <archie@whistle.com>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <jwd@unx.sas.com>
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 <freebsd-current@freebsd.org>; 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" <obrien@freebsd.org>
To: John DeBoskey <jwd@unx.sas.com>
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 <current@freebsd.org>; 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: <matusita@jp.FreeBSD.org>
<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 <matusita@jp.FreeBSD.org>
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,
<URL:http://www.freebsd.org/cgi/query-pr.cgi?pr=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 <matusita@jp.FreeBSD.org>
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 <current@freebsd.org>; 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 <jazepeda@pacbell.net>
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 <phk@critter.freebsd.dk>
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 <phk@critter.freebsd.dk>
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 <phk@critter.freebsd.dk>
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 <phk@critter.freebsd.dk>
>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 <phk@critter.freebsd.dk>
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 <phk@critter.freebsd.dk>
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 <phk@critter.freebsd.dk>
>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 <freebsd-current@FreeBSD.ORG>; 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 <jruigrok@via-net-works.nl>
To: Archie Cobbs <archie@whistle.com>
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
<jruigrok@via-net-works.nl> 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 <freebsd-current@freebsd.org>; 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: <k?joch@yahoo.com>
Message-ID: <016901c0288a$c7951cd0$4800a8c0@wsjk02.kmjeuro.com>
From: "Karl M. Joch" <k_joch@yahoo.com>
To: <freebsd-current@FreeBSD.ORG>, <freebsd-mobile@FreeBSD.ORG>
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 <culverk@wam.umd.edu>
To: "Karl M. Joch" <k_joch@yahoo.com>
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: <Pine.GSO.4.21.0009271014430.3225-100000@rac2.wam.umd.edu>
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 <freebsd-current@freebsd.org>; 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: <k?joch@yahoo.com>
Message-ID: <01bd01c0289a$e17771b0$4800a8c0@wsjk02.kmjeuro.com>
From: "Karl M. Joch" <k_joch@yahoo.com>
To: <freebsd-current@freebsd.org>, <freebsd-mobile@freebsd.org>
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 <culverk@wam.umd.edu>
An: Karl M. Joch <k_joch@yahoo.com>
Cc: freebsd-current@FreeBSD.ORG <freebsd-current@FreeBSD.ORG>; freebsd-mobile@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 <freebsd-current@FreeBSD.ORG>; 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 <freebsd-current@FreeBSD.ORG>; 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" <tomdean@ix.netcom.com>
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: <unknown card> (vendor=0x11c1, dev=0x0441) at 7.0 irq 3
return ("LUCENT K56Flex DSVD LTMODEM (winmodem, unsupported)");
pci0: <unknown card> (vendor=0x1179, dev=0x0d01) at 9.0 irq 11
return ("Toshiba Fast Infra Red controller");
What might this be? vendor?
pci0: <unknown card> (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 <freebsd-current@FreeBSD.ORG>; 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 <brooks@one-eyed-alien.net>
To: "Thomas D. Dean" <tomdean@ix.netcom.com>
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: <unknown card> (vendor=0x11c1, dev=0x0441) at 7.0 irq 3
> return ("LUCENT K56Flex DSVD LTMODEM (winmodem, unsupported)");
>
> pci0: <unknown card> (vendor=0x1179, dev=0x0d01) at 9.0 irq 11
> return ("Toshiba Fast Infra Red controller");
>
> What might this be? vendor?
> pci0: <unknown card> (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 <freebsd-current@FreeBSD.ORG>; 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" <winter@jurai.net>
To: "Thomas D. Dean" <tomdean@ix.netcom.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Unknown PCI chipsets
In-Reply-To: <200009271918.e8RJITv03988@ix.netcom.com>
Message-ID: <Pine.BSF.4.21.0009271835450.23690-100000@sasami.jurai.net>
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: <unknown card> (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 <freebsd-current@freebsd.org>; 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" <gjohnson@gs.verio.net>
To: <freebsd-current@FreeBSD.ORG>
Subject: interesting problem
Date: Wed, 27 Sep 2000 17:55:47 -0500
Message-ID: <FOENIGAJAKGPLNGHHADIAEJFDAAA.gjohnson@gs.verio.net>
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 <kris@FreeBSD.org>
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: interesting problem
In-Reply-To: <FOENIGAJAKGPLNGHHADIAEJFDAAA.gjohnson@gs.verio.net>
Message-ID: <Pine.BSF.4.21.0009271647220.87719-100000@freefall.freebsd.org>
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 <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current 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" <gjohnson@gs.verio.net>
To: "Kris Kennaway" <kris@FreeBSD.org>
Cc: <freebsd-current@FreeBSD.ORG>
Subject: RE: interesting problem
Date: Wed, 27 Sep 2000 19:07:17 -0500
Message-ID: <FOENIGAJAKGPLNGHHADIIEJHDAAA.gjohnson@gs.verio.net>
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: <Pine.BSF.4.21.0009271647220.87719-100000@freefall.freebsd.org>
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 <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current 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 <kris@FreeBSD.org>
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: freebsd-current@FreeBSD.ORG
Subject: RE: interesting problem
In-Reply-To: <FOENIGAJAKGPLNGHHADIIEJHDAAA.gjohnson@gs.verio.net>
Message-ID: <Pine.BSF.4.21.0009271717040.14622-100000@freefall.freebsd.org>
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 <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current 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 <bright@wintelcom.net>
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: Kris Kennaway <kris@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG
Subject: Re: interesting problem
Message-ID: <20000927171829.J9141@fw.wintelcom.net>
References: <Pine.BSF.4.21.0009271647220.87719-100000@freefall.freebsd.org> <FOENIGAJAKGPLNGHHADIIEJHDAAA.gjohnson@gs.verio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <FOENIGAJAKGPLNGHHADIIEJHDAAA.gjohnson@gs.verio.net>; 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 <gjohnson@gs.verio.net> [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 <freebsd-current@FreeBSD.ORG>; 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 <grog@lemis.com>
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: Kris Kennaway <kris@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG
Subject: Re: interesting problem
Message-ID: <20000928113444.F11123@sydney.worldwide.lemis.com>
References: <Pine.BSF.4.21.0009271647220.87719-100000@freefall.freebsd.org> <FOENIGAJAKGPLNGHHADIIEJHDAAA.gjohnson@gs.verio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <FOENIGAJAKGPLNGHHADIIEJHDAAA.gjohnson@gs.verio.net>; 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 <haro@tk.kubota.co.jp>
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" <gjohnson@gs.verio.net>
To: "Greg Lehey" <grog@lemis.com>
Cc: "Kris Kennaway" <kris@FreeBSD.ORG>, <freebsd-current@FreeBSD.ORG>
Subject: RE: interesting problem
Date: Wed, 27 Sep 2000 20:26:13 -0500
Message-ID: <FOENIGAJAKGPLNGHHADIOEJKDAAA.gjohnson@gs.verio.net>
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 <bright@wintelcom.net>
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: Greg Lehey <grog@lemis.com>, Kris Kennaway <kris@FreeBSD.ORG>,
freebsd-current@FreeBSD.ORG
Subject: Re: interesting problem
Message-ID: <20000927183939.B7553@fw.wintelcom.net>
References: <20000928113444.F11123@sydney.worldwide.lemis.com> <FOENIGAJAKGPLNGHHADIOEJKDAAA.gjohnson@gs.verio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <FOENIGAJAKGPLNGHHADIOEJKDAAA.gjohnson@gs.verio.net>; 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 <gjohnson@gs.verio.net> [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 <freebsd-current@FreeBSD.ORG>; 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 <archie@whistle.com>
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 <jruigrok@via-net-works.nl>
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 <current@freebsd.org>; 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 <haro@tk.kubota.co.jp>
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 <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
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
<a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html">
Public Key</a>
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 <freebsd-current@freebsd.org>; 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" <faulkner@asgard.hos.net>
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 <freebsd-current@FreeBSD.ORG>; 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: <mu93dildm85.wl@cx281057-a.irvn1.occa.home.com>
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 <freebsd-current@FreeBSD.ORG>; 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" <faulkner@asgard.hos.net>
To: "Peter S. Housel" <housel@acm.org>
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> <mu93dildm85.wl@cx281057-a.irvn1.occa.home.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <mu93dildm85.wl@cx281057-a.irvn1.occa.home.com>; 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 <freebsd-current@FreeBSD.ORG>; 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 <julian@elischer.org>
To: "Boyd R. Faulkner" <faulkner@asgard.hos.net>
Cc: "Peter S. Housel" <housel@acm.org>, freebsd-current@FreeBSD.ORG
Subject: Re: Network bridge on current.
In-Reply-To: <20000928022230.A967@simon.catburg.net>
Message-ID: <Pine.BSF.4.10.10009280032180.17364-100000@InterJet.elischer.org>
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 <current@freebsd.org>; 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 <current@freebsd.org>; Thu, 28 Sep 2000 00:50:10 -0700 (PDT)
Date: Thu, 28 Sep 2000 00:50:10 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: current@freebsd.org
Subject: hwptr went backwards..
Message-ID: <Pine.BSF.4.10.10009280043300.17364-100000@InterJet.elischer.org>
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 <current@freebsd.org>; 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 <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
Cc: Munehiro Matsuda <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 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 <msmith@freebsd.org>
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 <current@freebsd.org>; 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 <iwasaki@jp.FreeBSD.org>
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 <rivers@dignus.com>
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 <bright@wintelcom.net> wrote:
>
> * Tony Johnson <gjohnson@gs.verio.net> [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 <iwasaki@jp.FreeBSD.org>
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 <freebsd-current@FreeBSD.ORG>; 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 <dnelson@emsphone.com>
To: Julian Elischer <julian@elischer.org>
Cc: "Boyd R. Faulkner" <faulkner@asgard.hos.net>,
"Peter S. Housel" <housel@acm.org>, freebsd-current@FreeBSD.ORG
Subject: Re: Network bridge on current.
Message-ID: <20000928093910.A24037@dan.emsphone.com>
References: <20000928022230.A967@simon.catburg.net> <Pine.BSF.4.10.10009280032180.17364-100000@InterJet.elischer.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: Mutt/1.3.9i
In-Reply-To: <Pine.BSF.4.10.10009280032180.17364-100000@InterJet.elischer.org>; 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 <freebsd-current@FreeBSD.ORG>; 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 <billf@chimesnet.com>
To: Julian Elischer <julian@elischer.org>
Cc: "Boyd R. Faulkner" <faulkner@asgard.hos.net>,
"Peter S. Housel" <housel@acm.org>, freebsd-current@FreeBSD.ORG
Subject: Re: Network bridge on current.
Message-ID: <20000928104014.W34501@jade.chc-chimes.com>
References: <20000928022230.A967@simon.catburg.net> <Pine.BSF.4.10.10009280032180.17364-100000@InterJet.elischer.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.10.10009280032180.17364-100000@InterJet.elischer.org>; 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 <current@freebsd.org>; 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 <tanimura@r.dl.itc.u-tokyo.ac.jp>
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" <n@nectar.com> 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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@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 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; Thu, 28 Sep 2000 10:04:25 -0500 (CDT)
(envelope-from alcachofo@demv.net)
Message-ID: <000901c0295d$7f4b1be0$06f238c8@sabrina>
Reply-To: "Alcachofo Demv" <alcachofo@demv.net>
From: "Alcachofo Demv" <alcachofo@demv.net>
To: <freebsd-current@freebsd.org>
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 <current@FreeBSD.ORG>; 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 <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200009281513.LAA82640@khavrinen.lcs.mit.edu>
To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
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
<<On Thu, 28 Sep 2000 22:50:53 +0900, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> 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 <freebsd-current@FreeBSD.ORG>; 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" <faulkner@asgard.hos.net>
To: Bill Fumerola <billf@chimesnet.com>
Cc: Julian Elischer <julian@elischer.org>,
"Boyd R. Faulkner" <faulkner@asgard.hos.net>,
"Peter S. Housel" <housel@acm.org>, freebsd-current@FreeBSD.ORG
Subject: Re: Network bridge on current.
Message-ID: <20000928101749.A1798@simon.catburg.net>
References: <20000928022230.A967@simon.catburg.net> <Pine.BSF.4.10.10009280032180.17364-100000@InterJet.elischer.org> <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 <current@FreeBSD.ORG>; 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 <dnelson@emsphone.com>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, 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:
> <<On Thu, 28 Sep 2000 22:50:53 +0900, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> 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 <current@freebsd.org>; 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" <n@nectar.com>
To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
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 <iwasaki@jp.FreeBSD.org>
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 <msmith@freebsd.org>
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 <current@FreeBSD.ORG>; 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" <n@nectar.com>
To: Dan Nelson <dnelson@emsphone.com>
Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>,
Seigo Tanimura <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
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 <adrian@freebsd.org>
To: Bruce Evans <bde@zeta.org.au>
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> <Pine.BSF.4.21.0009260346491.12315-100000@besplex.bde.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <Pine.BSF.4.21.0009260346491.12315-100000@besplex.bde.org>; 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
<adrian@freebsd.org> 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 <current@FreeBSD.ORG>; 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 <fjoe@iclub.nsu.ru>
To: Dan Nelson <dnelson@emsphone.com>
Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>,
Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, 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: <Pine.BSF.4.21.0009290006340.58344-100000@iclub.nsu.ru>
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 <iwasaki@jp.FreeBSD.org>
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 <current@FreeBSD.ORG>; 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" <n@nectar.com>
To: Max Khon <fjoe@iclub.nsu.ru>
Cc: Dan Nelson <dnelson@emsphone.com>,
Garrett Wollman <wollman@khavrinen.lcs.mit.edu>,
Seigo Tanimura <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
Message-ID: <20000928124412.F42464@spawn.nectar.com>
References: <20000928102400.A17446@dan.emsphone.com> <Pine.BSF.4.21.0009290006340.58344-100000@iclub.nsu.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.BSF.4.21.0009290006340.58344-100000@iclub.nsu.ru>; 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 <current@freebsd.org>; 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 <t-ogawa@triaez.kaisei.org>
To: Julian Elischer <julian@elischer.org>
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)"
<Pine.BSF.4.10.10009280043300.17364-100000@InterJet.elischer.org>
References: <Pine.BSF.4.10.10009280043300.17364-100000@InterJet.elischer.org>
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 <julian@elischer.org> wrote:
> pcm0: hwptr went backwards 708 -> 628
I've seen this too on my PC running current as of Sep
20. dmesg says:
pcm0: <ESS Solo-1 (unknown vendor)> 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 <current@freebsd.org>; 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 <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: 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 <msmith@freebsd.org>
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 <sys/rman.h>
#include <sys/acpi.h>
-
#include <dev/acpi/acpi.h> /* for softc */
#include <dev/acpi/aml/aml_amlmem.h>
@@ -63,8 +62,6 @@
#include <dev/acpi/aml/aml_parse.h>
#include <dev/acpi/aml/aml_memman.h>
-#include <machine/acpi_machdep.h> /* 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 <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
+ * Copyright (c) 1999, 2000 Mitsuru IWASAKI <iwasaki@FreeBSD.org>
+ * 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 <sys/param.h>
+#include <sys/systm.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <sys/conf.h>
+#include <sys/sysctl.h>
+
+#include <sys/malloc.h>
+#include <vm/vm.h>
+#include <vm/pmap.h>
+
+#include <sys/eventhandler.h> /* for EVENTHANDLER_REGISTER */
+#include <sys/reboot.h> /* for RB_POWEROFF */
+#include <machine/clock.h> /* for DELAY */
+#include <sys/unistd.h> /* for RFSTOPPED*/
+#include <sys/kthread.h> /* for kthread stuff*/
+#include <sys/ctype.h>
+
+#include <machine/bus.h>
+#include <machine/resource.h>
+#include <sys/rman.h>
+
+#include <sys/acpi.h>
+#include <dev/acpi/acpi.h> /* 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 <sys/malloc.h>
#include <sys/bus.h>
-#include <sys/acpi.h>
+#include <machine/bus.h>
+#include <machine/resource.h>
+#include <sys/rman.h>
+#include <sys/acpi.h>
#include <dev/acpi/acpi.h>
#include <dev/acpi/aml/aml_amlmem.h>
--==_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 <current@freebsd.org>; 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 <current@freebsd.org>; Thu, 28 Sep 2000 20:37:22 +0200 (CEST)
Date: Thu, 28 Sep 2000 20:37:22 +0200 (CEST)
From: Anonymous Coward <barry@fluffy.gets.an.analprobe.dk>
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: <Pine.BSF.4.21.0009282028020.61669-100000@vax.chrillesen.dk>
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 <freebsd-current@FreeBSD.ORG>; 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 <dervish@goku.cl.msu.edu>
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
<dervish@goku.cl.msu.edu>
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 <current@freebsd.org>; 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 <current@freebsd.org>; Thu, 28 Sep 2000 21:11:31 +0200 (CEST)
Date: Thu, 28 Sep 2000 21:11:31 +0200 (CEST)
From: Anonymous Coward <barry@fluffy.gets.an.analprobe.dk>
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: <Pine.BSF.4.21.0009282028020.61669-100000_vax.chrillesen.dk@ns.sol.net>
Message-ID: <Pine.BSF.4.21.0009282107370.61669-100000@vax.chrillesen.dk>
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 <current@freebsd.org>; 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 <iwasaki@jp.FreeBSD.org>
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 <sys/proc.h>
+
+#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 <sys/systm.h>
+#include <machine/acpica_osd.h>
+#include <machine/clock.h>
#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 <vm/vm.h>
#include <vm/pmap.h>
+#include <dev/acpi/acpi.h>
+
#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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.org>; 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 <freebsd-current@FreeBSD.ORG>; 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 <bartequi@inwind.it>
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" <gjohnson@gs.verio.net>
To: "Thomas David Rivers" <rivers@dignus.com>, <bright@wintelcom.net>
Cc: <freebsd-current@FreeBSD.ORG>, <grog@lemis.com>,
<kris@FreeBSD.ORG>
Subject: RE: interesting problem
Date: Thu, 28 Sep 2000 19:54:01 -0500
Message-ID: <FOENIGAJAKGPLNGHHADIEENDDAAA.gjohnson@gs.verio.net>
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 <bright@wintelcom.net> wrote:
>
> * Tony Johnson <gjohnson@gs.verio.net> [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 <freebsd-current@FreeBSD.ORG>; 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 <trish@bsdunix.net>
X-Sender: trish@superconductor.rush.net
To: Julian Elischer <julian@elischer.org>
Cc: "Boyd R. Faulkner" <faulkner@asgard.hos.net>,
"Peter S. Housel" <housel@acm.org>, freebsd-current@FreeBSD.ORG
Subject: Re: Network bridge on current.
In-Reply-To: <Pine.BSF.4.10.10009280032180.17364-100000@InterJet.elischer.org>
Message-ID: <Pine.BSO.4.21.0009282139270.15666-100000@superconductor.rush.net>
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 <freebsd-current@FreeBSD.ORG>; 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 <trish@bsdunix.net>
X-Sender: trish@superconductor.rush.net
To: Julian Elischer <julian@elischer.org>
Cc: "Boyd R. Faulkner" <faulkner@asgard.hos.net>,
"Peter S. Housel" <housel@acm.org>, freebsd-current@FreeBSD.ORG
Subject: Re: Network bridge on current.
In-Reply-To: <Pine.BSO.4.21.0009282139270.15666-100000@superconductor.rush.net>
Message-ID: <Pine.BSO.4.21.0009282143570.15666-100000@superconductor.rush.net>
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 <grog@lemis.com>
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: Thomas David Rivers <rivers@dignus.com>, 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> <FOENIGAJAKGPLNGHHADIEENDDAAA.gjohnson@gs.verio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <FOENIGAJAKGPLNGHHADIEENDDAAA.gjohnson@gs.verio.net>; 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 <bright@wintelcom.net> wrote:
>>>
>>> * Tony Johnson <gjohnson@gs.verio.net> [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 <FreeBSD-current@FreeBSD.ORG>; 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 <grog@lemis.com>
To: FreeBSD current users <FreeBSD-current@FreeBSD.ORG>
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 <morganw@chemicals.tacorp.com>
To: current@freebsd.org
Cc: smp@freebsd.org
Subject: panic in "kernel configuration menu"
Message-ID: <Pine.BSF.4.21.0009282217250.71321-100000@volatile.chemicals.tacorp.com>
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" <gjohnson@gs.verio.net>
To: "Greg Lehey" <grog@lemis.com>
Cc: "Thomas David Rivers" <rivers@dignus.com>,
<bright@wintelcom.net>, <freebsd-current@FreeBSD.ORG>,
<kris@FreeBSD.ORG>
Subject: RE: interesting problem
Date: Thu, 28 Sep 2000 21:45:13 -0500
Message-ID: <FOENIGAJAKGPLNGHHADICENKDAAA.gjohnson@gs.verio.net>
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 <bright@wintelcom.net> wrote:
>>>
>>> * Tony Johnson <gjohnson@gs.verio.net> [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 <current@freebsd.org>; 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 <nnd@mail.nsk.ru>
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 <grog@lemis.com>
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: Thomas David Rivers <rivers@dignus.com>, 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> <FOENIGAJAKGPLNGHHADICENKDAAA.gjohnson@gs.verio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <FOENIGAJAKGPLNGHHADICENKDAAA.gjohnson@gs.verio.net>; 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 <grog@lemis.com>
To: Wesley Morgan <morganw@chemicals.tacorp.com>
Cc: current@FreeBSD.ORG, smp@FreeBSD.ORG
Subject: Re: panic in "kernel configuration menu"
Message-ID: <20000929125132.H4293@wantadilla.lemis.com>
References: <Pine.BSF.4.21.0009282217250.71321-100000@volatile.chemicals.tacorp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.21.0009282217250.71321-100000@volatile.chemicals.tacorp.com>; 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" <gjohnson@gs.verio.net>
Cc: "Greg Lehey" <grog@lemis.com>,
"Thomas David Rivers" <rivers@dignus.com>, bright@wintelcom.net,
freebsd-current@FreeBSD.ORG, kris@FreeBSD.ORG
Subject: Re: interesting problem
In-Reply-To: Message from "Tony Johnson" <gjohnson@gs.verio.net>
of "Thu, 28 Sep 2000 21:45:13 CDT." <FOENIGAJAKGPLNGHHADICENKDAAA.gjohnson@gs.verio.net>
Date: Thu, 28 Sep 2000 21:05:54 -0700
Message-ID: <92431.970200354@winston.osd.bsdi.com>
From: Jordan Hubbard <jkh@winston.osd.bsdi.com>
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 <freebsd-current@FreeBSD.ORG>; 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" <faulkner@asgard.hos.net>
To: Siobhan Patricia Lynch <trish@bsdunix.net>
Cc: Julian Elischer <julian@elischer.org>,
"Boyd R. Faulkner" <faulkner@asgard.hos.net>,
"Peter S. Housel" <housel@acm.org>, freebsd-current@FreeBSD.ORG
Subject: Re: Network bridge on current.
Message-ID: <20000929005326.A442@simon.catburg.net>
References: <Pine.BSF.4.10.10009280032180.17364-100000@InterJet.elischer.org> <Pine.BSO.4.21.0009282139270.15666-100000@superconductor.rush.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSO.4.21.0009282139270.15666-100000@superconductor.rush.net>; 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 <bright@wintelcom.net>
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: Thomas David Rivers <rivers@dignus.com>,
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> <FOENIGAJAKGPLNGHHADIEENDDAAA.gjohnson@gs.verio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <FOENIGAJAKGPLNGHHADIEENDDAAA.gjohnson@gs.verio.net>; 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 <gjohnson@gs.verio.net> [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 <freebsd-current@FreeBSD.ORG>; 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 <bright@wintelcom.net>
To: Thomas David Rivers <rivers@dignus.com>
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 <rivers@dignus.com> [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 <current@freebsd.org>; 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 <matusita@jp.FreeBSD.org>
Cc: current@freebsd.org
Subject: Re: sysinstall: Avoiding version checking of CD-ROM (patch included)
In-Reply-To: Message from Makoto MATSUSHITA <matusita@jp.FreeBSD.org>
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 <jkh@winston.osd.bsdi.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> Speaking about sysinstall, would you please check my PR (bin/21423,
> <URL:http://www.freebsd.org/cgi/query-pr.cgi?pr=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 <current@freebsd.org>; 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: <matusita@jp.FreeBSD.org>
<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 <matusita@jp.FreeBSD.org>
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 <current@freebsd.org>; 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 <haro@tk.kubota.co.jp>
X-Dispatcher: imput version 20000228(IM140)
Lines: 27
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
From: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
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 <current@freebsd.org>; 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 <haro@tk.kubota.co.jp>
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 <msmith@freebsd.org>
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 <sys/acpi.h> and
<sys/dev/acpi/acpi.h> 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 <sys/rman.h>
#include <sys/acpi.h>
-
#include <dev/acpi/acpi.h> /* for softc */
#include <dev/acpi/aml/aml_amlmem.h>
@@ -63,38 +62,14 @@
#include <dev/acpi/aml/aml_parse.h>
#include <dev/acpi/aml/aml_memman.h>
-#include <machine/acpi_machdep.h> /* 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 <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
+ * Copyright (c) 1999, 2000 Mitsuru IWASAKI <iwasaki@FreeBSD.org>
+ * 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 <sys/param.h>
+#include <sys/systm.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <sys/conf.h>
+#include <sys/sysctl.h>
+
+#include <sys/malloc.h>
+#include <vm/vm.h>
+#include <vm/pmap.h>
+
+#include <sys/eventhandler.h> /* for EVENTHANDLER_REGISTER */
+#include <sys/reboot.h> /* for RB_POWEROFF */
+#include <machine/clock.h> /* for DELAY */
+#include <sys/unistd.h> /* for RFSTOPPED*/
+#include <sys/kthread.h> /* for kthread stuff*/
+#include <sys/ctype.h>
+
+#include <machine/bus.h>
+#include <machine/resource.h>
+#include <sys/rman.h>
+
+#include <sys/acpi.h>
+#include <dev/acpi/acpi.h> /* 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 <sys/malloc.h>
#include <sys/bus.h>
-#include <sys/acpi.h>
+#include <machine/bus.h>
+#include <machine/resource.h>
+#include <sys/rman.h>
+#include <sys/acpi.h>
#include <dev/acpi/acpi.h>
#include <dev/acpi/aml/aml_amlmem.h>
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 <iwasaki@FreeBSD.org>
+ * Copyright (c) 2000 Michael Smith <msmith@freebsd.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -28,9 +29,273 @@
*/
#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/systm.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <sys/conf.h>
+#include <sys/sysctl.h>
-#include <machine/acpi_machdep.h>
+#include <sys/malloc.h>
+#include <vm/vm.h>
+#include <vm/pmap.h>
+#include <sys/eventhandler.h> /* for EVENTHANDLER_REGISTER */
+#include <sys/reboot.h> /* for RB_POWEROFF */
+#include <machine/clock.h> /* for DELAY */
+#include <sys/unistd.h> /* for RFSTOPPED*/
+#include <sys/kthread.h> /* for kthread stuff*/
+#include <sys/ctype.h>
+
+#include <machine/bus.h>
+#include <machine/resource.h>
+#include <sys/rman.h>
+
+#include <sys/acpi.h>
+#include <dev/acpi/acpi.h> /* for softc */
+
+#include <dev/acpi/aml/aml_amlmem.h>
+#include <dev/acpi/aml/aml_common.h>
+#include <dev/acpi/aml/aml_env.h>
+#include <dev/acpi/aml/aml_evalobj.h>
+#include <dev/acpi/aml/aml_name.h>
+#include <dev/acpi/aml/aml_parse.h>
+#include <dev/acpi/aml/aml_memman.h>
+#include <sys/param.h> /* XXX trim includes */
+#include <sys/systm.h>
+#include <sys/kernel.h>
+#include <sys/malloc.h>
+#include <sys/bus.h>
+#include <sys/acpi.h>
+#include <vm/vm.h>
+#include <vm/pmap.h>
+#include <machine/md_var.h>
+#include <machine/segments.h>
+#include <machine/stdarg.h>
+#include <machine/vmparam.h>
+#include <machine/pc/bios.h>
+
+#include <machine/bus.h>
+#include <machine/resource.h>
+#include <sys/rman.h>
+
+#include <machine/vm86.h>
+
+
+#include <dev/acpi/acpi.h>
+
#ifdef ACPI_NO_OSDFUNC_INLINE
#include <machine/acpica_osd.h>
#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 <sys/param.h>
@@ -50,10 +49,6 @@
#include <isa/pnpreg.h>
#include <isa/pnpvar.h>
-#if NACPI > 0
-#include <sys/acpi.h>
-#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 <machine/ipl.h>
#include <machine/md_var.h>
#include <machine/mutex.h>
+#include <machine/pc/bios.h>
#include <machine/pcb_ext.h> /* pcb.h included via sys/user.h */
#include <machine/globaldata.h>
#include <machine/globals.h>
@@ -120,10 +120,6 @@
#include <sys/ptrace.h>
#include <machine/sigframe.h>
-#if NACPI > 0
-#include <sys/acpi.h>
-#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 <sys/ioccom.h>
+/* 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 <iwasaki@jp.FreeBSD.org>
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 <machine/acpi.h>, 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 <iwasaki@jp.FreeBSD.org>
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 <sys/acpi.h> and
> <sys/dev/acpi/acpi.h> in terms of functionality.
I'd like to move and rename them as I said in my previous mail,
<sys/acpi.h> -> <sys/dev/acpi/acpi.h>
shared by both kernel and userland programs
<sys/dev/acpi/acpi.h> -> <sys/dev/acpi/acpivar.h>
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" <tshiozak@astec.co.jp>
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 <iwasaki@jp.freebsd.org>
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 <sys/acpi.h> and
> > <sys/dev/acpi/acpi.h> in terms of functionality.
> I'd like to move and rename them as I said in my previous mail,
> <sys/acpi.h> -> <sys/dev/acpi/acpi.h>
> shared by both kernel and userland programs
> <sys/dev/acpi/acpi.h> -> <sys/dev/acpi/acpivar.h>
> 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" <tshiozak@astec.co.jp>
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" <tshiozak@astec.co.jp>
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 <iwasaki@jp.FreeBSD.org>
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,
> > <sys/acpi.h> -> <sys/dev/acpi/acpi.h>
> > shared by both kernel and userland programs
> > <sys/dev/acpi/acpi.h> -> <sys/dev/acpi/acpivar.h>
> > 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 <dev/usb/usb.h>,
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 <iwasaki@jp.FreeBSD.org>
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 <iwasaki@jp.freebsd.org>, 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
<a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html">
Public Key</a>
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 <freebsd-current@freebsd.org>; 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" <kdulzo@caffeine.gerp.org>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <mirko.viviani@rccr.cremona.it> (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 <current@FreeBSD.ORG>; 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 <dnelson@emsphone.com>
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 <iwasaki@jp.FreeBSD.org>
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 <current@freebsd.org>; 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 <jdp@polstra.com>
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>,
<mirko.viviani@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 <current@freebsd.org>; 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 <dmmiller@cvzoom.net>
X-Sender: dmmiller@acs-24-154-25-35.zoominternet.net
To: Alexander Langer <alex@big.endian.de>
Cc: current@freebsd.org
Subject: Re: setting device permissions for DEVFS
In-Reply-To: <20000929180208.A821@cichlids.cichlids.com>
Message-ID: <Pine.BSF.4.21.0009291327080.62512-100000@acs-24-154-25-35.zoominternet.net>
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 <current@freebsd.org>; 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 <matusita@jp.FreeBSD.org>
Cc: current@freebsd.org
Subject: Re: sysinstall: Avoiding version checking of CD-ROM (patch included)
In-Reply-To: Message from Makoto MATSUSHITA <matusita@jp.FreeBSD.org>
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 <jkh@winston.osd.bsdi.com>
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 <current@freebsd.org>; 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 <jdp@polstra.com>
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 <current@FreeBSD.ORG>; 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" <boshea@ricochet.net>
To: mirko.viviani@rccr.cremona.it
Cc: John Polstra <jdp@polstra.com>, 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 <jdp@polstra.com>, 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 <freebsd-current@FreeBSD.ORG>; 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 <Gerhard.Sittig@gmx.net>
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> <FOENIGAJAKGPLNGHHADICENKDAAA.gjohnson@gs.verio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <FOENIGAJAKGPLNGHHADICENKDAAA.gjohnson@gs.verio.net>; 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.
<irony mode on>
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 ...".
<irony mode off>
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 <current@freebsd.org>; 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 <iwasaki@jp.FreeBSD.org>
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 <msmith@freebsd.org>
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,
> > > <sys/acpi.h> -> <sys/dev/acpi/acpi.h>
> > > shared by both kernel and userland programs
> > > <sys/dev/acpi/acpi.h> -> <sys/dev/acpi/acpivar.h>
> > > 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 <dev/usb/usb.h>,
> 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 <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: 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 <msmith@freebsd.org>
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 <current@freebsd.org>; 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 <iwasaki@jp.freebsd.org>, 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 <msmith@freebsd.org>
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 <iwasaki@jp.FreeBSD.org>
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 <current@freebsd.org>; 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 <iwasaki@jp.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: 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 <msmith@freebsd.org>
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 <FreeBSD-current@FreeBSD.ORG>; 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 <Don.Lewis@tsc.tdk.com>
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 <grog@lemis.com>,
FreeBSD current users <FreeBSD-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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" <n@nectar.com>
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" <n@nectar.com>,
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 <nectar@FreeBSD.org> -----
Date: Fri, 29 Sep 2000 05:56:34 -0700 (PDT)
From: Jacques Vidrine <nectar@FreeBSD.org>
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 <danny@cs.huji.ac.il>
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 <freebsd-current@freebsd.org>; 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 <bp@butya.kz>
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: <Pine.BSF.4.10.10009300926560.94703-100000@lion.butya.kz>
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 <current@freebsd.org>; 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 <iwasaki@jp.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: 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 <msmith@freebsd.org>
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 <current@freebsd.org>; 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 <iwasaki@jp.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: 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 <msmith@freebsd.org>
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 <phk@critter.freebsd.dk>
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 <current@FreeBSD.ORG>; 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 <mzaki@e-mail.ne.jp>
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 <Alexander@Leidinger.net> 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 <mzaki@e-mail.ne.jp>
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 <freebsd-current@freebsd.org>; 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" <kdulzo@caffeine.gerp.org> "Fri, 29 Sep 2000 10:57:01 EST."
Date: Sat, 30 Sep 2000 09:39:36 +0200
From: Mark Murray <mark@grondar.za>
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 <current@freebsd.org>; 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: <matusita@jp.FreeBSD.org>
<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 <matusita@jp.FreeBSD.org>
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 <alex@big.endian.de>
To: Donn Miller <dmmiller@cvzoom.net>
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 <alex@big.endian.de>,
Donn Miller <dmmiller@cvzoom.net>, current@FreeBSD.ORG,
imp@freebsd.org
References: <20000929180208.A821@cichlids.cichlids.com> <Pine.BSF.4.21.0009291327080.62512-100000@acs-24-154-25-35.zoominternet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.21.0009291327080.62512-100000@acs-24-154-25-35.zoominternet.net>; 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 <current@freebsd.org>; 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 <tanimura@r.dl.itc.u-tokyo.ac.jp>
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" <n@nectar.com> 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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@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 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 <current@FreeBSD.ORG>; 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 <mwm@mired.org>
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 <alex@big.endian.de>
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>
<Pine.BSF.4.21.0009291327080.62512-100000@acs-24-154-25-35.zoominternet.net>
<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?
<mike
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:11 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 41A1837B502
for <current@freebsd.org>; 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 <alex@big.endian.de>
To: Mike Meyer <mwm@mired.org>
Cc: current@FreeBSD.ORG
Subject: Re: setting device permissions for DEVFS
Message-ID: <20000930201738.A17165@cichlids.cichlids.com>
Mail-Followup-To: Alexander Langer <alex@big.endian.de>,
Mike Meyer <mwm@mired.org>, current@FreeBSD.ORG
References: <20000929180208.A821@cichlids.cichlids.com> <Pine.BSF.4.21.0009291327080.62512-100000@acs-24-154-25-35.zoominternet.net> <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 <alex@big.endian.de>
To: Donn Miller <dmmiller@cvzoom.net>
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 <alex@big.endian.de>,
Donn Miller <dmmiller@cvzoom.net>, current@FreeBSD.ORG,
imp@FreeBSD.ORG
References: <20000929180208.A821@cichlids.cichlids.com> <Pine.BSF.4.21.0009291327080.62512-100000@acs-24-154-25-35.zoominternet.net> <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 <current@FreeBSD.ORG>; 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 <mwm@mired.org>
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 <tanimura@r.dl.itc.u-tokyo.ac.jp>
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" <n@nectar.com> 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.
<mike
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:53:15 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 A684437B503
for <current@FreeBSD.ORG>; 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 <mwm@mired.org>
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 <alex@big.endian.de>
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>
<Pine.BSF.4.21.0009291327080.62512-100000@acs-24-154-25-35.zoominternet.net>
<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?
<mike
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: 6:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from shale.csir.co.za (shale.csir.co.za [146.64.46.5])
by hub.freebsd.org (Postfix) with ESMTP id 92B7837B66D
for <current@FreeBSD.ORG>; 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 <reg@FreeBSD.ORG>
To: Mike Meyer <mwm@mired.org>
Cc: Alexander Langer <alex@big.endian.de>, current@FreeBSD.ORG
Subject: Re: setting device permissions for DEVFS
Message-ID: <20000930120607.C349@shale.csir.co.za>
References: <20000929180208.A821@cichlids.cichlids.com> <Pine.BSF.4.21.0009291327080.62512-100000@acs-24-154-25-35.zoominternet.net> <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 <freebsd-current@freebsd.org>; 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 <mzaki@e-mail.ne.jp>
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 <mzaki@e-mail.ne.jp>
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 <iwasaki@jp.FreeBSD.org>
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 <current@freebsd.org>; 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 <iwasaki@jp.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: 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 <msmith@freebsd.org>
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 <reg@FreeBSD.ORG>
Cc: Mike Meyer <mwm@mired.org>,
Alexander Langer <alex@big.endian.de>, 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 <phk@critter.freebsd.dk>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <bob@buckhorn.net>
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 <current@freebsd.org>
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 <iwasaki@jp.FreeBSD.org>
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 <current@freebsd.org>; 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 <iwasaki@jp.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: 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 <msmith@freebsd.org>
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 <current@freebsd.org>; 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 <alc@cs.rice.edu>
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 <freebsd-current@freebsd.org>; 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" <gjohnson@gs.verio.net>
To: "Gerhard Sittig" <Gerhard.Sittig@gmx.net>,
<freebsd-current@FreeBSD.ORG>
Subject: RE: interesting problem
Date: Sat, 30 Sep 2000 18:47:17 -0500
Message-ID: <FOENIGAJAKGPLNGHHADIKECPDBAA.gjohnson@gs.verio.net>
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 <freebsd-current@FreeBSD.ORG>; 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 <billf@chimesnet.com>
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: Gerhard Sittig <Gerhard.Sittig@gmx.net>,
freebsd-current@FreeBSD.ORG
Subject: Re: interesting problem
Message-ID: <20000930200138.X38472@jade.chc-chimes.com>
References: <20000929191133.R5065@speedy.gsinet> <FOENIGAJAKGPLNGHHADIKECPDBAA.gjohnson@gs.verio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <FOENIGAJAKGPLNGHHADIKECPDBAA.gjohnson@gs.verio.net>; 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 <thyerm@camtech.net.au>
X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 5.0-CURRENT i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Johnson <gjohnson@gs.verio.net>
Cc: Greg Lehey <grog@lemis.com>,
Thomas David Rivers <rivers@dignus.com>, bright@wintelcom.net,
freebsd-current@FreeBSD.ORG, kris@FreeBSD.ORG
Subject: You should be running -STABLE (Was: Re: interesting problem)
References: <FOENIGAJAKGPLNGHHADICENKDAAA.gjohnson@gs.verio.net>
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 <gshapiro@freebsd.org>
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 <gshapiro@FreeBSD.org>
Cc: freebsd-current@FreeBSD.org, cvs-committers@FreeBSD.org
Subject: Re: sendmail related changes
In-Reply-To: Message from Gregory Neil Shapiro <gshapiro@freebsd.org>
of "Sat, 30 Sep 2000 20:19:16 PDT." <14806.44340.887777.120946@horsey.gshapiro.net>
From: "Brian F. Feldman" <green@FreeBSD.org>
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 <gshapiro@freebsd.org> 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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <cjh@kr.FreeBSD.org>
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 <cjh@FreeBSD.org> <cjh@kr.FreeBSD.org>
KFUG <http://www.kr.FreeBSD.org> Web Data Bank <http://www.wdb.co.kr>
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 <tanimura@r.dl.itc.u-tokyo.ac.jp>
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 <mwm@mired.org> 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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@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: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 <current@FreeBSD.ORG>; 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 <mwm@mired.org>
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 <tanimura@r.dl.itc.u-tokyo.ac.jp>
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 <mwm@mired.org> 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 :-).
<mike
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:20:18 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 F37BF37B503
for <current@freebsd.org>; 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" <gjohnson@gs.verio.net>
To: "CHOI Junho" <cjh@kr.FreeBSD.org>, <current@freebsd.org>
Subject: RE: Today -current broken on build
Date: Sun, 1 Oct 2000 00:20:04 -0500
Message-ID: <FOENIGAJAKGPLNGHHADICEDGDBAA.gjohnson@gs.verio.net>
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 <cjh@FreeBSD.org>
<cjh@kr.FreeBSD.org>
KFUG <http://www.kr.FreeBSD.org> Web Data Bank
<http://www.wdb.co.kr>
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 <current@freebsd.org>; 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" <gjohnson@gs.verio.net>
Cc: "CHOI Junho" <cjh@kr.FreeBSD.org>, current@freebsd.org
Subject: Re: Today -current broken on build
In-reply-to: Your message of "Sun, 01 Oct 2000 00:20:04 CDT."
<FOENIGAJAKGPLNGHHADICEDGDBAA.gjohnson@gs.verio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 30 Sep 2000 22:34:29 -0700
From: Mike Smith <msmith@freebsd.org>
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 <cjh@FreeBSD.org>
> <cjh@kr.FreeBSD.org>
> KFUG <http://www.kr.FreeBSD.org> Web Data Bank
> <http://www.wdb.co.kr>
> 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