From owner-acpi-jp@jp.freebsd.org  Sun Jul 29 10:50:02 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id KAA79273;
	Sun, 29 Jul 2001 10:50:02 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from hfep01.dion.ne.jp (hfep01.dion.ne.jp [203.181.105.67])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id KAA79266
	for <acpi-jp@jp.freebsd.org>; Sun, 29 Jul 2001 10:50:01 +0900 (JST)
	(envelope-from haro@h4.dion.ne.jp)
Received: from localhost ([61.200.140.7]) by hfep01.dion.ne.jp with ESMTP
          id <20010729014958977.QGHV@hfep01.dion.ne.jp>;
          Sun, 29 Jul 2001 10:49:58 +0900
To: neckpain@nettaxi.com
Cc: msmith@freebsd.org, current@freebsd.org, acpi-jp@jp.freebsd.org
In-Reply-To: <200107271225.FAA09468@mail25.bigmailbox.com>
References: <200107271225.FAA09468@mail25.bigmailbox.com>
X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010729104940A.haro@h4.dion.ne.jp>
Date: Sun, 29 Jul 2001 10:49:40 +0900
From: Munehiro Matsuda <haro@h4.dion.ne.jp>
X-Dispatcher: imput version 20000228(IM140)
Lines: 91
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+010328
X-Sequence: acpi-jp 1200
Subject: [acpi-jp 1200] Re: acpica malfunctions
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: haro@h4.dion.ne.jp

Thank you for your patch.

Now I can boot my SONY PCG-Z505V/BP with acpi_pcib.c rev1.11 + your patch.
Here's ACPI related dmesg:

acpi0: <SONY   Z3      > on motherboard
Timecounter "ACPI"  frequency 3579545 Hz
acpi_cpu0: <CPU> on acpi0
acpi_tz0: <thermal zone> on acpi0
acpi_button0: <Power Button> on acpi0
acpi_pcib0: <Host-PCI bridge> on acpi0
pci0: <PCI bus> on acpi_pcib0
acpi_pcib0: matched entry for 0.7.INTD (source \\_SB_.LNKD)
acpi_pcib0: possible interrupts:  9
acpi_pcib0: routed interrupt 9 via \\_SB_.LNKD
acpi_pcib0: matched entry for 0.12.INTA (source \\_SB_.LNKB)
acpi_pcib0: possible interrupts:  9
acpi_pcib0: routed interrupt 9 via \\_SB_.LNKB

 Thank you,
  Haro

From: "neckpain@nettaxi.com" <neckpain@nettaxi.com>
Date: Fri, 27 Jul 2001 05:25:53 -0700
::In-Reply-To: <200107232037.f6NKbx201647@mass.dis.org>; from msmith@FreeBSD.ORG on Mon, Jul 23, 2001 at 01:37:59PM -0700
::
::On Mon, Jul 23, 2001 at 01:37:59PM -0700, Mike Smith wrote:
::> > > > 1. Acpica modules hangs in
::> > > >     AcpiRsCalculateByteStreamLength() called from
::> > > >     AcpiRsCreateByteStream() called from
::> > > >     AcpiRsSetSrsMethodData() called from
::> > > >     AcpiSetCurrentResources() from somewhere in acpi_pcib.c .
::> > > >
::> > > >     The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length 
::> > == 0
::> > > > .
::> > >
::> > > Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484?
::> > > I think I should be passing a pointer to the buffer, not a pointer to a
::> > > pointer.
::> > 
::> > There's no &crsbuf in line 484 (not in rev 1.10, nor 1.11).
::> > 
::> > Assuming you're talking about the one in line 478, it doesn't compile if you
::> > change it to crsbuf from &crsbuf, since crsbuf is an ACPI_BUFFER, not
::> > an (ACPI_BUFFER *).
::> 
::> Um.  Sorry about the line numbers, and yes, sorry about the confusion 
::> there; I just looked at it and it seemed wrong.
::> 
::> I'd still like to know the allocation length for that buffer though; my 
::> last suspicion is that it doesn't contain any resources at all, and so 
::> we're overrunning it when we go to try to stuff an interrupt resource 
::> into it.  If that's the case, it's easy to fix.  If not, then we will 
::> have to go hunting snarks.
::
::Mike,
::Seems like I managed to solve my problem. Attached is to be applied against
::sys/dev/acpica/acpi_pcib.c, rev 1.10 .
::
::First of all, the list returned in crsbuf was terminated with an element
::with its Length field equal to zero (and Id field was ACPI_RSTYPE_IRQ).
::Since AcpiRsCalculateByteStreamLength() expects ACPI_RSTYPE_END_TAG as
::terminator and doesn't check the validity of Length field (or, in other words,
::this function doesn't treat it as terminator), the function never returned.
::
::And as you suggested, AcpiGetCurrentResources() returned an IRQ resource
::with no interrupts(NumberOfInterrupts = 0, and no room for
::Data.Irq.Interrupts[0]). Thus the line 476 in acpi_pcib.c was overwriting
::the Id field in the next element.
::
::The patch tries to allocate another buffer to resize the list, and to modify the
::last element's Id to ACPI_RSTYPE_END_TAG.
::I think AcpiRsCalculateByteStreamLength() should just exit the while loop
::when it found an element with Length = 0, rather than wait for the end tag
::forever.
::
::Thanks.
::
::
::------------------------------------------------------------
::Shop Smart Compare Prices on Name-Brand Products from Name-Brand Stores!!
::http://www.smartshop.com/cgi-bin/main.cgi?ssa=4099

=------------------------------------------------------------------------------
           _ _    Munehiro (haro) Matsuda
 -|- /_\  |_|_|   Business Incubation Dept., Kubota Corp.
 /|\ |_|  |_|_|   1-3 Nihonbashi-Muromachi 3-Chome
                  Chuo-ku Tokyo 103-8310, Japan
                  Tel: +81-3-3245-3318  Fax: +81-3-3245-3315
                  Email: haro@kubota.co.jp
