From owner-acpi-jp@jp.FreeBSD.org Thu Sep 26 12:20:51 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g8Q3Kpk64191;
	Thu, 26 Sep 2002 12:20:51 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g8Q3Kp364186
	for <acpi-jp@jp.FreeBSD.org>; Thu, 26 Sep 2002 12:20:51 +0900 (JST)
	(envelope-from takawata@axe-inc.co.jp)
Received: from axe-inc.co.jp ([192.47.224.47])
	by axe-inc.co.jp (8.9.3+3.2W/3.7W) with ESMTP id MAA08698
	for <acpi-jp@jp.FreeBSD.org>; Thu, 26 Sep 2002 12:20:49 +0900 (JST)
Message-Id: <200209260320.MAA08698@axe-inc.co.jp>
To: acpi-jp@jp.FreeBSD.org
In-reply-to: Your message of "Wed, 25 Sep 2002 15:02:24 MST."
             <20020925150224.A50756@FreeBSD.org>
From: User Takawata <takawata@axe-inc.co.jp>
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Thu, 26 Sep 2002 12:29:54 +0900
X-Sequence: acpi-jp 1851
Subject: [acpi-jp 1851] Re: Toshiba Satellite with strange ACPI
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: takawata@axe-inc.co.jp
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+020902

In message <20020925150224.A50756@FreeBSD.org>, Juli Mallett wrote:
>How exactly do I get binary dumps of both of these?  I'll be more than glad to
>.
>
>Thanks,
>juli.

>* De: "Moore, Robert" <robert.moore@intel.com> [ Data: 2002-09-25 ]
>	[ Subjecte: RE: [acpi-jp 1848] RE: Toshiba Satellite with strange ACPI 
>]
>> 
>> We'll need the FADT also, of course.
....
>> Bob
>> Intel folks: according to the acpidump it seems that she doesn't have
>> any GPE1 block at all.  Looking at evevent.c, it seems that when setting
>> up Gpe initialize the code doesn't check to see if GPE1LEN and GPE1BLK
>> are zero to see if it has a GPE1 block.  Looking at the logs, it looks
>> like it did check LEN and BLK at some point.  According to the text of
>> the specification quoted in the comment above the code it seems that
>> you should be checking to see if BLK and LEN in the FADT are zero for
>> each GPE block before doing anything else.

There is no tool for it. Apply following patch to acpidump source code
then get acpidump again. I'll clean up this patch and merge.

--- /usr/src/usr.sbin/acpi/acpidump/acpi.c	Tue Oct 23 02:25:25 2001
+++ acpi.c	Thu Sep 26 12:11:21 2002
@@ -118,8 +118,8 @@
 	dsdp = (struct ACPIsdt *) acpi_map_sdt(facp->dsdt_ptr);
 	if (acpi_checksum(dsdp, dsdp->len))
 		errx(1, "DSDT is corrupt\n");
-	acpi_handle_dsdt(dsdp);
 	aml_dump(dsdp);
+	acpi_handle_dsdt(dsdp);
 }
 
 static void
@@ -213,6 +213,8 @@
 acpi_print_facp(struct FACPbody *facp)
 {
 	char	sep;
+	int i;
+	char *rawdata; 
 
 	printf(BEGIN_COMMENT);
 	printf("\tDSDT=0x%x\n", facp->dsdt_ptr);
@@ -330,6 +332,24 @@
 	printf(", RsdtAddress=0x%08x\n", rp->addr);
 	printf(END_COMMENT);
 }
+static void
+acpi_hexdump_facp(struct ACPIsdt *sdp)
+{
+  int j;
+  unsigned char *rawdata;
+  
+  printf(BEGIN_COMMENT);
+  printf("HEXDUMP RSDT:\n" );
+  rawdata = (unsigned char *) sdp;
+  for(j=0; j < sdp->len; j++){
+    if((j & 0xf) == 0){
+      printf("\n%02x:", j);
+    }
+    printf("%02x ", rawdata[j]);
+  }
+  printf("\n");
+  printf(END_COMMENT);
+}
 
 void
 acpi_handle_rsdt(struct ACPIsdt *rsdp)
@@ -337,6 +357,7 @@
 	int	i;
 	int	entries;
 	struct	ACPIsdt *sdp;
+	unsigned char *rawdata;
 
 	entries = (rsdp->len - SIZEOF_SDT_HDR) / sizeof(u_int32_t);
 	acpi_print_rsdt(rsdp);
@@ -345,6 +366,7 @@
 		if (acpi_checksum(sdp, sdp->len))
 			errx(1, "RSDT entry %d is corrupt\n", i);
 		if (!memcmp(sdp->signature, "FACP", 4)) {
+		  acpi_hexdump_facp(sdp);
 			acpi_handle_facp((struct FACPbody *) sdp->body);
 		} else {
 			acpi_print_sdt(sdp);



