From owner-svn-src-head@FreeBSD.ORG Tue Mar 9 18:03:58 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id C889A1065721; Tue, 9 Mar 2010 18:03:57 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Tue, 9 Mar 2010 13:03:45 -0500 User-Agent: KMail/1.6.2 References: <201003081940.o28JeVG1088074@svn.freebsd.org> <201003082035.43977.jkim@FreeBSD.org> <201003090753.31627.jhb@freebsd.org> In-Reply-To: <201003090753.31627.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003091303.49689.jkim@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r204877 - head/sys/modules/acpi/acpi X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 18:03:58 -0000 On Tuesday 09 March 2010 07:53 am, John Baldwin wrote: > On Monday 08 March 2010 8:35:42 pm Jung-uk Kim wrote: > > On Monday 08 March 2010 05:52 pm, Jung-uk Kim wrote: > > > On Monday 08 March 2010 05:25 pm, John Baldwin wrote: > > > > On Monday 08 March 2010 5:11:42 pm Jung-uk Kim wrote: > > > > > On Monday 08 March 2010 04:11 pm, John Baldwin wrote: > > > > > > On Monday 08 March 2010 2:40:31 pm Jung-uk Kim wrote: > > > > > > > Author: jkim > > > > > > > Date: Mon Mar 8 19:40:31 2010 > > > > > > > New Revision: 204877 > > > > > > > URL: http://svn.freebsd.org/changeset/base/204877 > > > > > > > > > > > > > > Log: > > > > > > > Enable ACPI module build on amd64. Although we > > > > > > > strongly recommend building it into kernel, there is no > > > > > > > need to prevent it from building at all. > > > > > > > > > > > > (Oops, ignore previous spurious reply). > > > > > > > > > > > > Please revert this. The MADT parser on amd64 is slightly > > > > > > different from i386 and will not work when acpi is loaded > > > > > > as a module. If anything, I would prefer we make acpi > > > > > > not be a module on i386. There are several things that > > > > > > would be far less invasive to implement via #ifdef > > > > > > DEV_ACPI than by defining runtime kobj interfaces to the > > > > > > ACPI driver. > > > > > > > > > > madt.c itself is not very different but I understand what > > > > > you are trying to explain here. In fact, I tested it > > > > > before committing and the trick was adding mptable in place > > > > > of acpi. It worked fine although it may not be ideal. I > > > > > can back out sys/modules/acpi/Makefile change if you agree, > > > > > however. > > > > > > > > It is different enough. Specifically, the amd64 one sets a > > > > "better" value for mp_maxid than i386, but it can only do > > > > this because it can run before SI_SUB_KLD since it is never > > > > invoked as a module. I still think that we should probably > > > > be moving away from acpi.ko rather than towards for other > > > > reasons. > > > > > > I noticed that and I used mptable instead, which seems to do > > > well enough for the job. Please keep in mind that I am not > > > trying to promote acpi.ko at all. I just want to make sure > > > acpi.ko can be built and loaded without builing and installing > > > the whole world/kernel for i386 to test new ACPICA. :-( > > > > > > Any way, I will just revert sys/modules/acpi/Makefile change, > > > then. It should be a reasonable compromise, deal? > > > > I thought you complained because I accidentally committed my > > local changes to sys/modules/acpi/Makefile. In fact, I didn't. > > :-) Do you still think I should back it out? Or is it okay? > > I think it should be backed out. The MP table is not really a good > workaround as you cannot mix and match ACPI and MP table for PCI > interrupt routing. Or rather, if you use the MP Table, we have to > use it for all PCI stuff and cannot use ACPI for any PCI-related > stuff, so it's not really ideal. I don't think the system quite > does the right thing though. I suspect it is still using ACPI to > manage PCI and you are just getting lucky that ACPI numbers the IO > APIC IRQs the same way FreeBSD's MP Table driver happens to do. Understood. Thanks for the detailed explanation. > Also, the MP Table is not always kept up to date in modern BIOSes. > Since most modern OS's only use the ACPI tables, BIOS writers do > not test the MP Table, and I know of one instance a few years ago > where Intel shipped a completely wrong MP Table for a new platform > because nothing they tested used it. I am well aware of this issue. > If all you want is the ability to build an acpi.ko but not to > actually use it, then maybe you could only enable building the > module if a special variable is set? That is, you could do 'make > BUILD_KLD=yes' in sys/modules/acpi/acpi to build the module for > debugging. However, a default build (such as building GENERIC) > would not build or install acpi.ko. And we do not build or install acpi.ko by default as you expected: # $FreeBSD: head/sys/modules/acpi/Makefile 194701 2009-06-23 13:17:25Z rpaulo $ .if ${MACHINE} == "i386" SUBDIR= acpi .endif SUBDIR+= acpi_aiboost acpi_asus acpi_fujitsu acpi_hp acpi_ibm \ acpi_panasonic acpi_sony acpi_toshiba acpi_video \ acpi_dock acpi_wmi .include You have to descend to the subdir and build/install manually and that's all I wanted. > I just build a full kernel to test ACPI changes myself. Thanks. Jung-uk Kim