On Fri, Apr 18, 2014 at 09:53:19AM +0800, Lv Zheng wrote: > Note that this patch is only used for stable kernels, upstream kernels > will have this problem fixed in ACPICA 201303-04 release. So upstream > kernels shouldn't merge this commit. What kernel commit fixed this issue in "upstream"? > It is reported that there are buggy BIOSes in the world: AMI uses a XSDt > compiler for early BIOSes, this compiler will generate XSDT with a NULL > entry. The affected BIOS versions are "AMI BIOS F2-F4". > > Original solution on Linux is to use an alternative heathy root table > instead of the ill one. This commit is refined by the following ACPICA > commit that tries to reduce the source code differences between Linux and > ACPICA upstream. > Commit: 671cc68dc61f029d44b43a681356078e02d8dab8 > Subject: ACPICA: Back port and refine validation of the XSDT root table. > But according to the bug report, the XSDT in fact is not broken, we should > just add NULL entry sanity check before installing a table address from > XSDT. > > With the NULL entry sanity check implemented, the XSDT validation is > useless because: > 1. If XSDT contains NULL entries, it can be bypassed by the new sanity > check mechanism; > 2. If RSDP contains a bad XSDT address, invoking XSDT validation will still > lead to kernel crash. > > This patch deletes XSDT validation logics and adds code to skip NULL > entries that can be found in RSDT or XSDT. Lv Zheng. > > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911 > Buglink: https://bugs.archlinux.org/task/39811 > Signed-off-by: Lv Zheng <lv.zheng@xxxxxxxxx> > Reported-and-tested-by: Bruce Chiarelli <mano155@xxxxxxxxx> > Reported-and-tested-by: Spyros Stathopoulos <spystath@xxxxxxxxx> > Cc: Zhao Yakui <yakui.zhao@xxxxxxxxx> > Cc: <stable@xxxxxxxxxxxxxxx> # 3.14.x: 671cc68: ACPICA: Back port and refine validation of the XSDT root table. So this fix is only needed for 3.14? Or older? I'm confused here... greg k-h -- 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
