From owner-acpi-jp@jp.freebsd.org  Fri Sep 29 14:20:24 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id OAA02251;
	Fri, 29 Sep 2000 14:20:24 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id OAA02245;
	Fri, 29 Sep 2000 14:20:21 +0900 (JST)
	(envelope-from msmith@mass.osd.bsdi.com)
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 e8T5LUA03595;
	Thu, 28 Sep 2000 22:21:34 -0700 (PDT)
	(envelope-from msmith@mass.osd.bsdi.com)
Message-Id: <200009290521.e8T5LUA03595@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: acpi-jp@jp.freebsd.org, iwasaki@jp.freebsd.org
In-reply-to: Your message of "Fri, 29 Sep 2000 13:28:04 +0900."
             <200009290428.NAA28176@shidahara1.planet.sci.kobe-u.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 28 Sep 2000 22:21:29 -0700
From: Mike Smith <msmith@freebsd.org>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 687
Subject: [acpi-jp 687] Re: My system hang with ACPI kernel thread 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: msmith@freebsd.org

> In message <200009281819.e8SIJhA01660@mass.osd.bsdi.com>, Mike Smith wrote:
> >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
> 
> The 'dev/acpi/acpi.c' line  should be count for now.
> #define NACPI 1
> is needed not for acpi module it self, but needed for i386/i386/bios.c and
> i386/i386/machdep.c

The bios.c code will be removed in the next version of the patch, as will 
the code in machdep.c.  Everything will move to acpi_machdep.c  I'll also 
be deleting <machine/acpi.h>, as it's not necessary (and never was).

> To get rid of it,
> 1.Move ACPI bios detection code to acpi probe 
> (export some utility function is needed ,and spliting pnpbios driver 
> will be better  design,IMHO.)

The RSDT/FACP parsing is all that needs to be common, and I'm not 
entirely sure that the code shouldn't be duplicated for simplicity.  I'm 
not sure about moving the pmap code yet; the last time I tried I ran into 
the ptov functionality and I decided my technique was wrong.

> 2.Export Int15h E820H-compatible format of memory map.
> It may be good design to eject the real memory detection code 
> to boot loader.This is not only solve this problem,but also 
> solve Libretto30 16bpp X problem cleanly(*).

Laying out the memory map in the loader has always been an appealing 
idea.  I'm not sure how I feel about this though, as people want to be 
able to boot without it still.

> (*)
> To use X on Libretto30 with 16bpp mode,15M-16M range memory 
> should not be used.And BIOS cannot detect it,so 
> user should override memory detection. see
> 
> http://www.jp.freebsd.org/cgi/cvsweb.cgi/PAO3/src/sys/i386/i386/machdep.c?r1=1.6&r2=1.7&cvsroot=freebsd-jp

I'll have a look at this, but as I understand it you need the 15-16M 
memory hole, correct?

-- 
... 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


