Jürgen Keil wrote: >>>On as ASUS A7V, a resp->Id ACPI_RSTYPE_IRQ (0) entry is found, it has >>>a resp->Length of 0x44 bytes. But the size of the array elements >>>(sizeof ACPI_RESOURCE) is 0x5c. >>> >>>Doesn't the second entry start at offset 0x44 from the kmem_zalloc'ed >>>buffer, after the assignment "*srsp = *resp;" (because the actual resource >>>data doesn't use the full structure's size) ? >> >>Yup. I believe I'm guilty as charged. The reason this doesn't >>blow up, and probably won't ever blow up, is that this code is >>only used to set the IRQ for a PCI IRQ link device. The _SRS >>method for a PCI IRQ link device is only going to use the first >>item in the resource byte stream (constructed from the ACPI_RESOURCE >>structures). > > > acpica seems to expect the ACPI_RSTYPE_END_TAG item after the > IRQ item. IIRC, in one kmdb debug session, I zeroed out the second item's > ->Id and ->Length field and I was getting an endless loop inside acpica > (acpica tried to skip to the next item, and was advancing a buffer pointer > by ->Length bytes, making no progress, and was stuck on the second item)
Right; I've convinced myself that I was trying to do the wrong thing in the first place, but doing it wrongly, which has the side-effect of making it work (since the ACPI_RESOURCE following the IRQ resource is always an end tag in practice). I wrote that code a long, long time ago ;-). [...] >>>Wouldn't it be better to use something like this: >>> >>> srsp = kmem_zalloc(2 * sizeof (*srsp), KM_SLEEP); >>> bcopy(resp, srsp, resp->Length); >>> ACPI_NEXT_RESOURCE(srsp)->Id = ACPI_RSTYPE_END_TAG; >>> ACPI_NEXT_RESOURCE(srsp)->Length = 0; >>> break; >> >>Yes, indeed. I'd be delighted to incorporate this contributed fix >>as a P3 bug. Sound good? > > > Yes. Great! Thanks - Dana _______________________________________________ opensolaris-code mailing list [email protected] https://opensolaris.org:444/mailman/listinfo/opensolaris-code
