Date: Fri, 27 Jul 2001 05:25:53 -0700 From: "neckpain@nettaxi.com" <neckpain@nettaxi.com> To: msmith@freebsd.org Cc: current@freebsd.org Subject: Re: acpica malfunctions Message-ID: <200107271225.FAA09468@mail25.bigmailbox.com>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format... ------------=_996236753-9320-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary 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 ------------=_996236753-9320-0 Content-Type: application/octet-stream; name="acpi_pcib.c.diff" Content-Disposition: inline; filename="acpi_pcib.c.diff" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9kZXYvYWNwaWNhL2FjcGlfcGNpYi5jCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL2N2cy9zcmMvc3lzL2Rldi9h Y3BpY2EvYWNwaV9wY2liLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTAK ZGlmZiAtdSAtdSAtcjEuMTAgYWNwaV9wY2liLmMKLS0tIHN5cy9kZXYvYWNw aWNhL2FjcGlfcGNpYi5jCTIwMDEvMDcvMDcgMTA6MTI6MDYJMS4xMAorKysg c3lzL2Rldi9hY3BpY2EvYWNwaV9wY2liLmMJMjAwMS8wNy8yNyAwMjo0NDoz MgpAQCAtMjY5LDYgKzI2OSw0MSBAQAogICAgIHBjaV9jZmdyZWd3cml0ZShi dXMsIHNsb3QsIGZ1bmMsIHJlZywgZGF0YSwgYnl0ZXMpOwogfQogCitzdGF0 aWMgQUNQSV9TVEFUVVMKK2FjcGlfRW5sYXJnZVJlc291cmNlKEFDUElfQlVG RkVSICpidWZwLCBBQ1BJX1JFU09VUkNFICpjdXJwLCBzaXplX3Qgd2FudCkK K3sKKwlBQ1BJX1JFU09VUkNFCSp0b3A7CisJQUNQSV9SRVNPVVJDRQkqYWxs b2M7CisJc2l6ZV90CQlwOworCXNpemVfdAkJQnVmZmVyU2l6ZTsKKworCWlm IChjdXJwIDwgKHRvcCA9IGJ1ZnAtPlBvaW50ZXIpIHx8CisJICAgIFBPSU5U RVJfQUREKEFDUElfUkVTT1VSQ0UsIHRvcCwgYnVmcC0+TGVuZ3RoIC0gY3Vy cC0+TGVuZ3RoKSA8IGN1cnApCisJCXJldHVybiBBRV9CQURfUEFSQU1FVEVS OworCisJQnVmZmVyU2l6ZSA9IGJ1ZnAtPkxlbmd0aCAtIGN1cnAtPkxlbmd0 aCArIHdhbnQ7CisJaWYgKChhbGxvYyA9IEFjcGlPc0FsbG9jYXRlKEJ1ZmZl clNpemUpKSA9PSBOVUxMKQorCQlyZXR1cm4gQUVfTk9fTUVNT1JZOworCisJ cCA9IChjaGFyICopY3VycCAtIChjaGFyICopdG9wOworCW1lbWNweShhbGxv YywgdG9wLCBwKTsKKworCW1lbWNweSgoY2hhciAqKWFsbG9jICsgcCwgY3Vy cCwgd2FudCk7CisJKFBPSU5URVJfQUREKEFDUElfUkVTT1VSQ0UsIGFsbG9j LCBwKSktPkxlbmd0aCA9IHdhbnQ7CisKKwltZW1jcHkoKGNoYXIgKilhbGxv YyArIHAgKyB3YW50LCAoY2hhciAqKWN1cnAgKyBjdXJwLT5MZW5ndGgsCisJ ICAgIGJ1ZnAtPkxlbmd0aCAtIHAgLSBjdXJwLT5MZW5ndGgpOworCisJYWxs b2MtPkxlbmd0aCArPSB3YW50IC0gY3VycC0+TGVuZ3RoOworCWJ1ZnAtPkxl bmd0aCA9IEJ1ZmZlclNpemU7CisJQWNwaU9zRnJlZShidWZwLT5Qb2ludGVy KTsKKwlidWZwLT5Qb2ludGVyID0gYWxsb2M7CisKKwlyZXR1cm4gQUVfT0s7 Cit9CisKKworCiAvKgogICogUm91dGUgYW4gaW50ZXJydXB0IGZvciBhIGNo aWxkIG9mIHRoZSBicmlkZ2UuCiAgKgpAQCAtNDczLDYgKzUwOCw0MyBAQAog ICAgIGZvciAoaSA9IDA7IGkgPCBwcnNyZXMtPkRhdGEuSXJxLk51bWJlck9m SW50ZXJydXB0czsgaSsrKQogCXByaW50ZigiICAlZCIsIHByc3Jlcy0+RGF0 YS5JcnEuSW50ZXJydXB0c1tpXSk7CiAgICAgcHJpbnRmKCJcbiIpOworCisg ICAgeworCUFDUElfUkVTT1VSQ0UJKnIsICpzOworCXNpemVfdAkJbmV3c2l6 ZTsKKwlpbnQJCWksIGosIG47CisKKwkvKgorCSAqIGZpcnN0IGdyb3cgdGhl IHNpemUgb2YgSVJRIHJlc291cmNlIHNvIHdlIGhhdmUgcm9vbSBmb3IgYW4g SVJRCisJICovCisJbiA9IGNyc3Jlcy0+RGF0YS5JcnEuTnVtYmVyT2ZJbnRl cnJ1cHRzICsKKwkgICAgcHJzcmVzLT5EYXRhLklycS5OdW1iZXJPZkludGVy cnVwdHM7CisJbmV3c2l6ZSA9IChjaGFyICopJihjcnNyZXMtPkRhdGEuSXJx LkludGVycnVwdHNbMF0pIC0gKGNoYXIgKiljcnNyZXMgKworCSAgICBuICog c2l6ZW9mIChjcnNyZXMtPkRhdGEuSXJxLkludGVycnVwdHNbMF0pOworCWlm IChhY3BpX0VubGFyZ2VSZXNvdXJjZSgmY3JzYnVmLCBjcnNyZXMsIG5ld3Np emUpICE9IEFFX09LKQorCSAgICBnb3RvIG91dDsKKworCS8qIGZpeCBjcnNy ZXMgcG9pbnQgdG8gdGhlIHJlc291cmNlIGluIHRoZSBuZXdseSBhbGxvY2F0 ZWQgYnVmZmVyICovCisJYWNwaV9GaW5kSW5kZXhlZFJlc291cmNlKChBQ1BJ X1JFU09VUkNFICopY3JzYnVmLlBvaW50ZXIsCisJICAgIHBydC0+U291cmNl SW5kZXgsICZjcnNyZXMpOworCisJZm9yIChpID0gY3JzcmVzLT5EYXRhLkly cS5OdW1iZXJPZkludGVycnVwdHMsIGogPSAwOyBpIDwgbjsgKytpLCArK2op CisJICAgIGNyc3Jlcy0+RGF0YS5JcnEuSW50ZXJydXB0c1tpXSA9IHByc3Jl cy0+RGF0YS5JcnEuSW50ZXJydXB0c1tqXTsKKwljcnNyZXMtPkRhdGEuSXJx Lk51bWJlck9mSW50ZXJydXB0cyA9IG47CisKKwkvKgorCSAqIGZpbmQgdGhl IGxhc3QgZWxlbWVudChMZW5ndGggPSAwKQorCSAqIGFuZCBzZXQgSWQgdG8g QUNQSV9SU1RZUEVfRU5EX1RBRworCSAqLworCXIgPSBjcnNidWYuUG9pbnRl ciwKKwlzID0gUE9JTlRFUl9BREQoQUNQSV9SRVNPVVJDRSwgY3JzYnVmLlBv aW50ZXIsIGNyc2J1Zi5MZW5ndGgpOworCWZvciAoOyByIDwgczsgciA9IFBP SU5URVJfQUREKEFDUElfUkVTT1VSQ0UsIHIsIHItPkxlbmd0aCkpCisJICAg IGlmIChyLT5MZW5ndGggPT0gMCkgeworCQlyLT5JZCA9IEFDUElfUlNUWVBF X0VORF9UQUc7CisJCWJyZWFrOworCSAgICB9CisgICAgfQorCiAgICAgY3Jz cmVzLT5EYXRhLklycS5JbnRlcnJ1cHRzWzBdID0gcHJzcmVzLT5EYXRhLkly cS5JbnRlcnJ1cHRzWzBdOwogICAgIGNyc3Jlcy0+RGF0YS5JcnEuTnVtYmVy T2ZJbnRlcnJ1cHRzID0gMTsKICAgICBpZiAoQUNQSV9GQUlMVVJFKHN0YXR1 cyA9IEFjcGlTZXRDdXJyZW50UmVzb3VyY2VzKGxua2RldiwgJmNyc2J1Zikp KSB7Cg== ------------=_996236753-9320-0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107271225.FAA09468>