From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 8 05:12:16 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 192ED1065674 for ; Mon, 8 Jun 2009 05:12:16 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 908038FC12 for ; Mon, 8 Jun 2009 05:12:15 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:Sender; b=Wi/mQSCBV63522Tr4zZGFfKFBskGRVDLzISxvTsoOI7bIheYgHfj7hrJZmmUVeFKrYZr0RticSgLoABl7HvsnncVJ2lzZ7BmTMXfLYfnYGTXtbcAr5Pt81u3yyWBiwB49b3Pk9eyacnupUCFGOZ5Hn1FK8dC5dGc9hmuzGmGHQk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MDX9a-00017v-Kt for freebsd-acpi@freebsd.org; Mon, 08 Jun 2009 09:12:14 +0400 Date: Mon, 8 Jun 2009 09:12:12 +0400 From: Eygene Ryabinkin To: freebsd-acpi@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sender: rea-fbsd@codelabs.ru Subject: [PATCH] acpidump: teach to disassemble arbitrary memory locations as AML code X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 05:12:16 -0000 It is not uncommon when some chunks of the AML code are loaded by DSDT =66rom the memory locations that aren't part of the DSDT itself, but one wants to see what's inside. It can be achieved with 'dd' and 'iasl', but it is better to implement this machinery inside acpidump to ease the life of both users and develepers that needs to see the full picture of the ACPI stuff from foreign machines. This commit also have some small fixes: - verbose output (going to stderr) isn't mixed with normal output that goes to stdout -- the latter is made unbuffered; - we're using IASL's logics to get the name of the output file and, moreover, we prevent two simultaneous invocations of acpidump to hose other's output; - IASL exit code is checked and if disassembler exited abnormally or was failed to do its job, the warning is produced to give the reader an idea on what's going on. Signed-off-by: Eygene Ryabinkin --- usr.sbin/acpi/acpidump/acpi.c | 165 ++++++++++++++++++++++++++++++++-= ---- usr.sbin/acpi/acpidump/acpidump.8 | 5 + usr.sbin/acpi/acpidump/acpidump.c | 97 +++++++++++++++++++++- usr.sbin/acpi/acpidump/acpidump.h | 2 + 4 files changed, 244 insertions(+), 25 deletions(-) diff --git a/usr.sbin/acpi/acpidump/acpi.c b/usr.sbin/acpi/acpidump/acpi.c index fed0fb2..321f894 100644 --- a/usr.sbin/acpi/acpidump/acpi.c +++ b/usr.sbin/acpi/acpidump/acpi.c @@ -1,6 +1,7 @@ /*- * Copyright (c) 1998 Doug Rabson * Copyright (c) 2000 Mitsuru IWASAKI + * Copyright (c) 2009 Eygene Ryabinkin * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -31,10 +32,13 @@ #include #include #include +#include +#include #include #include #include #include +#include #include #include =20 @@ -800,47 +804,166 @@ dsdt_save_file(char *outfile, struct ACPIsdt *rsdt, = struct ACPIsdt *dsdp) close(fd); } =20 -void -aml_disassemble(struct ACPIsdt *rsdt, struct ACPIsdt *dsdp) -{ - char tmpstr[32], buf[256]; - FILE *fp; - int fd, len; +#define TMPIN "/tmp/acpidump.XXXXXX.aml" +#define TMPSLEN 4 =20 - strcpy(tmpstr, "/tmp/acpidump.XXXXXX"); - fd =3D mkstemp(tmpstr); - if (fd < 0) { - perror("iasl tmp file"); +/* + * Disassembles contents of a given file and dumps them to the + * specified file descriptor. + */ +static void +invoke_iasl(char *infile, FILE *outfp) +{ + char buf[256], *outfile; + int len, status; + FILE *fp; + pid_t child; + + if (strlen(infile) <=3D TMPSLEN) { + warnx("bad input file name '%s', should be longer " + "than " ##TMPSLEN " characters", infile); return; } - write_dsdt(fd, rsdt, dsdp); - close(fd); + if (strcmp(infile + strlen(infile) - TMPSLEN, ".aml")) { + warnx("bad input file name '%s', should end on '.aml'", + infile); + return; + } + outfile =3D strdup(infile); + if (outfile =3D=3D NULL) { + perror("ASL tmp file"); + return; + } + strcpy(outfile + strlen(outfile) - TMPSLEN, ".dsl"); =20 - /* Run iasl -d on the temp file */ - if (fork() =3D=3D 0) { + /* Run iasl -d on the input file */ + child =3D fork(); + if (child =3D=3D -1) { + warn("fork"); + free(outfile); + return; + } + if (child =3D=3D 0) { close(STDOUT_FILENO); if (vflag =3D=3D 0) close(STDERR_FILENO); - execl("/usr/sbin/iasl", "iasl", "-d", tmpstr, (char *) 0); + execl("/usr/sbin/iasl", "iasl", "-d", "-p", outfile, + infile, (char *) 0); err(1, "exec"); } =20 - wait(NULL); - unlink(tmpstr); + if (waitpid(child, &status, 0) !=3D child) { + warn("waitpid(%lu)", (unsigned long)child); + unlink(outfile); + free(outfile); + return; + } + + if (!WIFEXITED(status)) { + warnx("IASL exited abnormally: status =3D %d", status); + unlink(outfile); + free(outfile); + return; + } + + if (WEXITSTATUS(status) !=3D 0) { + warnx("IASL was not able to disassemble the passed AML code"); + unlink(outfile); + free(outfile); + return; + } =20 /* Dump iasl's output to stdout */ - fp =3D fopen("acpidump.dsl", "r"); - unlink("acpidump.dsl"); + fp =3D fopen(outfile, "r"); + unlink(outfile); + free(outfile); if (fp =3D=3D NULL) { - perror("iasl tmp file (read)"); + perror("ASL tmp file (read)"); return; } while ((len =3D fread(buf, 1, sizeof(buf), fp)) > 0) - fwrite(buf, 1, len, stdout); + fwrite(buf, 1, len, outfp); fclose(fp); } =20 void +mem_disassemble(size_t dumpaddr, size_t dumplen) +{ + char tmpstr[sizeof(TMPIN)]; + char buf[256]; + int fd, memfd, toread, towrite; + + strcpy(tmpstr, TMPIN); + fd =3D mkstemps(tmpstr, TMPSLEN); + if (fd < 0) { + perror("AML tmp file"); + return; + } + memfd =3D open("/dev/mem", O_RDONLY); + if (memfd =3D=3D -1) { + perror("open /dev/mem"); + close(fd); + unlink(tmpstr); + return; + } + if (lseek(memfd, dumpaddr, SEEK_SET) =3D=3D -1) { + perror("seeking /dev/mem"); + close(fd); + close(memfd); + unlink(tmpstr); + return; + } + + while (dumplen > 0) { + toread =3D (dumplen > sizeof(buf) ? sizeof(buf) : dumplen); + towrite =3D read(memfd, buf, toread); + if (towrite =3D=3D -1) { + perror("reading /dev/mem"); + close(fd); + close(memfd); + unlink(tmpstr); + return; + } + if (write(fd, buf, towrite) !=3D towrite) { + perror("writing to AML tmp file"); + close(fd); + close(memfd); + unlink(tmpstr); + return; + } + dumplen -=3D towrite; + } + + close(fd); + close(memfd); + + invoke_iasl(tmpstr, stdout); + unlink(tmpstr); +} + +void +aml_disassemble(struct ACPIsdt *rsdt, struct ACPIsdt *dsdp) +{ + char tmpstr[sizeof(TMPIN)]; + int fd; + + strcpy(tmpstr, TMPIN); + fd =3D mkstemps(tmpstr, TMPSLEN); + if (fd < 0) { + perror("AML tmp file"); + return; + } + write_dsdt(fd, rsdt, dsdp); + close(fd); + + invoke_iasl(tmpstr, stdout); + unlink(tmpstr); +} + +#undef TMPIN +#undef TMPSLEN + +void sdt_print_all(struct ACPIsdt *rsdp) { acpi_handle_rsdt(rsdp); diff --git a/usr.sbin/acpi/acpidump/acpidump.8 b/usr.sbin/acpi/acpidump/acp= idump.8 index 1401e38..ec16e4b 100644 --- a/usr.sbin/acpi/acpidump/acpidump.8 +++ b/usr.sbin/acpi/acpidump/acpidump.8 @@ -4,6 +4,7 @@ .\" Copyright (c) 2000 Mitsuru IWASAKI .\" Copyright (c) 2000 Yasuo YOKOYAMA .\" Copyright (c) 2000 Hiroki Sato +.\" Copyright (c) 2009 Eygene Ryabinkin .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without @@ -43,6 +44,7 @@ .Op Fl v .Op Fl f Ar dsdt_input .Op Fl o Ar dsdt_output +.Op Fl a Ar address:length .Sh DESCRIPTION The .Nm @@ -122,6 +124,9 @@ the DSDT consists of free-formatted AML data. The following options are supported by .Nm : .Bl -tag -width indent +.It Fl d Ar address:length +Disassemble the given block of physical memory to the standard output. +This flag can be repeated: multiple blocks will be disassembled. .It Fl d Disassemble the DSDT into ASL using .Xr iasl 8 diff --git a/usr.sbin/acpi/acpidump/acpidump.c b/usr.sbin/acpi/acpidump/acp= idump.c index a601ac2..b10527a 100644 --- a/usr.sbin/acpi/acpidump/acpidump.c +++ b/usr.sbin/acpi/acpidump/acpidump.c @@ -1,5 +1,6 @@ /*- * Copyright (c) 2000 Mitsuru IWASAKI + * Copyright (c) 2009 Eygene Ryabinkin * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -32,6 +33,7 @@ #include #include #include +#include #include =20 #include "acpidump.h" @@ -40,23 +42,78 @@ int dflag; /* Disassemble AML using iasl(8) */ int tflag; /* Dump contents of SDT tables */ int vflag; /* Use verbose messages */ =20 +struct aflag { + size_t addr; + size_t size; + struct aflag *next; +}; + static void usage(const char *progname) { =20 - fprintf(stderr, "usage: %s [-d] [-t] [-h] [-v] [-f dsdt_input] " + fprintf(stderr, "usage: %s [-a addr:len] [-d] [-t] [-h] [-v] [-f dsdt_inp= ut] " "[-o dsdt_output]\n", progname); fprintf(stderr, "To send ASL:\n\t%s -dt | gzip -c9 > foo.asl.gz\n", progname); exit(1); } =20 +/* + * Parses pair of address:length from the given string. + * Both numbers can be hexadecimal (prefixed by 0[xX]) + * or plain decimal. + * + * Returns 0 for success, !=3D 0 otherwise. + */ +static int +parse_addr(const char *arg, size_t *addr, size_t *len) +{ + char *c1, *c2, *a, *l; + + c1 =3D strchr(arg, ':'); + c2 =3D strrchr(arg, ':'); + if (c1 !=3D c2 || c1 =3D=3D NULL) { + warnx ("argument to '-a' should have form 'addr:len'"); + return 1; + } + + l =3D c1 + 1; + a =3D strndup(arg, l - arg); + if (a =3D=3D NULL) + err(EX_OSERR, "can't parse address:size tuple"); + + if (sscanf(a, "%zi", addr) !=3D 1) { + warnx("Unable to parse address from argument to '-a'"); + free(a); + return 1; + } + if (sscanf(l, "%zi", len) !=3D 1) { + warnx("Unable to parse length from argument to '-a'"); + free(a); + return 1; + } + + free(a); + return 0; +} + int main(int argc, char *argv[]) { char c, *progname; - char *dsdt_input_file, *dsdt_output_file; - struct ACPIsdt *rsdt, *sdt; + char *dsdt_input_file =3D NULL, *dsdt_output_file =3D NULL; + struct ACPIsdt *rsdt =3D NULL, *sdt =3D NULL; + struct aflag *aroot =3D NULL, *atmp; + + /* + * When stdin/stdout are sent to the same file, stdout shouldn't + * be buffered to prevent mixing two outputs. We won't try to + * check it stdin/stdout are the same files, but will just + * make stdout unbuffered unconditionally. This is most + * useful when we're running in verbose mode. + */ + setbuf(stdout, NULL); =20 dsdt_input_file =3D dsdt_output_file =3D NULL; progname =3D argv[0]; @@ -64,8 +121,17 @@ main(int argc, char *argv[]) if (argc < 2) usage(progname); =20 - while ((c =3D getopt(argc, argv, "dhtvf:o:")) !=3D -1) { + while ((c =3D getopt(argc, argv, "a:dhtvf:o:")) !=3D -1) { switch (c) { + case 'a': + atmp =3D (struct aflag *)malloc(sizeof(*atmp)); + if (atmp =3D=3D NULL) + errx(EX_OSERR, "parsing arguments to '-a'"); + if (parse_addr(optarg, &atmp->addr, &atmp->size)) + usage(progname); + atmp->next =3D aroot; + aroot =3D atmp; + break; case 'd': dflag =3D 1; break; @@ -140,5 +206,28 @@ main(int argc, char *argv[]) warnx("iasl processing complete"); } =20 + if (aroot !=3D NULL) { + struct aflag *nroot =3D NULL; + /* Reverse list and disassemble each memory location */ + while (aroot !=3D NULL) { + atmp =3D aroot->next; + aroot->next =3D nroot; + nroot =3D aroot; + aroot =3D atmp; + } + while (nroot !=3D NULL) { + if (vflag) { + warnx("disassembling memory at 0x%zx, " + "0x%zx bytes", nroot->addr, nroot->size); + } + mem_disassemble(nroot->addr, nroot->size); + if (vflag) + warnx("finished disassembling"); + atmp =3D nroot; + nroot =3D nroot->next; + free(atmp); + } + } + exit(0); } diff --git a/usr.sbin/acpi/acpidump/acpidump.h b/usr.sbin/acpi/acpidump/acp= idump.h index 8d79168..8428b58 100644 --- a/usr.sbin/acpi/acpidump/acpidump.h +++ b/usr.sbin/acpi/acpidump/acpidump.h @@ -332,6 +332,8 @@ void sdt_print_all(struct ACPIsdt *); =20 /* Disassemble the AML in the DSDT */ void aml_disassemble(struct ACPIsdt *, struct ACPIsdt *); +/* Disassemble arbitrary memory chunk */ +void mem_disassemble(size_t dumpaddr, size_t dumplen); =20 /* Routines for accessing tables in physical memory */ struct ACPIrsdp *acpi_find_rsd_ptr(void); --=20 1.6.3.1 --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 8 05:46:22 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A19C106564A for ; Mon, 8 Jun 2009 05:46:22 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id A555A8FC1A for ; Mon, 8 Jun 2009 05:46:21 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=pUGQqkMfHUvhtIr/ggHkMIVIXy3yH51C5Hv2OSl7yNKJHsd2zk57i6IGdjHhf2z7lCXQU+z2/ZLBWfdPO24FTCm3pSf8QiONvHZG8pX9UlcfOVY7En5shZaKN4eRxlmleJSf+5CRGi0Njxf0kP7SzVo3cW45qySZOMabMalETV4=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MDXga-0004bF-Of for freebsd-acpi@freebsd.org; Mon, 08 Jun 2009 09:46:20 +0400 Date: Mon, 8 Jun 2009 09:46:18 +0400 From: Eygene Ryabinkin To: freebsd-acpi@freebsd.org Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="p609JBPwWeYlfsbE" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: [PATCH] acpidump: teach to disassemble arbitrary memory locations as AML code X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 05:46:22 -0000 --p609JBPwWeYlfsbE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Mon, Jun 08, 2009 at 09:12:12AM +0400, Eygene Ryabinkin wrote: > It is not uncommon when some chunks of the AML code are loaded by DSDT > from the memory locations that aren't part of the DSDT itself, but one > wants to see what's inside. It can be achieved with 'dd' and 'iasl', > but it is better to implement this machinery inside acpidump to ease the > life of both users and develepers that needs to see the full picture > of the ACPI stuff from foreign machines. [...] Hmm, seems like the patch was a bit corrupted, so attaching it instead of making inline. I had also submitted PR for this stuff: http://www.freebsd.org/cgi/query-pr.cgi?pr=135349 -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --p609JBPwWeYlfsbE-- From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 8 08:09:10 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D2C7106566C; Mon, 8 Jun 2009 08:09:10 +0000 (UTC) (envelope-from josef.moellers@ts.fujitsu.com) Received: from dgate10.ts.fujitsu.com (dgate10.ts.fujitsu.com [80.70.172.49]) by mx1.freebsd.org (Postfix) with ESMTP id 704BC8FC1A; Mon, 8 Jun 2009 08:09:08 +0000 (UTC) (envelope-from josef.moellers@ts.fujitsu.com) DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Organization:User-Agent: MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=aQQqf0+OWCkkpcugTTIVMM0VECYDFdyXO+T3UKDQpHdiRjzENBx0hWEJ T+yuqfevhOTyqN7ihDtbSuXZ2yDHxEywZLL9cDkimyvlqAnJR2dPVtFM5 /pNKnRbEojeL9hgH0r5WTyLRAXzjkhnSRqDSvlBxu+DVdnOoo2KZiccfG 1ZpiWFOvKq7BizF4p1rfUYbsm5zB0nR5UScPXXVTWsAtT39+hhjy8s+lT ouuzT0niZFnpOO1KljPJZ2uG2HC3X; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=josef.moellers@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1244448563; x=1275984563; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Josef=20Moellers=20|Subject:=20Re:=20Failure=20to=20get=20past=20a=20PCI =20bridge|Date:=20Mon,=2008=20Jun=202009=2010:09:11=20+02 00|Message-ID:=20<4A2CC727.50806@ts.fujitsu.com>|To:=20Jo hn=20Baldwin=20|CC:=20"freebsd-acpi@free bsd.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=208bit|In-Reply-To:=20<200906 051152.24609.jhb@freebsd.org>|References:=20<4A24D29A.503 0604@ts.fujitsu.com>=20<200906051030.30236.jhb@freebsd.or g>=20<4A293100.7030203@ts.fujitsu.com>=20<200906051152.24 609.jhb@freebsd.org>; bh=vVIkmpgXflKfopFcIX5SeV2rJFRfviLidnNQRlrQybE=; b=fngBeolsGPrKYFLPJhyOtswryv2K5vIjirAtCgcEONirvQcKpLXdBRWO OnyonaEx7LFWE56PmEFKyL0EF4i1qsIhSfGixexc0xvRXyqZFU0LD0Gv+ /A59rufVFOEX4LjW8ccMW4aY+19+7gj9qN0FP4jR0NFXpkVk8UMipDEGE rfUvfuraxMewZIi5r1XEux+PTP1tH278kXptx7Xx5rNfSDaOqNMdRqlSC mNZGiFFwzyYY6z0yp6+CmZPMpu1IT; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.41,323,1241388000"; d="scan'208";a="81362945" Received: from abgdgate40u.abg.fsc.net ([172.25.138.90]) by dgate10u.abg.fsc.net with ESMTP; 08 Jun 2009 10:09:21 +0200 X-IronPort-AV: E=Sophos;i="4.41,322,1241388000"; d="scan'208";a="52108882" Received: from dolphin.pdb.fsc.net (HELO [192.168.32.205]) ([172.25.253.253]) by abgdgate40u.abg.fsc.net with ESMTP; 08 Jun 2009 10:09:07 +0200 Message-ID: <4A2CC727.50806@ts.fujitsu.com> Date: Mon, 08 Jun 2009 10:09:11 +0200 From: Josef Moellers Organization: Fujitsu Technology Solutions User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: John Baldwin References: <4A24D29A.5030604@ts.fujitsu.com> <200906051030.30236.jhb@freebsd.org> <4A293100.7030203@ts.fujitsu.com> <200906051152.24609.jhb@freebsd.org> In-Reply-To: <200906051152.24609.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-acpi@freebsd.org" Subject: Re: Failure to get past a PCI bridge X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 08:09:10 -0000 'morning, John Baldwin wrote: > On Friday 05 June 2009 10:51:44 am Josef Moellers wrote: > >> Hello, >> >> Thanks for the help! >> >> John Baldwin wrote: >> >>> On Friday 05 June 2009 5:17:25 am Josef Moellers wrote: >>> >>> >>>> Difficult, since I can't boot properly. >>>> However, I have managed to get the dsdt using a SuSE Linux and have run >>>> that through acpidump -d on a 7.2 running on a XEN virtual machine. >>>> Here's the result. >>>> >>>> >>> Hmm, your BIOS is certainly hosed. First, it does have separate processor >>> objects: >>> >> [...] >> >> I'll show this to our BIOS people. When I talked to them before, they >> claimed that everything were OK, since the OSes we support do come up >> properly. >> > > I think your BIOS is actually ok, sorry my e-mail was a bit of a stream of > conciousness. > That's what my colleague confirmed ;-) However, being the nice guy that he is, he provided me with a preliminary extra special test version (he was on the brink of going on holiday!), which presents the bridges in their numerical order (0, 1, 2, 0xfe, 0xff). With that BIOS, I finally got access to the keyboard and RAID controller and all and I'm installing FBSD as I'm writing this. So, maybe the algorithm shouldn't be "if we find a bridge with number 0 which is not the first one, give it another number" shouldn't this be "if we find *a* *second* bridge with number 0, give it another number"? > >>> PCI bus 254, and pcib2 has PCI bus 0). Try this: >>> >>> >> [...] >> That will be difficult, because I'd have to rebuild the installation CD >> from scratch. >> But I guess fixing the problem is better that building a work-around for it. >> > > Ah, if you have a working machine where you can build a kernel, you can build > an new CD using an existing ISO as a template. Simply build a GENERIC kernel > and install it into some DESTDIR=/foo and mount the ISO image using mdconfig > to /dist. Then do something like 'mkisofs -o new.iso -r -J -b > boot/cdboot -no-emul-boot -x /dist/boot/kernel /dist /foo'. If that > complains about duplicate 'boot/kernel' then you may need to copy all > of /dist/boot to /foo/boot, install the new kernel into /foo, and > use '-x /dist/boot /dist /foo'. > > Also, if this machine supports PXE boot at all, that can be a way to boot a > test kernel as well. Maybe that's what we'll have to do after all. Thanks for the support, Josef -- These are my personal views and not those of Fujitsu Technology Solutions! Josef Möllers (Pinguinpfleger bei FTS) If failure had no penalty success would not be a prize (T. Pratchett) Company Details: http://de.ts.fujitsu.com/imprint.html From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 8 08:30:07 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95845106566C for ; Mon, 8 Jun 2009 08:30:07 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id E86EB8FC15 for ; Mon, 8 Jun 2009 08:30:06 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by ewy8 with SMTP id 8so3872486ewy.43 for ; Mon, 08 Jun 2009 01:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:mime-version:message-id:content-type :content-transfer-encoding; bh=hb7F1EF0TZ4/+lCzjVkZ1VJI9ygBhL2aUJjc0fEUh/w=; b=CuTUnHsWDtSZmPm83sdYv6Ab8fBi3583MIeBXI6cJEpQOfbe33Vz4Ji9yDk64m6N39 mLRvSCWE8aS6twrk9U7lljtzU1REMb7vmZhNkyeuWDp252tnKg0seqX2Bz8IEpCXKwcx NBUZ3IltOTRR/ewHsIMMzn4XwpXUKWULk+G3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :message-id:content-type:content-transfer-encoding; b=pB0iRTajh+dbxirxVS33R6xDN2RaHNjyU6QfRWsBHfbO+onnstVEKkMGMgnB1q4etT NBR027RZXT6504BmcmgSngv8qXHvtjRmybVYp+Bl75bYc5+ez1wgHFcXOsYOA+8C5EF7 WLUgJ1CBfh+yeh75LCdbqZgZ7h3iNXBqwt1uY= Received: by 10.216.15.85 with SMTP id e63mr2177994wee.199.1244448151086; Mon, 08 Jun 2009 01:02:31 -0700 (PDT) Received: from dragonmini.dg ([196.34.241.123]) by mx.google.com with ESMTPS id f13sm2961737gvd.23.2009.06.08.01.02.25 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 01:02:30 -0700 (PDT) From: David Naylor Organization: Private To: freebsd-acpi@freebsd.org Date: Mon, 8 Jun 2009 10:02:35 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200906081002.37853.naylor.b.david@gmail.com> Content-Type: multipart/signed; boundary="nextPart1319713.eFRYOlUdSV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Subject: Lenovo S10 and ACPI problems X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 08:30:07 -0000 --nextPart1319713.eFRYOlUdSV Content-Type: multipart/mixed; boundary="Boundary-01=_bWMLK24M+bSmkqr" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_bWMLK24M+bSmkqr Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I'm getting ACPI related problems with a Lenovo S10e. The battery status w= ill=20 not update (and I assume temperature). Sometimes this even results in a=20 power off (shutdown -p) not powering off the netbook (in this case it looks= =20 as if ACPI got disabled). =20 Disabling EC stops dmesg from being flooded with error messages from ACPI. = =20 I've tried debug.acpi.ec.polled=3D1 and debug.acpi.ec.burst=3D1 in various= =20 combinations without success (no change in behaviour). =20 A recompile of the DSDT shows only a few warnings and one remark. I don't= =20 think the warnings are related to this (not that I know anything about DSDT= ). =20 If anyone would like the DSDT just let me know and I'll mail it to you. =20 Windows (XP and Vista) obviously work, didn't find any reference to this=20 problem with Linux (via Google). =20 The following is from -Current (after recent ACPI import) with verbose boot= =2E =20 Had the same problem with old ACPI implementation. (The latest BIOS is use= d) # grep -i acpi /var/run/dmesg.boot [ See attached ] Any help will be appreciated. Regards, David Extracted some error messages: ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed=20 [\\_SB_.PCI0.LPCB.EC0_.GBAS] (Node 0xc3e58e00), AE_NO_HARDWARE_RESPONSE ACPI Error (psparse-0633): Method parse/execution failed=20 [\\_SB_.PCI0.LPCB.EC0_._Q2E] (Node 0xc3e5b000), AE_NO_HARDWARE_RESPONSE acpi_ec0: evaluation of query method _Q2E failed: AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.ACAD._PSR]= =20 (Node 0xc3e54240), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_TZ_.TZ00._TMP]= =20 (Node 0xc3d4a280), AE_NO_HARDWARE_RESPONSE acpi_tz0: error fetching current temperature -- AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA]= =20 (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node= =20 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._BST]= =20 (Node 0xc3e53dc0), AE_NO_HARDWARE_RESPONSE --Boundary-01=_bWMLK24M+bSmkqr Content-Type: text/plain; charset="iso 8859-15"; name="dmesg.boot" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.boot" Features=0xbfe9fbff MADT: Found CPU APIC ID 0 ACPI ID 0: enabled MADT: Found CPU APIC ID 1 ACPI ID 1: enabled ACPI APIC Table: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ACPI: RSDP 0xf7a60 00024 (v2 PTLTD ) ACPI: XSDT 0x3f6dac38 00084 (v1 LENOVO CB-01 06040000 LTP 00000000) ACPI: FACP 0x3f6e1bd7 000F4 (v3 INTEL CALISTGA 06040000 ALAN 00000001) ACPI: DSDT 0x3f6dbe3a 05D29 (v1 INTEL CALISTGA 06040000 INTL 20061109) ACPI: FACS 0x3f6e2fc0 00040 ACPI: HPET 0x3f6e1ccb 00038 (v1 INTEL CALISTGA 06040000 LOHR 0000005A) ACPI: MCFG 0x3f6e1d03 0003C (v1 INTEL CALISTGA 06040000 LOHR 0000005A) ACPI: TCPA 0x3f6e1d3f 00032 (v1 PTLTD CALISTGA 06040000 PTL 00000001) ACPI: TMOR 0x3f6e1d71 00026 (v1 PTLTD 06040000 PTL 00000003) ACPI: APIC 0x3f6e1d97 00068 (v1 PTLTD APIC 06040000 LTP 00000000) ACPI: BOOT 0x3f6e1dff 00028 (v1 PTLTD $SBFTBL$ 06040000 LTP 00000001) ACPI: SLIC 0x3f6e1e27 00176 (v1 LENOVO CB-01 06040000 LTP 00000000) ACPI: ASF! 0x3f6e1f9d 00063 (v16 CETP CETP 06040000 PTL 00000001) ACPI: SSDT 0x3f6db258 0025F (v1 PmRef Cpu0Tst 00003000 INTL 20050624) ACPI: SSDT 0x3f6db1b2 000A6 (v1 PmRef Cpu1Tst 00003000 INTL 20050624) ACPI: SSDT 0x3f6dacbc 004F6 (v2 PmRef CpuPm 00003000 INTL 20050624) acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc398f000 pa 0x1000 AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 pcib3: irq 18 at device 28.2 on pci0 pci5: on pcib3 pcib4: at device 30.0 on pci0 pci6: on pcib4 acpi_tz0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 psmcpnp0: irq 12 on acpi0 cpu0: on acpi0 ACPI: SSDT 0x3f6dbb21 00245 (v2 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: SSDT 0x3f6db4b7 005E5 (v2 PmRef Cpu0Cst 00003001 INTL 20050624) cpu1: on acpi0 ACPI: SSDT 0x3f6dbd66 000D4 (v2 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: SSDT 0x3f6dba9c 00085 (v2 PmRef Cpu1Cst 00003000 INTL 20050624) acpi_acad0: acline initialization start acpi_acad0: Off Line acpi_acad0: acline initialization done, tried 1 times acpi_ec0: wait timed out (no response), forcing polled mode acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.PCI0.LPCB.EC0_.GBAS] (Node 0xc3e58e00), AE_NO_HARDWARE_RESPONSE ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.PCI0.LPCB.EC0_._Q2E] (Node 0xc3e5b000), AE_NO_HARDWARE_RESPONSE acpi_ec0: evaluation of query method _Q2E failed: AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.ACAD._PSR] (Node 0xc3e54240), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.ACAD._PSR] (Node 0xc3e54240), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_TZ_.TZ00._TMP] (Node 0xc3d4a280), AE_NO_HARDWARE_RESPONSE acpi_tz0: error fetching current temperature -- AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc3e53dc0), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0.UPBS] (Node 0xc3e53d80), AE_NO_HARDWARE_RESPONSE ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc3e53dc0), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc3e53dc0), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc3e53dc0), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc3e53dc0), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] 20090521 evregion-531 ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc3e53dc0), AE_NO_HARDWARE_RESPONSE --Boundary-01=_bWMLK24M+bSmkqr-- --nextPart1319713.eFRYOlUdSV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkosxZ0ACgkQUaaFgP9pFrIxBQCfcqy79Kb2rri87Jbi8VInc52d cukAniZvdTKAtjAeqMqUTBpE43GkAcmu =+nOq -----END PGP SIGNATURE----- --nextPart1319713.eFRYOlUdSV-- From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 8 11:06:47 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EE001065670 for ; Mon, 8 Jun 2009 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F05788FC15 for ; Mon, 8 Jun 2009 11:06:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n58B6k7k020521 for ; Mon, 8 Jun 2009 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n58B6kpP020517 for freebsd-acpi@FreeBSD.org; Mon, 8 Jun 2009 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jun 2009 11:06:46 GMT Message-Id: <200906081106.n58B6kpP020517@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 47 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 8 15:33:56 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14E6B10656AC for ; Mon, 8 Jun 2009 15:33:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2976B8FC08 for ; Mon, 8 Jun 2009 15:33:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D39CC46B3B; Mon, 8 Jun 2009 11:33:54 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AEC498A049; Mon, 8 Jun 2009 11:33:51 -0400 (EDT) From: John Baldwin To: Josef Moellers Date: Mon, 8 Jun 2009 10:47:17 -0400 User-Agent: KMail/1.9.7 References: <4A24D29A.5030604@ts.fujitsu.com> <200906051152.24609.jhb@freebsd.org> <4A2CC727.50806@ts.fujitsu.com> In-Reply-To: <4A2CC727.50806@ts.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906081047.17487.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Jun 2009 11:33:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "freebsd-acpi@freebsd.org" Subject: Re: Failure to get past a PCI bridge X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 15:33:57 -0000 On Monday 08 June 2009 4:09:11 am Josef Moellers wrote: > 'morning, > > John Baldwin wrote: > > On Friday 05 June 2009 10:51:44 am Josef Moellers wrote: > > > >> Hello, > >> > >> Thanks for the help! > >> > >> John Baldwin wrote: > >> > >>> On Friday 05 June 2009 5:17:25 am Josef Moellers wrote: > >>> > >>> > >>>> Difficult, since I can't boot properly. > >>>> However, I have managed to get the dsdt using a SuSE Linux and have run > >>>> that through acpidump -d on a 7.2 running on a XEN virtual machine. > >>>> Here's the result. > >>>> > >>>> > >>> Hmm, your BIOS is certainly hosed. First, it does have separate processor > >>> objects: > >>> > >> [...] > >> > >> I'll show this to our BIOS people. When I talked to them before, they > >> claimed that everything were OK, since the OSes we support do come up > >> properly. > >> > > > > I think your BIOS is actually ok, sorry my e-mail was a bit of a stream of > > conciousness. > > > That's what my colleague confirmed ;-) > However, being the nice guy that he is, he provided me with a > preliminary extra special test version (he was on the brink of going on > holiday!), which presents the bridges in their numerical order (0, 1, 2, > 0xfe, 0xff). With that BIOS, I finally got access to the keyboard and > RAID controller and all and I'm installing FBSD as I'm writing this. > > So, maybe the algorithm shouldn't be "if we find a bridge with number 0 > which is not the first one, give it another number" shouldn't this be > "if we find *a* *second* bridge with number 0, give it another number"? Yes, that's bascially what my patch does. > > Ah, if you have a working machine where you can build a kernel, you can build > > an new CD using an existing ISO as a template. Simply build a GENERIC kernel > > and install it into some DESTDIR=/foo and mount the ISO image using mdconfig > > to /dist. Then do something like 'mkisofs -o new.iso -r -J -b > > boot/cdboot -no-emul-boot -x /dist/boot/kernel /dist /foo'. If that > > complains about duplicate 'boot/kernel' then you may need to copy all > > of /dist/boot to /foo/boot, install the new kernel into /foo, and > > use '-x /dist/boot /dist /foo'. > > > > Also, if this machine supports PXE boot at all, that can be a way to boot a > > test kernel as well. > Maybe that's what we'll have to do after all. Ok, let me know if it works. Thanks. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 8 18:21:28 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07F5D106566C for ; Mon, 8 Jun 2009 18:21:28 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9B78FC16 for ; Mon, 8 Jun 2009 18:21:27 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: by fg-out-1718.google.com with SMTP id e12so820658fga.12 for ; Mon, 08 Jun 2009 11:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:organization:to :subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; bh=SzSLS9TfOjXQjCRRM25pZcakOYq+WlPuBKGcjfVlUPg=; b=Yc0j0n1+jc6VaS1ePagoxBoeo5ybsk5Lp8tqI2li1LyDm8uVGAj9Y1sqgqhdOeJJQq VWERR2Eiz6XbdLAOybbYmOl2UmHfsRBnHtDf+2mRqKOVWz0kjyrsOjbnw4u3ESCJpVuX eLx8Uyn+/DuklaP0p8bJdOIh79cs5VcgzeWeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:organization:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=jgjmfbExb28a9tOAwQA/DZcxCAT1viG0fU9wp0JnnYSH9cf39h8l/TVeDukSYlblJR U6U8NFgItNHv3hVSMbnE6dsLgGp5ClitzZqlO9cUtYcoFWhy6TmoJnDjnbFZdiiaNLjW 9MOj89MJqBGg7C+l/tZGtu3nQvReUIPtY6WnM= Received: by 10.86.82.17 with SMTP id f17mr7581508fgb.65.1244485286383; Mon, 08 Jun 2009 11:21:26 -0700 (PDT) Received: from onyx_hp.dhcp.loc ([92.50.244.69]) by mx.google.com with ESMTPS id d4sm157516fga.11.2009.06.08.11.21.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 11:21:24 -0700 (PDT) From: Dmitry Kolosov Organization: Home To: freebsd-acpi@freebsd.org Date: Mon, 8 Jun 2009 22:21:21 +0400 User-Agent: KMail/1.11.4 (FreeBSD/7.2-STABLE; KDE/4.2.4; i386; ; ) References: <200906081002.37853.naylor.b.david@gmail.com> In-Reply-To: <200906081002.37853.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906082221.21912.ivakras1@gmail.com> Subject: Re: Lenovo S10 and ACPI problems X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ivakras1@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 18:21:28 -0000 =F0=CF=CE=C5=C4=C5=CC=D8=CE=C9=CB 08 =C9=C0=CE=D1 2009 12:02:35 David Naylo= r =D0=C9=D3=C1=CC=C9: > Hi, >=20 > I'm getting ACPI related problems with a Lenovo S10e. The battery status= will=20 > not update (and I assume temperature). Sometimes this even results in a= =20 > power off (shutdown -p) not powering off the netbook (in this case it loo= ks=20 > as if ACPI got disabled). =20 >=20 > Disabling EC stops dmesg from being flooded with error messages from ACPI= =2E =20 > I've tried debug.acpi.ec.polled=3D1 and debug.acpi.ec.burst=3D1 in variou= s=20 > combinations without success (no change in behaviour). =20 >=20 > A recompile of the DSDT shows only a few warnings and one remark. I don'= t=20 > think the warnings are related to this (not that I know anything about DS= DT). =20 > If anyone would like the DSDT just let me know and I'll mail it to you. = =20 >=20 > Windows (XP and Vista) obviously work, didn't find any reference to this= =20 > problem with Linux (via Google). =20 >=20 > The following is from -Current (after recent ACPI import) with verbose bo= ot. =20 > Had the same problem with old ACPI implementation. (The latest BIOS is u= sed) >=20 > # grep -i acpi /var/run/dmesg.boot > [ See attached ] >=20 > Any help will be appreciated. >=20 > Regards, >=20 > David >=20 > Extracted some error messages: > ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 > [EmbeddedControl] 20090521 evregion-531 > ACPI Error (psparse-0633): Method parse/execution failed=20 > [\\_SB_.PCI0.LPCB.EC0_.GBAS] (Node 0xc3e58e00), AE_NO_HARDWARE_RESPONSE > ACPI Error (psparse-0633): Method parse/execution failed=20 > [\\_SB_.PCI0.LPCB.EC0_._Q2E] (Node 0xc3e5b000), AE_NO_HARDWARE_RESPONSE > acpi_ec0: evaluation of query method _Q2E failed: AE_NO_HARDWARE_RESPONSE >=20 > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 > [EmbeddedControl] 20090521 evregion-531 > ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.ACAD._PS= R]=20 > (Node 0xc3e54240), AE_NO_HARDWARE_RESPONSE >=20 > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 > [EmbeddedControl] 20090521 evregion-531 > ACPI Error (psparse-0633): Method parse/execution failed [\\_TZ_.TZ00._TM= P]=20 > (Node 0xc3d4a280), AE_NO_HARDWARE_RESPONSE > acpi_tz0: error fetching current temperature -- AE_NO_HARDWARE_RESPONSE >=20 > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 > [EmbeddedControl] 20090521 evregion-531 > ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._ST= A]=20 > (Node 0xc3e53e00), AE_NO_HARDWARE_RESPONSE > ACPI Error (uteval-0329): Method execution failed [\\_SB_.BAT0._STA] (Nod= e=20 > 0xc3e53e00), AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for=20 > [EmbeddedControl] 20090521 evregion-531 > ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._BS= T]=20 > (Node 0xc3e53dc0), AE_NO_HARDWARE_RESPONSE >=20 Same problem with 7.2-STABLE on ACER Aspire 5720. From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 9 08:15:47 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C0DA1065670; Tue, 9 Jun 2009 08:15:47 +0000 (UTC) (envelope-from josef.moellers@ts.fujitsu.com) Received: from dgate20.ts.fujitsu.com (dgate20.ts.fujitsu.com [80.70.172.51]) by mx1.freebsd.org (Postfix) with ESMTP id 7841F8FC17; Tue, 9 Jun 2009 08:15:46 +0000 (UTC) (envelope-from josef.moellers@ts.fujitsu.com) DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Organization:User-Agent: MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=bmbtl3u86krSd91cZiFARCBFvbODVT30JdEAPfLBIuyfFlkpw3/7TOh6 OeuPud4eX/nCzNdMYPtrghMkb1vUG5kEtJc8Cv/P8TRgJJ4iJ6arCjxB4 5snO4V6jbgCAaDIZZpEYOaCdi1jgtw4ge1hLOJCL6kxn02hj8ahEW87o9 NaslWxGLghntyBSv2yLLqz11JXboir51ayTp0s7EtkJiyQHtuoJkZ3drZ SewGJ9/zPbJzTGXBI6a1Ortc8AW7y; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=josef.moellers@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1244535275; x=1276071275; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Josef=20Moellers=20|Subject:=20Re:=20Failure=20to=20get=20past=20a=20PCI =20bridge|Date:=20Tue,=2009=20Jun=202009=2010:15:48=20+02 00|Message-ID:=20<4A2E1A34.2010405@ts.fujitsu.com>|To:=20 John=20Baldwin=20|CC:=20"freebsd-acpi@fr eebsd.org"=20|MIME-Version:=201 .0|Content-Transfer-Encoding:=208bit|In-Reply-To:=20<2009 06081047.17487.jhb@freebsd.org>|References:=20<4A24D29A.5 030604@ts.fujitsu.com>=20<200906051152.24609.jhb@freebsd. org>=20<4A2CC727.50806@ts.fujitsu.com>=20<200906081047.17 487.jhb@freebsd.org>; bh=jfcn0Psd/IuqayEjR/E0l8Laig6jIlxbpTXsiO6G2Gc=; b=ROFNJCCbP1LTnCETiEZziVKNqpXgquDvUaGM86jQfxjsDjGv5KSJNF2k /eF6vQCCvpQQWyssMzdb4lzooOA0JkA0X9cPRxIyBNuQduClalbKBqdSP yEalTPT5oYS3yxSFuzNpKV/SVJHgq2rfbuB6hjIIpJ8oq8HwVRPzVZ4v5 p7p2ECY4nAqkB1qEVfYhjTGc8s5IaLZEqXTg3V0xBx1QJ7cep8vrt676Y ap2V8t7E3l5E5sBAs8v7VJoWnPes/; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.41,330,1241388000"; d="scan'208";a="71617926" Received: from abgdgate40u.abg.fsc.net ([172.25.138.90]) by dgate20u.abg.fsc.net with ESMTP; 09 Jun 2009 10:14:33 +0200 X-IronPort-AV: E=Sophos;i="4.41,329,1241388000"; d="scan'208";a="52195084" Received: from unknown (HELO [172.25.253.16]) ([172.25.253.16]) by abgdgate40u.abg.fsc.net with ESMTP; 09 Jun 2009 10:15:44 +0200 Message-ID: <4A2E1A34.2010405@ts.fujitsu.com> Date: Tue, 09 Jun 2009 10:15:48 +0200 From: Josef Moellers Organization: Fujitsu Technology Solutions User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: John Baldwin References: <4A24D29A.5030604@ts.fujitsu.com> <200906051152.24609.jhb@freebsd.org> <4A2CC727.50806@ts.fujitsu.com> <200906081047.17487.jhb@freebsd.org> In-Reply-To: <200906081047.17487.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-acpi@freebsd.org" Subject: Re: Failure to get past a PCI bridge X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 08:15:47 -0000 John Baldwin wrote: > On Monday 08 June 2009 4:09:11 am Josef Moellers wrote: > >> 'morning, >> >> John Baldwin wrote: >> >>> On Friday 05 June 2009 10:51:44 am Josef Moellers wrote: >>> >>> >>>> Hello, >>>> >>>> Thanks for the help! >>>> >>>> John Baldwin wrote: >>>> >>>> >>>>> On Friday 05 June 2009 5:17:25 am Josef Moellers wrote: >>>>> >>>>> >>>>> >>>>>> Difficult, since I can't boot properly. >>>>>> However, I have managed to get the dsdt using a SuSE Linux and have run >>>>>> that through acpidump -d on a 7.2 running on a XEN virtual machine. >>>>>> Here's the result. >>>>>> >>>>>> >>>>>> >>>>> Hmm, your BIOS is certainly hosed. First, it does have separate >>>>> > processor > >>>>> objects: >>>>> >>>>> >>>> [...] >>>> >>>> I'll show this to our BIOS people. When I talked to them before, they >>>> claimed that everything were OK, since the OSes we support do come up >>>> properly. >>>> >>>> >>> I think your BIOS is actually ok, sorry my e-mail was a bit of a stream of >>> conciousness. >>> >>> >> That's what my colleague confirmed ;-) >> However, being the nice guy that he is, he provided me with a >> preliminary extra special test version (he was on the brink of going on >> holiday!), which presents the bridges in their numerical order (0, 1, 2, >> 0xfe, 0xff). With that BIOS, I finally got access to the keyboard and >> RAID controller and all and I'm installing FBSD as I'm writing this. >> >> So, maybe the algorithm shouldn't be "if we find a bridge with number 0 >> which is not the first one, give it another number" shouldn't this be >> "if we find *a* *second* bridge with number 0, give it another number"? >> > > Yes, that's bascially what my patch does. > I promise to do my best to read mails in the future ;-) Yes, you're obviously right. Shame on me. > >>> Ah, if you have a working machine where you can build a kernel, you can >>> > build > >>> an new CD using an existing ISO as a template. Simply build a GENERIC >>> > kernel > >>> and install it into some DESTDIR=/foo and mount the ISO image using >>> > mdconfig > >>> to /dist. Then do something like 'mkisofs -o new.iso -r -J -b >>> boot/cdboot -no-emul-boot -x /dist/boot/kernel /dist /foo'. If that >>> complains about duplicate 'boot/kernel' then you may need to copy all >>> of /dist/boot to /foo/boot, install the new kernel into /foo, and >>> use '-x /dist/boot /dist /foo'. >>> >>> Also, if this machine supports PXE boot at all, that can be a way to boot >>> > a > >>> test kernel as well. >>> >> Maybe that's what we'll have to do after all. >> > > Ok, let me know if it works. Thanks. Yepp! Works like a charm. I had been able to boot the original kernel with the modified BIOS and apply your patch. Then I rebooted with that kernel (on the modified BIOS, i.e. the one with the 0 254 255 bus numbers) and it booted OK. Then I flashed the BIOS back to a release version (i.e. one with 255 254 0 bus numbers) and the patched kernel booted OK and the non-patched kernel (kernel.old) crashed because it did not find its root FS. BTW As I understand it, the 254 and 255 busses are on-chip Nehalem busses which provide access to certain chip registers. Will this make its way into a future release? 8.0? Josef -- These are my personal views and not those of Fujitsu Technology Solutions! Josef Möllers (Pinguinpfleger bei FTS) If failure had no penalty success would not be a prize (T. Pratchett) Company Details: http://de.ts.fujitsu.com/imprint.html From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 9 13:49:42 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33F4D106564A for ; Tue, 9 Jun 2009 13:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0583D8FC1A for ; Tue, 9 Jun 2009 13:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B144546B0C; Tue, 9 Jun 2009 09:49:41 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 78E2D8A06B; Tue, 9 Jun 2009 09:49:40 -0400 (EDT) From: John Baldwin To: Josef Moellers Date: Tue, 9 Jun 2009 09:39:34 -0400 User-Agent: KMail/1.9.7 References: <4A24D29A.5030604@ts.fujitsu.com> <200906081047.17487.jhb@freebsd.org> <4A2E1A34.2010405@ts.fujitsu.com> In-Reply-To: <4A2E1A34.2010405@ts.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906090939.34827.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 09 Jun 2009 09:49:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "freebsd-acpi@freebsd.org" Subject: Re: Failure to get past a PCI bridge X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:49:42 -0000 On Tuesday 09 June 2009 4:15:48 am Josef Moellers wrote: > > Ok, let me know if it works. Thanks. > Yepp! Works like a charm. I had been able to boot the original kernel > with the modified BIOS and apply your patch. > Then I rebooted with that kernel (on the modified BIOS, i.e. the one > with the 0 254 255 bus numbers) and it booted OK. Then I flashed the > BIOS back to a release version (i.e. one with 255 254 0 bus numbers) and > the patched kernel booted OK and the non-patched kernel (kernel.old) > crashed because it did not find its root FS. Woo, thanks for testing. > BTW As I understand it, the 254 and 255 busses are on-chip Nehalem > busses which provide access to certain chip registers. > > Will this make its way into a future release? 8.0? Yes, it will be in 8.0 and 7.3. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 9 13:51:34 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0153F10656CF; Tue, 9 Jun 2009 13:51:34 +0000 (UTC) (envelope-from josef.moellers@ts.fujitsu.com) Received: from dgate10.ts.fujitsu.com (dgate10.ts.fujitsu.com [80.70.172.49]) by mx1.freebsd.org (Postfix) with ESMTP id 367348FC13; Tue, 9 Jun 2009 13:51:32 +0000 (UTC) (envelope-from josef.moellers@ts.fujitsu.com) DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Organization:User-Agent: MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=X959rWXcDKX1mr3MquX0XjIaYdf64vTo4RbCbrixxghi+5WNd8JvUn7h PhvW7hxr8g95dgwIz6AeZ/IM2oCPMU7xFL8d1tx4Yr90Rb0BzPrFySFl6 0aoMnDO/GP1ioKwoCH3MqFY51SLoiVAriLPGzhA5lp7GlHhrD+SCY/acD xsAZIEu0SQgSRp6Ejbvrwv6c89/lPDhPbRYPzpqKB+Bgqn5/q0K0c8pXx 3eS+Lc2reddUgFVkfH/G9YBfsCjpk; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=josef.moellers@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1244555557; x=1276091557; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Josef=20Moellers=20|Subject:=20Re:=20Failure=20to=20get=20past=20a=20PCI =20bridge|Date:=20Tue,=2009=20Jun=202009=2015:51:35=20+02 00|Message-ID:=20<4A2E68E7.50907@ts.fujitsu.com>|To:=20Jo hn=20Baldwin=20|CC:=20"freebsd-acpi@free bsd.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=208bit|In-Reply-To:=20<200906 090939.34827.jhb@freebsd.org>|References:=20<4A24D29A.503 0604@ts.fujitsu.com>=20<200906081047.17487.jhb@freebsd.or g>=20<4A2E1A34.2010405@ts.fujitsu.com>=20<200906090939.34 827.jhb@freebsd.org>; bh=4nPsujMqkpc9Bf9O/WZPhLfhM3i+cK2wNVl83nzW7dI=; b=X5WtcGpaWRPSPEGyoNHT7AIupmVLCFwCw0kGKYdvlZFu1Ryt/4GQ8Bkj WIi3yLRolUWpxHbwqnRQhQzJnziLWFpq7UaZQ3KrO+N4I59igvdNM9CFz GUyTkDP19Dt0AaALGs7zA8+23u0suiFxXaQtRbLNzUZXNIwWnHdeKxDaF sUSkH6EYRgMevrAJBWPfeaqsgkE8kVWX9kSpJ13APsgN+zstjYGBQafWf vrNTg5kpmCnk1cVXmhX2rbgqTMxyL; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.41,331,1241388000"; d="scan'208";a="81747282" Received: from abgdgate40u.abg.fsc.net ([172.25.138.90]) by dgate10u.abg.fsc.net with ESMTP; 09 Jun 2009 15:52:35 +0200 X-IronPort-AV: E=Sophos;i="4.41,331,1241388000"; d="scan'208";a="52227812" Received: from unknown (HELO [172.25.253.16]) ([172.25.253.16]) by abgdgate40u.abg.fsc.net with ESMTP; 09 Jun 2009 15:51:30 +0200 Message-ID: <4A2E68E7.50907@ts.fujitsu.com> Date: Tue, 09 Jun 2009 15:51:35 +0200 From: Josef Moellers Organization: Fujitsu Technology Solutions User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: John Baldwin References: <4A24D29A.5030604@ts.fujitsu.com> <200906081047.17487.jhb@freebsd.org> <4A2E1A34.2010405@ts.fujitsu.com> <200906090939.34827.jhb@freebsd.org> In-Reply-To: <200906090939.34827.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-acpi@freebsd.org" Subject: Re: Failure to get past a PCI bridge X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:51:35 -0000 John Baldwin wrote: > On Tuesday 09 June 2009 4:15:48 am Josef Moellers wrote: > >>> Ok, let me know if it works. Thanks. >>> >> Yepp! Works like a charm. I had been able to boot the original kernel >> with the modified BIOS and apply your patch. >> Then I rebooted with that kernel (on the modified BIOS, i.e. the one >> with the 0 254 255 bus numbers) and it booted OK. Then I flashed the >> BIOS back to a release version (i.e. one with 255 254 0 bus numbers) and >> the patched kernel booted OK and the non-patched kernel (kernel.old) >> crashed because it did not find its root FS. >> > > Woo, thanks for testing. > No problem! Thanks for helping. > >> BTW As I understand it, the 254 and 255 busses are on-chip Nehalem >> busses which provide access to certain chip registers. >> >> Will this make its way into a future release? 8.0? >> > > Yes, it will be in 8.0 and 7.3. Great news, especially the "7.3". Keep up the good work, Josef -- These are my personal views and not those of Fujitsu Technology Solutions! Josef Möllers (Pinguinpfleger bei FTS) If failure had no penalty success would not be a prize (T. Pratchett) Company Details: http://de.ts.fujitsu.com/imprint.html From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 9 15:26:20 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AEA01065672 for ; Tue, 9 Jun 2009 15:26:20 +0000 (UTC) (envelope-from dan@dburkland.com) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by mx1.freebsd.org (Postfix) with SMTP id C9C038FC29 for ; Tue, 9 Jun 2009 15:26:19 +0000 (UTC) (envelope-from dan@dburkland.com) Received: from source ([173.8.114.137]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKSi5/G0q3hjTFxZ6lNk8vCIk4wCeSY+91@postini.com; Tue, 09 Jun 2009 08:26:20 PDT Received: from mail.dburk.local ([10.0.0.4]) by mail ([10.0.0.4]) with mapi; Tue, 9 Jun 2009 10:15:31 -0500 From: Daniel Burkland To: "freebsd-acpi@freebsd.org" Date: Tue, 9 Jun 2009 10:14:18 -0500 Thread-Topic: Lenovo S10 and ACPI problems Thread-Index: AQHJ6RUgLRV/Fb3GAEaI1581mKjPgQ== Message-ID: <9BF0E9EFFF8AD245AAB6AAB1542D95967AAF0281@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: Lenovo S10 and ACPI problems X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 15:26:20 -0000 I also am experiencing similars error messages when I use shutdown -p on my= Vostro 1310. I made a post on the FreeBSD forums which you can find here: = http://forums.freebsd.org/showthread.php?t=3D3513&highlight=3Dvostro+1310 I= can run Linux on the machine with no problems but as I am no developer I w= ould have no idea on how to fix this issue.=20 Dan= From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 10 17:00:13 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F7BC106566B for ; Wed, 10 Jun 2009 17:00:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1A28FC17 for ; Wed, 10 Jun 2009 17:00:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5AH0Ccx021913 for ; Wed, 10 Jun 2009 17:00:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5AH0CX5021912; Wed, 10 Jun 2009 17:00:12 GMT (envelope-from gnats) Date: Wed, 10 Jun 2009 17:00:12 GMT Message-Id: <200906101700.n5AH0CX5021912@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Wesha Cc: Subject: Re: kern/132602: [acpi] ACPI Problem with Intel SS4200: System does not power off X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wesha List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 17:00:13 -0000 The following reply was made to PR kern/132602; it has been noted by GNATS. From: Wesha To: bug-followup@FreeBSD.org, MasterOne@o0l0o.org Cc: Subject: Re: kern/132602: [acpi] ACPI Problem with Intel SS4200: System does not power off Date: Wed, 10 Jun 2009 11:40:17 -0500 ------------25741E13756C1AC Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hello Bug-followup, It turns out that it powers off just fine if USB controller is disabled in SS4200 BIOS. Hope it would give some leads. See screenshot @ http://ss4200.pbworks.com/FreeNAS-0_70 --=20 Best regards, Wesha mailto:freebsd-bugs2@wesha.name ------------25741E13756C1AC Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6 iQEVAwUASi/h8LY28H2PPbCpAQEsugf9EUwJPNnywPisPAVbLzDB+S6ml9yPLUmY jGCo5XTLgr5rkQUxJ4RJOB66DMMuZtKDvyxZHiZWjBpInbP5uiujolDFeSG/EogK AVMnm7vUdILULQXzrnGW+/3hSgCPiN0J8Llsi54z3C6T+u8wKtNarxVDqee329mo fDGjdj7yIazIngaJGslR7AeVRgEZvA5nnrsFGcAzoRVE874SbAhqiV4YS0txzDX2 5RI7MscZ756uWzflwDIjeOeMHk4L4lY6T6ZX7FaA3BH3yobl7wPn61kPyYLg1poH s7N3NIV2D2nWxiBYVw00eQqXAHX4UvFOSFUhpS2d6eMIwnrMuE90ng== =6bkl -----END PGP MESSAGE----- ------------25741E13756C1AC-- From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 10 20:18:07 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35558106564A for ; Wed, 10 Jun 2009 20:18:07 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id B32268FC08 for ; Wed, 10 Jun 2009 20:18:01 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by ewy8 with SMTP id 8so1107512ewy.43 for ; Wed, 10 Jun 2009 13:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:mime-version:message-id:content-type :content-transfer-encoding; bh=VbsgqZwepenUwS7zOJ3xg2FfDmRmLhXtMVoe5RE0jBs=; b=se/N9Kd/57px6ZKHDUxIJR89VNKgI7E4XpNPA+GH4OXr/WJukccwfp/n5yELv7r/ch bcX+Qqky3BTABGqdklyu01lpkBFz7jrzuTY0hSbc4A97Ye2Zb4Pnna/V1X8p8hMMhUso TJwzo9uW+DgYY3vTN/eqTAby+YguAVR+Z21I4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :message-id:content-type:content-transfer-encoding; b=SDWqzAJZ0eUBKzGFgksUf+t0tOMgbV9pg4OwWYiDAlA2o5hb2QNQZoe80uky1iX8nJ YhY3rwujYzYbY2SGNqZLgjbpV78vk4GjywepYOIV3B4VIK9pZu6IgrgPCst+PLWvgPRp wFcRmt16gVDMvuS79CsRufdIjgcGXZHK42isA= Received: by 10.210.39.2 with SMTP id m2mr4562497ebm.2.1244665080750; Wed, 10 Jun 2009 13:18:00 -0700 (PDT) Received: from dragonmini.dg ([196.34.241.123]) by mx.google.com with ESMTPS id 10sm44194eyz.51.2009.06.10.13.17.57 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 13:18:00 -0700 (PDT) From: David Naylor Organization: Private To: freebsd-acpi@freebsd.org Date: Wed, 10 Jun 2009 22:19:09 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200906102219.13050.naylor.b.david@gmail.com> Content-Type: multipart/signed; boundary="nextPart1361612.cF3FHAUn6d"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Subject: Missing hw.acpi.poll_timeout (and other tunable) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 20:18:07 -0000 --nextPart1361612.cF3FHAUn6d Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, While trying to debug my misbehaving ACPI I tried using hw.acpi.poll_timeou= t. =20 When trying to find the default value I couldn't find any reference to it i= n=20 the source codes: # find /usr/src -type f | xargs -i poll_timeout | grep=20 =2E/share/man/man4/acpi.4:.It Va hw.acpi.ec.poll_timeout This tunable is documented in acpi(4). Is there a reason for this being=20 removed. =20 Also there are other tunables that may be useful for diagnostics (although= =20 they didn't work for me) that are not mentioned in the man pages. These ar= e=20 debug.acpi.ec.burst, debug.acpi.ec.polled, debug.acpi.ec.timeout (may be th= e=20 above tunable renamed?) [although I got the impression that these tunables= =20 where 'temporary', if so please ignore]. =20 My apologies if I've preempted pending commits for acpi. =20 Regards, David P.S. Not on mailing-list --nextPart1361612.cF3FHAUn6d Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkowFUEACgkQUaaFgP9pFrKFwgCeNSQvhT/flnim4EI4OSpmQAPZ nPcAnjGlhewhtmA5Il1eXFU2aXYYMNhr =tulE -----END PGP SIGNATURE----- --nextPart1361612.cF3FHAUn6d-- From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 12 21:48:01 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B24B106566C for ; Fri, 12 Jun 2009 21:48:01 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi157.prodigy.net (nlpi157.sbcis.sbc.com [207.115.36.171]) by mx1.freebsd.org (Postfix) with ESMTP id D48AD8FC08 for ; Fri, 12 Jun 2009 21:48:00 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-2-171.dsl.snfc21.pacbell.net [71.139.2.171]) (authenticated bits=0) by nlpi157.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n5CLZqI9015669; Fri, 12 Jun 2009 16:35:53 -0500 Message-ID: <4A32CA38.4020806@root.org> Date: Fri, 12 Jun 2009 14:35:52 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eygene Ryabinkin References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: [PATCH] acpidump: teach to disassemble arbitrary memory locations as AML code X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 21:48:01 -0000 Eygene Ryabinkin wrote: > It is not uncommon when some chunks of the AML code are loaded by DSDT > from the memory locations that aren't part of the DSDT itself, but one > wants to see what's inside. It can be achieved with 'dd' and 'iasl', > but it is better to implement this machinery inside acpidump to ease the > life of both users and develepers that needs to see the full picture > of the ACPI stuff from foreign machines. > > This commit also have some small fixes: > > - verbose output (going to stderr) isn't mixed with normal output > that goes to stdout -- the latter is made unbuffered; > > - we're using IASL's logics to get the name of the output file and, > moreover, we prevent two simultaneous invocations of acpidump > to hose other's output; > > - IASL exit code is checked and if disassembler exited abnormally > or was failed to do its job, the warning is produced to give > the reader an idea on what's going on. > > Signed-off-by: Eygene Ryabinkin I appreciate your work. What we need to do though is remove acpidump(8) from the system and import Intel's acpidmp utility. It's included in the ACPI-CA distribution and is functional enough that we can use it. Any functions we need that it doesn't yet have can be submitted to Intel to merge. Thanks, -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 12 22:02:38 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8869A106566C for ; Fri, 12 Jun 2009 22:02:38 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 68AA28FC13 for ; Fri, 12 Jun 2009 22:02:38 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 12 Jun 2009 14:55:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.42,211,1243839600"; d="scan'208";a="698920373" Received: from orsmsx601.amr.corp.intel.com ([10.22.226.213]) by fmsmga001.fm.intel.com with ESMTP; 12 Jun 2009 15:05:59 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx601.amr.corp.intel.com ([10.22.226.213]) with mapi; Fri, 12 Jun 2009 15:02:33 -0700 From: "Moore, Robert" To: Nate Lawson , Eygene Ryabinkin Date: Fri, 12 Jun 2009 15:02:33 -0700 Thread-Topic: [PATCH] acpidump: teach to disassemble arbitrary memory locations as AML code Thread-Index: Acnrp3sY5EPGLiq4Se+oJw73Hdt3wAAAeyoA Message-ID: <4911F71203A09E4D9981D27F9D8308582E6840C8@orsmsx503.amr.corp.intel.com> References: <4A32CA38.4020806@root.org> In-Reply-To: <4A32CA38.4020806@root.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" Subject: RE: [PATCH] acpidump: teach to disassemble arbitrary memory locations as AML code X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 22:02:38 -0000 Actually, we don't distribute an acpidump (yet) in ACPICA. The Linux versio= n is part of the "pmtools" package. It is of course, linux-specific. I won't distribute it with ACPICA until we= have an OS-independent version. It is on our list of things to-do. The formatting code is rather simple, but it would be best to have one inst= ance of the code, part of acpica. It would go like this: Get rsdt/xsdt -> call to OSL For all tables: Get acpi table -> call to OSL Dump the table >-----Original Message----- >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >acpi@freebsd.org] On Behalf Of Nate Lawson >Sent: Friday, June 12, 2009 2:36 PM >To: Eygene Ryabinkin >Cc: freebsd-acpi@freebsd.org >Subject: Re: [PATCH] acpidump: teach to disassemble arbitrary memory >locations as AML code > >Eygene Ryabinkin wrote: >> It is not uncommon when some chunks of the AML code are loaded by DSDT >> from the memory locations that aren't part of the DSDT itself, but one >> wants to see what's inside. It can be achieved with 'dd' and 'iasl', >> but it is better to implement this machinery inside acpidump to ease the >> life of both users and develepers that needs to see the full picture >> of the ACPI stuff from foreign machines. >> >> This commit also have some small fixes: >> >> - verbose output (going to stderr) isn't mixed with normal output >> that goes to stdout -- the latter is made unbuffered; >> >> - we're using IASL's logics to get the name of the output file and, >> moreover, we prevent two simultaneous invocations of acpidump >> to hose other's output; >> >> - IASL exit code is checked and if disassembler exited abnormally >> or was failed to do its job, the warning is produced to give >> the reader an idea on what's going on. >> >> Signed-off-by: Eygene Ryabinkin > >I appreciate your work. What we need to do though is remove acpidump(8) >from the system and import Intel's acpidmp utility. It's included in the >ACPI-CA distribution and is functional enough that we can use it. > >Any functions we need that it doesn't yet have can be submitted to Intel >to merge. > >Thanks, >-- >Nate >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 12 22:34:38 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 71FD1106564A; Fri, 12 Jun 2009 22:34:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Fri, 12 Jun 2009 18:34:27 -0400 User-Agent: KMail/1.6.2 References: <4A32CA38.4020806@root.org> <4911F71203A09E4D9981D27F9D8308582E6840C8@orsmsx503.amr.corp.intel.com> In-Reply-To: <4911F71203A09E4D9981D27F9D8308582E6840C8@orsmsx503.amr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200906121834.30294.jkim@FreeBSD.org> Cc: "Moore, Robert" Subject: Re: [PATCH] acpidump: teach to disassemble arbitrary memory locations as AML code X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 22:34:38 -0000 On Friday 12 June 2009 06:02 pm, Moore, Robert wrote: > Actually, we don't distribute an acpidump (yet) in ACPICA. The > Linux version is part of the "pmtools" package. > > It is of course, linux-specific. I won't distribute it with ACPICA > until we have an OS-independent version. It is on our list of > things to-do. FYI, it won't be terribly hard to port it because we also use /dev/mem. However, the source is acpisrc'ified and we cannot undo it to make it compile on FreeBSD. :-( Jung-uk Kim > The formatting code is rather simple, but it would be best to have > one instance of the code, part of acpica. > > It would go like this: > > Get rsdt/xsdt -> call to OSL > For all tables: > Get acpi table -> call to OSL > Dump the table > > >-----Original Message----- > >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > >acpi@freebsd.org] On Behalf Of Nate Lawson > >Sent: Friday, June 12, 2009 2:36 PM > >To: Eygene Ryabinkin > >Cc: freebsd-acpi@freebsd.org > >Subject: Re: [PATCH] acpidump: teach to disassemble arbitrary > > memory locations as AML code > > > >Eygene Ryabinkin wrote: > >> It is not uncommon when some chunks of the AML code are loaded > >> by DSDT from the memory locations that aren't part of the DSDT > >> itself, but one wants to see what's inside. It can be achieved > >> with 'dd' and 'iasl', but it is better to implement this > >> machinery inside acpidump to ease the life of both users and > >> develepers that needs to see the full picture of the ACPI stuff > >> from foreign machines. > >> > >> This commit also have some small fixes: > >> > >> - verbose output (going to stderr) isn't mixed with normal > >> output that goes to stdout -- the latter is made unbuffered; > >> > >> - we're using IASL's logics to get the name of the output file > >> and, moreover, we prevent two simultaneous invocations of > >> acpidump to hose other's output; > >> > >> - IASL exit code is checked and if disassembler exited > >> abnormally or was failed to do its job, the warning is produced > >> to give the reader an idea on what's going on. > >> > >> Signed-off-by: Eygene Ryabinkin > > > >I appreciate your work. What we need to do though is remove > > acpidump(8) from the system and import Intel's acpidmp utility. > > It's included in the ACPI-CA distribution and is functional > > enough that we can use it. > > > >Any functions we need that it doesn't yet have can be submitted to > > Intel to merge. > > > >Thanks, > >-- > >Nate > >_______________________________________________ > >freebsd-acpi@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >To unsubscribe, send any mail to > > "freebsd-acpi-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to > "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 13 09:18:52 2009 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55F32106564A for ; Sat, 13 Jun 2009 09:18:52 +0000 (UTC) (envelope-from peter.piggybox@virgin.net) Received: from smtprelay-virgin.hostedemail.com (smtprelay-virgin0179.hostedemail.com [64.99.136.179]) by mx1.freebsd.org (Postfix) with ESMTP id CD02A8FC14 for ; Sat, 13 Jun 2009 09:18:51 +0000 (UTC) (envelope-from peter.piggybox@virgin.net) Received: from smtprelay-virgin.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtpgrave04.hostedemail.com (Postfix) with ESMTP id 6A581898ACB for ; Sat, 13 Jun 2009 09:01:42 +0000 (UTC) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay06.hostedemail.com (Postfix) with SMTP id 0524F1C6C3FF for ; Sat, 13 Jun 2009 09:01:41 +0000 (UTC) X-Spam-Summary: 11, 1.093, 0, 75996753de0b98d9, bac5299263adec61, peter.piggybox@virgin.net, acpi@freebsd.org, RULES_HIT:1:125:355:379:601:617:945:946:960:966:968:973:988:989:1260:1261:1277:1312:1313:1314:1345:1431:1437:1516:1518:1519:1593:1594:1595:1596:1605:1730:1747:1766:1792:1981:2194:2196:2199:2200:2378:2393:2538:2539:2540:2553:2559:2562:2636:2693:2861:2901:3636:3743:3865:3866:3867:3868:3869:3870:3871:3872:3874:3876:3877:3961:4250:4321:4384:4385:4395:5007:6114:6119:6236:6261:7809:7875:7903:7974:8501:8603:8957:9038:9040:9149:9160:9165, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Filterd-Recvd-Size: 11538 Received: from ideapad.piggybox (client-81-105-212-191.mcr-bng-011.adsl.virginmedia.net [81.105.212.191]) by omf09.hostedemail.com (Postfix) with ESMTP for ; Sat, 13 Jun 2009 09:01:39 +0000 (UTC) Received: from ideapad.piggybox (localhost [127.0.0.1]) by ideapad.piggybox (8.14.3/8.14.3) with ESMTP id n5D80d2N001994 for ; Sat, 13 Jun 2009 09:00:39 +0100 (BST) (envelope-from peter@ideapad.piggybox) Received: (from peter@localhost) by ideapad.piggybox (8.14.3/8.14.3/Submit) id n5D80daf001993 for acpi@freebsd.org; Sat, 13 Jun 2009 09:00:39 +0100 (BST) (envelope-from peter) Date: Sat, 13 Jun 2009 09:00:39 +0100 From: Peter Harrison To: acpi@freebsd.org Message-ID: <20090613080039.GA1934@ideapad.piggybox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: ACPI problems with lenovo s10e X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 09:18:52 -0000 I'm having some acpi problems with a lenovo s10e netbook. The machine boots and runs basically OK, but it doesn't poweroff on shutdown -p and it seems to have a problem querying the battery's status. It will sometimes continually spam this to /var/log/messages: 175a176,212 > acpi_ec0: wait timed out (no response), forcing polled mode > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.BAT0.UPBS] (Node 0xc45bfac0), AE_NO_HARDWARE_RESPONSE over and over again. It doesn't happen on every boot, but on some it's so bad that the system will become sporadically unresponsive for a second or two at a time throughout use. I've been scanning through the acpi man page and wondered whether turning off part of the acpi system would help - if so which bit? Would upgrading to CURRENT help? Any thoughts or help really appreciated. Please cc me as I'm not subscribed. Thanks, Peter Harrison. This is on: FreeBSD ideapad.piggybox 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 and here's a dmesg from a 'good' boot: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d> AMD Features=0x100000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 1064108032 (1014 MB) avail memory = 1023393792 (975 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xf0500000-0xf057ffff,0xd0000000-0xdfffffff,0xf0600000-0xf063ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xf0580000-0xf05fffff at device 2.1 on pci0 hdac0: mem 0xf0640000-0xf0643fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 bge0: mem 0xf0200000-0xf020ffff irq 16 at device 0.0 on pci2 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bge0: Ethernet address: 00:23:8b:34:79:8a bge0: [ITHREAD] pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 pcib3: irq 18 at device 28.2 on pci0 pci5: on pcib3 ndis0: mem 0xf0400000-0xf0403fff irq 18 at device 0.0 on pci5 ndis0: [ITHREAD] ndis0: NDIS API version: 5.1 ndis0: WARNING: using obsoleted if_watchdog interface ndis0: Ethernet address: 00:23:4e:93:a4:de uhci0: port 0x1820-0x183f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xf0844000-0xf08443ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered ugen0: on uhub4 umass0: on uhub4 pcib4: at device 30.0 on pci0 pci6: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x18c8-0x18cf,0x18c0-0x18c3,0x18a8-0x18af,0x180c-0x180f,0x18b0-0x18bf mem 0xf0844400-0xf08447ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI called from vendor specific driver atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: port not implemented ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xdf000-0xdf7ff,0xe0000-0xe17ff pnpid ORM0000 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen1: on uhub1 Timecounters tick every 1.000 msec ad4: 76319MB at ata2-master SATA150 hdac0: HDA Codec #0: Realtek ALC269 pcm0: at cad 0 nid 1 on hdac0 GEOM_LABEL: Label for provider ad4s1a is ufsid/4a20f9c76d1ce80d. GEOM_LABEL: Label for provider ad4s1d is ufsid/4a20f9cb4eb76445. GEOM_LABEL: Label for provider ad4s1e is ufsid/4a20f9c7c991bdb8. GEOM_LABEL: Label for provider ad4s1f is ufsid/4a20f9c769a0ccbb. (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s1a GEOM_LABEL: Label ufsid/4a20f9c76d1ce80d removed. GEOM_LABEL: Label for provider ad4s1a is ufsid/4a20f9c76d1ce80d. GEOM_LABEL: Label ufsid/4a20f9c7c991bdb8 removed. GEOM_LABEL: Label for provider ad4s1e is ufsid/4a20f9c7c991bdb8. GEOM_LABEL: Label ufsid/4a20f9c769a0ccbb removed. GEOM_LABEL: Label for provider ad4s1f is ufsid/4a20f9c769a0ccbb. GEOM_LABEL: Label ufsid/4a20f9cb4eb76445 removed. GEOM_LABEL: Label for provider ad4s1d is ufsid/4a20f9cb4eb76445. GEOM_LABEL: Label ufsid/4a20f9c76d1ce80d removed. GEOM_LABEL: Label ufsid/4a20f9c7c991bdb8 removed. GEOM_LABEL: Label ufsid/4a20f9c769a0ccbb removed. GEOM_LABEL: Label ufsid/4a20f9cb4eb76445 removed. drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 13 15:14:21 2009 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2155B1065689 for ; Sat, 13 Jun 2009 15:14:21 +0000 (UTC) (envelope-from peter.piggybox@virgin.net) Received: from smtprelay-virgin.hostedemail.com (smtprelay-virgin0168.hostedemail.com [64.99.136.168]) by mx1.freebsd.org (Postfix) with ESMTP id C59258FC17 for ; Sat, 13 Jun 2009 15:14:20 +0000 (UTC) (envelope-from peter.piggybox@virgin.net) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay06.hostedemail.com (Postfix) with SMTP id D10371C6C3FB; Sat, 13 Jun 2009 15:14:19 +0000 (UTC) X-Spam-Summary: 11, 1.093, 0, 2081c2646eedc93a, bac5299263adec61, peter.piggybox@virgin.net, niktychina@gmail.com:peter.piggybox@virgin.net:acpi@freebsd.org, RULES_HIT:1:125:355:379:599:601:617:945:946:960:966:967:968:973:980:988:989:1260:1261:1277:1312:1313:1314:1345:1359:1431:1437:1516:1518:1519:1593:1594:1595:1596:1605:1730:1747:1766:1792:1981:2194:2196:2199:2200:2378:2393:2525:2538:2539:2551:2553:2559:2563:2638:2682:2685:2693:2857:2859:2861:2901:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3318:3622:3743:3865:3866:3867:3868:3869:3870:3871:3872:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:3961:4250:4321:4362:4384:4385:4395:4605:4860:5007:6114:6119:6236:6261:7679:7809:7875:7903:7974:8501:8603:8784:8957:9010:9025:9038:9040:9149:9160:9165:9388, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Filterd-Recvd-Size: 13318 Received: from ideapad.piggybox (client-81-105-209-21.mcr-bng-011.adsl.virginmedia.net [81.105.209.21]) by omf09.hostedemail.com (Postfix) with ESMTP; Sat, 13 Jun 2009 15:14:18 +0000 (UTC) Received: from ideapad.piggybox (localhost [127.0.0.1]) by ideapad.piggybox (8.14.3/8.14.3) with ESMTP id n5DEDJGr001095; Sat, 13 Jun 2009 15:13:19 +0100 (BST) (envelope-from peter@ideapad.piggybox) Received: (from peter@localhost) by ideapad.piggybox (8.14.3/8.14.3/Submit) id n5DEDJqh001094; Sat, 13 Jun 2009 15:13:19 +0100 (BST) (envelope-from peter) Date: Sat, 13 Jun 2009 15:13:18 +0100 From: Peter Harrison To: Nikolay Tychina Message-ID: <20090613141318.GA1090@ideapad.piggybox> References: <20090613080039.GA1934@ideapad.piggybox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: , acpi@freebsd.org, Peter Harrison Subject: Re: ACPI problems with lenovo s10e X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 15:14:21 -0000 Saturday, 13 June 2009 at 17:38:16 +0400, Nikolay Tychina said: > try to disable "ec" Do I do that with debug.acpi.disable=ec in loader.conf? What functionality will I lose by setting that? Thanks for your help. Peter Harrison. > > > 2009/6/13 Peter Harrison > > > I'm having some acpi problems with a lenovo s10e netbook. > > > > The machine boots and runs basically OK, but it doesn't poweroff on > > shutdown -p and it seems to have a problem querying the battery's status. It > > will sometimes continually spam this to /var/log/messages: > > > > 175a176,212 > > > acpi_ec0: wait timed out (no response), forcing polled mode > > > acpi_ec0: EcRead: failed waiting to get data > > > ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by > > Handler for [EmbeddedControl] [20070320] > > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_SB_.BAT0.UPBS] (Node 0xc45bfac0), AE_NO_HARDWARE_RESPONSE > > > > over and over again. > > > > It doesn't happen on every boot, but on some it's so bad that the system > > will become sporadically unresponsive for a second or two at a time > > throughout use. > > > > I've been scanning through the acpi man page and wondered whether turning > > off part of the acpi system would help - if so which bit? Would upgrading to > > CURRENT help? Any thoughts or help really appreciated. > > > > Please cc me as I'm not subscribed. Thanks, > > > > > > Peter Harrison. > > > > > > > > This is on: > > > > FreeBSD ideapad.piggybox 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 > > 08:49:13 UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > > i386 > > > > and here's a dmesg from a 'good' boot: > > > > Copyright (c) 1992-2009 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 > > root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.01-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0x106c2 Stepping = 2 > > > > Features=0xbfe9fbff > > Features2=0x40c39d> > > AMD Features=0x100000 > > AMD Features2=0x1 > > Logical CPUs per core: 2 > > real memory = 1064108032 (1014 MB) > > avail memory = 1023393792 (975 MB) > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP/HT): APIC ID: 1 > > ioapic0: Changing APIC ID to 1 > > ioapic0 irqs 0-23 on motherboard > > kbd1 at kbdmux0 > > acpi0: on motherboard > > acpi0: [ITHREAD] > > acpi0: Power Button (fixed) > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > > acpi_ec0: port 0x62,0x66 on acpi0 > > acpi_button0: on acpi0 > > acpi_button1: on acpi0 > > acpi_acad0: on acpi0 > > battery0: on acpi0 > > acpi_lid0: on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > vgapci0: port 0x1800-0x1807 mem > > 0xf0500000-0xf057ffff,0xd0000000-0xdfffffff,0xf0600000-0xf063ffff irq 16 at > > device 2.0 on pci0 > > agp0: on vgapci0 > > agp0: detected 7932k stolen memory > > agp0: aperture size is 256M > > vgapci1: mem 0xf0580000-0xf05fffff at device 2.1 > > on pci0 > > hdac0: mem > > 0xf0640000-0xf0643fff irq 22 at device 27.0 on pci0 > > hdac0: HDA Driver Revision: 20090329_0131 > > hdac0: [ITHREAD] > > pcib1: irq 17 at device 28.0 on pci0 > > pci2: on pcib1 > > bge0: mem 0xf0200000-0xf020ffff irq > > 16 at device 0.0 on pci2 > > miibus0: on bge0 > > brgphy0: PHY 1 on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > bge0: Ethernet address: 00:23:8b:34:79:8a > > bge0: [ITHREAD] > > pcib2: irq 16 at device 28.1 on pci0 > > pci3: on pcib2 > > pcib3: irq 18 at device 28.2 on pci0 > > pci5: on pcib3 > > ndis0: mem 0xf0400000-0xf0403fff irq 18 > > at device 0.0 on pci5 > > ndis0: [ITHREAD] > > ndis0: NDIS API version: 5.1 > > ndis0: WARNING: using obsoleted if_watchdog interface > > ndis0: Ethernet address: 00:23:4e:93:a4:de > > uhci0: port 0x1820-0x183f irq 23 at device > > 29.0 on pci0 > > uhci0: [GIANT-LOCKED] > > uhci0: [ITHREAD] > > usb0: on uhci0 > > usb0: USB revision 1.0 > > uhub0: on usb0 > > uhub0: 2 ports with 2 removable, self powered > > uhci1: port 0x1840-0x185f irq 19 at device > > 29.1 on pci0 > > uhci1: [GIANT-LOCKED] > > uhci1: [ITHREAD] > > usb1: on uhci1 > > usb1: USB revision 1.0 > > uhub1: on usb1 > > uhub1: 2 ports with 2 removable, self powered > > uhci2: port 0x1860-0x187f irq 18 at device > > 29.2 on pci0 > > uhci2: [GIANT-LOCKED] > > uhci2: [ITHREAD] > > usb2: on uhci2 > > usb2: USB revision 1.0 > > uhub2: on usb2 > > uhub2: 2 ports with 2 removable, self powered > > uhci3: port 0x1880-0x189f irq 16 at device > > 29.3 on pci0 > > uhci3: [GIANT-LOCKED] > > uhci3: [ITHREAD] > > usb3: on uhci3 > > usb3: USB revision 1.0 > > uhub3: on usb3 > > uhub3: 2 ports with 2 removable, self powered > > ehci0: mem > > 0xf0844000-0xf08443ff irq 23 at device 29.7 on pci0 > > ehci0: [GIANT-LOCKED] > > ehci0: [ITHREAD] > > usb4: EHCI version 1.0 > > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > > usb4: on ehci0 > > usb4: USB revision 2.0 > > uhub4: on usb4 > > uhub4: 8 ports with 8 removable, self powered > > ugen0: > addr 2> on uhub4 > > umass0: on uhub4 > > pcib4: at device 30.0 on pci0 > > pci6: on pcib4 > > isab0: at device 31.0 on pci0 > > isa0: on isab0 > > atapci0: port > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 > > ata0: on atapci0 > > ata0: [ITHREAD] > > atapci1: port > > 0x18c8-0x18cf,0x18c0-0x18c3,0x18a8-0x18af,0x180c-0x180f,0x18b0-0x18bf mem > > 0xf0844400-0xf08447ff irq 19 at device 31.2 on pci0 > > atapci1: [ITHREAD] > > atapci1: AHCI called from vendor specific driver > > atapci1: AHCI Version 01.10 controller with 4 ports detected > > ata2: on atapci1 > > ata2: [ITHREAD] > > ata3: on atapci1 > > ata3: port not implemented > > ata3: [ITHREAD] > > ata4: on atapci1 > > ata4: [ITHREAD] > > ata5: on atapci1 > > ata5: port not implemented > > ata5: [ITHREAD] > > pci0: at device 31.3 (no driver attached) > > acpi_tz0: on acpi0 > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > atkbd0: irq 1 on atkbdc0 > > kbd0 at atkbd0 > > atkbd0: [GIANT-LOCKED] > > atkbd0: [ITHREAD] > > psm0: irq 12 on atkbdc0 > > psm0: [GIANT-LOCKED] > > psm0: [ITHREAD] > > psm0: model Generic PS/2 mouse, device ID 0 > > cpu0: on acpi0 > > est0: on cpu0 > > p4tcc0: on cpu0 > > cpu1: on acpi0 > > est1: on cpu1 > > p4tcc1: on cpu1 > > pmtimer0 on isa0 > > orm0: at iomem 0xdf000-0xdf7ff,0xe0000-0xe17ff pnpid > > ORM0000 on isa0 > > ppc0: parallel port not found. > > sc0: at flags 0x100 on isa0 > > sc0: VGA <16 virtual consoles, flags=0x300> > > sio0: configured irq 4 not in bitmap of probed irqs 0 > > sio0: port may not be enabled > > sio0: configured irq 4 not in bitmap of probed irqs 0 > > sio0: port may not be enabled > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > > sio0: type 8250 or not responding > > sio0: [FILTER] > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > sio1: port may not be enabled > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > ugen1: > addr 2> on uhub1 > > Timecounters tick every 1.000 msec > > ad4: 76319MB at ata2-master SATA150 > > hdac0: HDA Codec #0: Realtek ALC269 > > pcm0: at cad 0 nid 1 on hdac0 > > GEOM_LABEL: Label for provider ad4s1a is ufsid/4a20f9c76d1ce80d. > > GEOM_LABEL: Label for provider ad4s1d is ufsid/4a20f9cb4eb76445. > > GEOM_LABEL: Label for provider ad4s1e is ufsid/4a20f9c7c991bdb8. > > GEOM_LABEL: Label for provider ad4s1f is ufsid/4a20f9c769a0ccbb. > > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > > (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 > > (probe0:umass-sim0:0:0:0): Medium not present > > (probe0:umass-sim0:0:0:0): Unretryable error > > SMP: AP CPU #1 Launched! > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-0 device > > da0: 40.000MB/s transfers > > da0: Attempt to query device size failed: NOT READY, Medium not present > > Trying to mount root from ufs:/dev/ad4s1a > > GEOM_LABEL: Label ufsid/4a20f9c76d1ce80d removed. > > GEOM_LABEL: Label for provider ad4s1a is ufsid/4a20f9c76d1ce80d. > > GEOM_LABEL: Label ufsid/4a20f9c7c991bdb8 removed. > > GEOM_LABEL: Label for provider ad4s1e is ufsid/4a20f9c7c991bdb8. > > GEOM_LABEL: Label ufsid/4a20f9c769a0ccbb removed. > > GEOM_LABEL: Label for provider ad4s1f is ufsid/4a20f9c769a0ccbb. > > GEOM_LABEL: Label ufsid/4a20f9cb4eb76445 removed. > > GEOM_LABEL: Label for provider ad4s1d is ufsid/4a20f9cb4eb76445. > > GEOM_LABEL: Label ufsid/4a20f9c76d1ce80d removed. > > GEOM_LABEL: Label ufsid/4a20f9c7c991bdb8 removed. > > GEOM_LABEL: Label ufsid/4a20f9c769a0ccbb removed. > > GEOM_LABEL: Label ufsid/4a20f9cb4eb76445 removed. > > drm0: on vgapci0 > > vgapci0: child drm0 requested pci_enable_busmaster > > info: [drm] AGP at 0xd0000000 256MB > > info: [drm] Initialized i915 1.6.0 20080730 > > drm0: [ITHREAD] > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > >