On Thu, Oct 27, 2011 at 7:49 PM, Thomas Renninger <trenn@xxxxxxx> wrote: > There is another problem. Would be great to get some opinions/feedback > on it already: > APEI GAR entries seem to have invalid bit_width entries on some platforms. > After looking at several tables, I expect that with APEI tables access width > (in bytes) should get used instead, Windows seem to ignore bit width fields, > at least for APEI tables. I'm confused. How can you tell that the bit_width is incorrect? My understanding is that the bit_width is the size of the *register*, while the access_width is the size of access the processor must generate on the bus. The access_width may be larger, for example, if the hardware only supports 32-bit or 64-bit reads. So I don't understand how you can derive bit_width from access_width. In the example below, I think we're supposed to do a 64-bit read, then extract 8 bits that contain the register of interest. If we keep all 64 bits, I don't see how that can be correct. > ... > Comparing different Generic Adress Register definitions of > different vendors it came out that bit width (at least in APEI > tables) is sometimes wrong or used different compared to older > ACPI BIOS definitions (e.g. older FACP tables). > It looks like Windows ignores the bit width field in > latest implementations. Either in APEI table parts only > (I'd say more likely) or in other ACPI parts as well. > > Worst case is that an address value to be read from a GAR structure > can have a 8 bit width definition resulting in: > ERST: Can not request iomem region <0x 3f-0x 3f> > while the access width is correct: > [1B0h 0432 1] Action : 0D (Get Error Address Range) > [1B4h 0436 12] Register Region : <Generic Address Structure> > [1B4h 0436 1] Space ID : 00 (SystemMemory) > [1B5h 0437 1] Bit Width : 08 > [1B6h 0438 1] Bit Offset : 00 > [1B7h 0439 1] Encoded Access Width : 04 (QWord Access:64) > [1B8h 0440 8] Address : 000000007F8A8032 Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
