Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: unable to build i386 ALL kernel, errors in smbus_acpi.c (ACPI_SMBUS_COMPONENT undeclared)
Fixed (except the acpitz(4) part; I am not quite sure what it was for...).
Thanks.
(These are all typical reasons why I continue to clean-up the acpi(4) subtree.)
- Jukka.
On Thu, Mar 04, 2010 at 02:49:22PM -0500, Greg A. Woods wrote:
> At Wed, 3 Mar 2010 18:01:33 -0800 (PST), Paul Goyette
> <paul%whooppee.com@localhost> wrote:
> Subject: Re: unable to build i386 ALL kernel, errors in smbus_acpi.c
> (ACPI_SMBUS_COMPONENT undeclared)
> >
> > Please try the attached patch...
>
> Your last checked in changes to smbus_acpi.c don't seem to have ever
> been run through a compiler, at least not with the options I reported. :-)
>
> As a side note I think that's the first time I've ever seen one file in
> the NetBSD kernel blow up so bad that it not only blew away my 2000-line
> scroll-back buffer, but would have done so even if it had been 5000
> lines! This ACPI stuff must be pretty big and complex! Another 5061
> lines of compiler output followed these few when I tried to compile
> again today:
>
> compile ALL/smbus_acpi.o
> /rest/work/woods/m-NetBSD-current/sys/dev/acpi/smbus_acpi.c:42: error:
> expected declaration specifiers or '...' before string consta
> nt
> cc1: warnings being treated as errors
> In file included from /rest/work/woods/m-NetBSD-current/sys/sys/stdint.h:36,
> from /rest/work/woods/m-NetBSD-current/sys/sys/inttypes.h:39,
> from /rest/work/woods/m-NetBSD-current/sys/sys/param.h:100,
> from
> /rest/work/woods/m-NetBSD-current/sys/dev/acpi/smbus_acpi.c:44:
> ./machine/int_types.h:45: warning: return type defaults to 'int'
> ./machine/int_types.h:45: warning: function declaration isn't a prototype
> ./machine/int_types.h: In function 'ACPI_MODULE_NAME':
>
>
> I think it really would help a lot to make sure to have run a successful
> compile of the ALL kernel before committing any changes. That way it is
> ensured that the most possible lines of code have been at least parsed
> and compiled and that the results will link into a coherent binary
> without any conflicts or missing bits. I realize developers might not
> want to run two compiles every time they do anything (one to build
> something to test, and one to test their changes in the context of the
> largest workable environment), but not doing so can waste a whole lot of
> other peoples time too.
>
>
> The fix seems simple enough this time, based on observation of other
> similar modules in the same directory:
>
> --- smbus_acpi.c 04 Mar 2010 13:48:05 -0500 1.6
> +++ smbus_acpi.c 04 Mar 2010 14:10:30 -0500
> @@ -38,9 +38,6 @@
> #include <sys/cdefs.h>
> __KERNEL_RCSID(0, "$NetBSD: smbus_acpi.c,v 1.6 2010/03/04 13:11:14 pgoyette
> Exp $");
>
> -#define _COMPONENT ACPI_BUS_COMPONENT
> -ACPI_MODULE_NAME ("smbus_acpi")
> -
> #include <sys/param.h>
> #include <sys/systm.h>
> #include <sys/kernel.h>
> @@ -56,6 +53,9 @@
> #include <dev/acpi/acpireg.h>
> #include <dev/acpi/acpivar.h>
>
> +#define _COMPONENT ACPI_BUS_COMPONENT
> +ACPI_MODULE_NAME ("smbus_acpi")
> +
> #include <dev/i2c/i2cvar.h>
>
> /*
>
>
> At this point it seems as if your suggested patch is not necessary to
> achieve a successful compile, though perhaps it would still be desirable
> for other reasons -- I haven't tried it though.
>
>
> Now I'm on to the next similar errors:
>
> /rest/work/woods/m-NetBSD-current/sys/dev/acpi/atk0110.c: In function
> 'aibs_attach_sif':
> /rest/work/woods/m-NetBSD-current/sys/dev/acpi/atk0110.c:174: error:
> 'ACPI_RESOURCE_COMPONENT' undeclared (first use in this function)
> /rest/work/woods/m-NetBSD-current/sys/dev/acpi/atk0110.c:174: error: (Each
> undeclared identifier is reported only once
> /rest/work/woods/m-NetBSD-current/sys/dev/acpi/atk0110.c:174: error: for each
> function it appears in.)
> /rest/work/woods/m-NetBSD-current/sys/dev/acpi/atk0110.c: In function
> 'aibs_refresh':
> /rest/work/woods/m-NetBSD-current/sys/dev/acpi/atk0110.c:333: error:
> 'ACPI_RESOURCE_COMPONENT' undeclared (first use in this function)
>
>
> The following changes complete the ACPI-related fixes necessary to
> compile the ALL kernel:
>
> Index: sys/dev/acpi/atk0110.c
> ==================================================================RCS file:
> /cvs/master/m-NetBSD/main/src/sys/dev/acpi/atk0110.c,v
> retrieving revision 1.7
> diff -u -r1.7 atk0110.c
> --- sys/dev/acpi/atk0110.c 4 Mar 2010 08:44:55 -0000 1.7
> +++ sys/dev/acpi/atk0110.c 4 Mar 2010 19:25:38 -0000
> @@ -27,9 +27,6 @@
>
> #include <dev/sysmon/sysmonvar.h>
>
> -#include "acpi.h"
> -#include "acpivar.h"
> -
> /*
> * ASUSTeK AI Booster (ACPI ASOC ATK0110).
> *
> @@ -42,6 +39,10 @@
> * -- Constantine A. Murenin <http://cnst.su/>
> */
>
> +#include <dev/acpi/acpica.h>
> +#include <dev/acpi/acpireg.h>
> +#include <dev/acpi/acpivar.h>
> +
> #define _COMPONENT ACPI_RESOURCE_COMPONENT
> ACPI_MODULE_NAME ("acpi_aibs")
>
> Index: sys/dev/acpi/acpi.c
> ==================================================================RCS file:
> /cvs/master/m-NetBSD/main/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.152
> diff -u -r1.152 acpi.c
> --- sys/dev/acpi/acpi.c 3 Mar 2010 06:57:05 -0000 1.152
> +++ sys/dev/acpi/acpi.c 4 Mar 2010 01:11:59 -0000
> @@ -823,7 +823,7 @@
>
> #ifdef ACPI_DEBUG
> aprint_normal("acpi_activate_device: %s, old status=%x\n",
> - (*di)->HardwareId.Value, (*di)->CurrentStatus);
> + (*di)->HardwareId.String, (*di)->CurrentStatus);
> #endif
>
> rv = acpi_allocate_resources(handle);
> @@ -841,7 +841,7 @@
>
> #ifdef ACPI_DEBUG
> aprint_normal("acpi_activate_device: %s, new status=%x\n",
> - (*di)->HardwareId.Value, (*di)->CurrentStatus);
> + (*di)->HardwareId.String, (*di)->CurrentStatus);
> #endif
> }
> #endif /* ACPI_ACTIVATE_DEV */
>
>
> The need for this last change kinda stuns me since someone went
> carefully through the same file and changed every other instance of
> HardwareId.Value -- but it looks as though they did it based only on one
> set of compiler errors and not by truly reading and searching through
> the code.
>
> I made one more non-essential change to try to debug problems on some HP
> hardware:
>
> Index: sys/dev/acpi/acpi_tz.c
> ==================================================================RCS file:
> /cvs/master/m-NetBSD/main/src/sys/dev/acpi/acpi_tz.c,v
> retrieving revision 1.59
> diff -u -r1.59 acpi_tz.c
> --- sys/dev/acpi/acpi_tz.c 18 Feb 2010 14:10:15 -0000 1.59
> +++ sys/dev/acpi/acpi_tz.c 25 Feb 2010 01:45:51 -0000
> @@ -179,7 +179,7 @@
> ACPI_STATUS rv;
> ACPI_INTEGER v;
>
> -#if 0
> +#if ACPIVERBOSE
> sc->sc_flags = ATZ_F_VERBOSE;
> #endif
> sc->sc_devnode = aa->aa_node;
> @@ -255,7 +255,7 @@
> }
>
> if (acpitz_get_integer(dv, "_TMP", &tmp)) {
> - aprint_error_dev(dv, "failed to evaluate _TMP\n");
> + aprint_error_dev(dv, "failed to get ACPI _TMP value, no
> acpitz(4) support?\n");
> return;
> }
>
> @@ -586,6 +586,11 @@
> *tmp = ATZ_TMP_INVALID;
> }
>
> +/*
> + * XXX OpenBSD handles some values differently, "debouncing" invalid readings
> + * for some number of retries...
> + */
> +
> static int
> acpitz_get_integer(device_t dv, const char *cm, UINT32 *val)
> {
>
>
> --
> Greg A. Woods
> Planix, Inc.
>
> <woods%planix.com@localhost> +1 416 218 0099
> http://www.planix.com/
Home |
Main Index |
Thread Index |
Old Index