On Mon, Oct 31, 2011 at 4:33 AM, Thomas Renninger <trenn@xxxxxxx> wrote: > On Friday 28 October 2011 17:14:39 Bjorn Helgaas wrote: >> 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. > This also is my understanding. >> So I don't understand how you can derive bit_width from access_width. > The problem is that Windows seem to ignore the bit width field, at least > for APEI tables. > There you also have the mask value and bit width information is not > needed to determine the bits of interest. > While mostly bit width information is correct, I compared quite some > tables and especially IBM is adding some interesting values. > But I've also seen wrong bit widths on Supermicro and others. > > >> 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. > Yep. But "Get Error Address Range" is supposed to return/contain an iomem address. > Cutting it down to 8 bits produces below error when trying to > reserve a memory region from the retrieved value/address at 0x3f. > Using acpidump to evaluate the register's 8 byte shows: > acpidump --addr 0x7F8A8032 --length 8 > 0x000000007f8a803f > which perfectly fits into an unused e820 reserved memory region. > > Same for "Get Error Address Length" on this machine: > [1D0h 0464 1] Action : 0E (Get Error Address Length) > [1D5h 0469 1] Bit Width : 08 > [1D7h 0471 1] Encoded Access Width : 03 (DWord Access:32) > [1D8h 0472 8] Address : 000000007F8A803A > [1E8h 0488 8] Mask : 00000000FFFFFFFF > > Reading 0x7F8A803A you get: > 0x2000 > which is exactly what you expect as "error memory length", but cut > down to 8 bits it's wrong. > Look at the mask value from which you could derive bit width (on APEI tables > only), it should be 0x16, but it's not needed (bit width info) and should > get ignored because it's sometimes wrong. > > The question remains whether Windows (which versions?) is only ignoring bit > width in their APEI implementation (this is what I currently expect). > For now, as we have separate APEI GAR checking it should be fine to > only ignore bit width there. But keeping an eye open and check > other ACPI tables containing GAR structures out there in the field > is certainly a good idea. Seems like these are BIOS bugs. Do we know for sure that Windows consumes this information that seems to be wrong? Have you had a conversation with the vendor about whether the BIOS is at fault here? If we make Linux ignore the bit_width, that might "fix" these boxes with broken BIOSes, but at the cost of breaking a box that uses bit_width correctly. 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
