From owner-acpi-jp@jp.freebsd.org  Tue Feb  6 09:46:38 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id JAA77180;
	Tue, 6 Feb 2001 09:46:38 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id JAA77175
	for <acpi-jp@jp.freebsd.org>; Tue, 6 Feb 2001 09:46:37 +0900 (JST)
	(envelope-from andrew.grover@intel.com)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id AAA08372
	for <acpi-jp@jp.freebsd.org>; Tue, 6 Feb 2001 00:47:54 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 06 Feb 2001 00:46:29 0000 (GMT)
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <1DXG5LGB>; Mon, 5 Feb 2001 16:46:28 -0800
Message-ID: <4148FEAAD879D311AC5700A0C969E8905DE649@orsmsx35.jf.intel.com>
From: "Grover, Andrew" <andrew.grover@intel.com>
To: "'acpi-jp@jp.freebsd.org'" <acpi-jp@jp.freebsd.org>
Date: Mon, 5 Feb 2001 16:46:24 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 1053
Subject: [acpi-jp 1053] Re: Some problem in resource handle part.
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: andrew.grover@intel.com

Aha, I didn't see that part! OK, thanks, will do.

-- Andy

> -----Original Message-----
> From: Takanori Watanabe
> [mailto:takawata@shidahara1.planet.sci.kobe-u.ac.jp]
> Sent: Monday, February 05, 2001 4:42 PM
> To: andrew.grover@intel.com
> Cc: acpi-jp@jp.freebsd.org
> Subject: [acpi-jp 1052] Re: Some problem in resource handle part.
> 
> 
> In message 
> <4148FEAAD879D311AC5700A0C969E8905DE643@orsmsx35.jf.intel.com>, "Gro
> ver, Andrew" $B$5$s$$$o$/(B:
> >1. OK, we will fix it.
> >2. Well, first, the spec makes it sound like all resources 
> must have an end
> >tag, so if a system doesn't then it's noncompliant. (What's 
> the point of an
> >end tag if some people don't use it?)
> 
> In the case I mentioned, EndTag exists but not located at the 
> end of buffer.
> Resource stream is smaller than the buffer reserved,like this.
> {0x22,0x0,0x10,0x79,0x0,0x0,0x0,0x0,0x0.....}
>   ^IrqTag        ^EndTag  ^----Untouched data follows.
> This case may occur the example I wrote.
> 
> >
> >Second, I think we handle this case. In 
> AcpiRsByteStreamToList() we loop,
> >consuming the resource data:
> >
> >    while (BytesParsed < ByteStreamBufferLength &&
> >            FALSE == EndTagProcessed)
> >
> >So, even with no end tag, we exit the loop at the end of the buffer.
> 
> Yes, this is correct.But I want to say is the case I mentioned above.
> To fix this,change
> in AcpiRsByteStreamToList()@rslist.c
> 
> 	if(!(ByteStreamBufferLength == ByteParsed) ||
> 		(TRUE != EndTagProcessed))
> 
> to
> 	if(TRUE != EndTagProcessed)
> 
> and 
> in AcpiRsCalculateListLength()@rscalc.c
> add 
> 	ByteStreamBufferLength = ByteParsed;
> at
>        case END_TAG:
> to stop calculation loop.
> 
> Thanks.
> 
> Takanori Watanabe
> <a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html">
> Public Key</a>
> Key fingerprint =  2C 51 E2 78 2C E1 C5 2D  0F F1 20 A3 11 3A 62 2A 
> 

