Distribution: RedHat 7.1 Hardware Environment: Running in simulation (Virtutech Simics) Software Environment: Problem Description: [also posted on the acpi-devel mailing list] There seem to be a problem with the RSDP scan in at least a few different kernel versions. In the 2.6 version I looked at we have: ---- /* * Scan memory looking for the RSDP signature. First search EBDA (low * memory) paragraphs and then search upper memory (E0000-FFFFF). */ rsdp_phys = acpi_scan_rsdp (0, 0x400); if (!rsdp_phys) rsdp_phys = acpi_scan_rsdp (0xE0000, 0xFFFFF); ---- In 2.4.20 version we have: ---- /* * Physical address is given */ /* * Region 1) Search EBDA (low memory) paragraphs */ rsdp = acpi_tb_scan_memory_for_rsdp(__va(LO_RSDP_WINDOW_BASE), LO_RSDP_WINDOW_SIZE); ---- Both versions claim to check the EBDA in the comments, but if I'm not mistaken they really check the lowest part of physical memory. The location of the EBDA varies between BIOSes (the real mode segment part can be found at 40:0E). Steps to reproduce: Linux will fail to find the RSDP on any system with the RSDP in the EBDA.
I just verified it with ACPI spec, only on EISA or MCA platform ,the pointer to EBDA is stored in 40:0E.
Created attachment 2607 [details] a patch
The patch is not correct. The low part of memory (0 to 0x400) shouldn't be scanned. That's where the bios data area is, not the EBDA. Also, the pointer at 40:0e is a real mode segment, so it has to be scaled (shifted 4 bits to the left) to make a physical address. Can we be certain that the boot loader and/or linux itself hasn't clobbered either the pointer at 40:0e or the EBDA itself? Note that a similar problem exists for the MPS tables. You might want to have a look on how that is solved. I have yet to find a system that doesn't have the EBDA pointer at 40:0e. I don't know why the note saying 'for eisa or mca systems' is there in the acpi spec.
Is this failure specific to a simlated environment, or does it occur also on a real machine? thanks, -Len
It would occur on any machine with the RSDP in the EBDA. My specific case is for a simulated machine, but nothing prevents a physical machine from having the RSDP in the EBDA. Such a system would work with Windows and FreeBSD (and possibly others), but would not work with Linux. I haven't checked where typical machine keep their RSDP, but firmware vendors that test with Linux would have already worked around this bug.
Created attachment 2854 [details] proposal patch Ok, how about this patch. I'm not sure if we should delete the code of scaning low 1k, since the code works for many system. I know spec doesn't mention it, but maybe it's a workaround. Len, you should check it. For the ebda overlap, mpparse doesn't handle it as well. In addition, the code has another bug, we should scan from 0xE0000 to 0xFFFFF, so the length is not 0xFFFFF.
From the ACPI Spec: OSPM finds the Root System Description Pointer (RSDP) structure by searching physical memory ranges on 16-byte boundaries for a valid Root System Description Pointer structure signature and checksum match as follows:
Why is the code in AcpiTbFindRsdp being (apparently) duplicated? This is the kind of code that should only exist once in the system, I would think. Bob
Even 'AcpiTbFindRsdp' doesn't do the right thing, it check 0x0-0x400 instead of ebda. Right, system should have only one find rsdp code, but before calling ACPICA routines, we should do many initizlizations. But 'acpi_find_rsdp' must be invoked very earlier, I don't think there is an easy way to to this.
The design of AcpiTbFindRsdp is such that it is always available, even before ACPI init. Yes, the code is wrong, and has been since day one, it does not scan the EBDA correctly. Of course, this means that there are very few systems that have the RSDP in the EBDA... Bob
As comments #3 said, the main problem here is that we are not certain that the boot loader and/or linux itself hasn't clobbered either the pointer at 40:0e or the EBDA itself.
*** Bug 2660 has been marked as a duplicate of this bug. ***
Created attachment 2908 [details] rsdp duplicate resolve patch make acpi_find_rsdp() call ACPICA function acpi_os_get_root_pointer()
ACPICA 20040527 was merged to linux-acpi-test-2.6.7, which includes the fix for acpi_tb_find_rsdp() from the ACPICA side for this bug. I think now we can use method acpi_find_root_pointer() from ACPICA to look up RSDP instead of inventing our own (acpi_scan_rsdp) like Zhenyu's patch (attachment 2908 [details]). One problem with this patch is > acpi_find_rsdp (void) > ... > + result = acpi_os_get_root_pointer (ACPI_PHYSICAL_ADDRESSING,&rsdp_address); > + if (ACPI_FAILURE(result)){ > + return result; since result is > 0 value, it will confuse caller functions. Suggest to change like this if (ACPI_FAILURE(result)){ return 0; Zhenyu, could you create the patch against the latest linux-acpi-test tree? Len, would you consider to apply? Thanks, -yi
Zhenyu is working on removing the duplicate code in rsdp scan. Reassign to him.
it still depends on .config, i recall Len'd like to remove CONFIG_ACPI_BOOT, if that dependence dropped, we can tweak rsdp scan code as exist patch.
*** Bug 3297 has been marked as a duplicate of this bug. ***
Created attachment 4074 [details] updated patch this patch only touch ia32 case (also x86_64). As on ia64, efi.acpi20 is used, so i don't want to bother that. tested on my dell, enable ACPI interpreter or just enable ACPI_BOOT without other ACPI part, both build and boot fine.
Created attachment 4075 [details] an acpi_find_rsdp customer fix for Unisys ES7000
The existing code for RSDP scanning in ACPI CA already handles the case where an RSDP is found with a bad checksum. We need to migrate Linux to use this code. This is a case of reinventing the wheel but not fully inflating the new tire. AcpiTbScanMemoryForRsdp ( /* The signature and checksum must both be correct */ /* If so, we have found the RSDP */
yep, we can still fix that in acpi_scan_rsdp() for ACPI_BOOT only.
Created attachment 4082 [details] update patch for handle rsdp with bad checksum
What is the status of this issue in kernel 2.6.16.5?
Wow, this really has a long history. What's the status of this bug? Is it fixed already?
code is still there, only one version left. But we don't have equipment to test this on.
Then why not reopen this bug when it can be reproduced.
(In reply to comment #24) > Wow, this really has a long history. > What's the status of this bug? > Is it fixed already? I just tested this with the kubuntu-7.04 desktop i386 cd. The bug is still there. The tested kernel is 2.6.20-15-generic.
Please test generic 2.6.22. Ubuntu adds too much code to ACPI to say something certain about ACPI state. Also, the changes we speek about went into .21 kernel.
(In reply to comment #28) > Please test generic 2.6.22. Ubuntu adds too much code to ACPI to say > something > certain about ACPI state. Also, the changes we speek about went into .21 > kernel. Could you point me to a bootable image with such a kernel?
Alpha version of suse 10.3 has it, probably some other not-yet-released distro goes with .22
please re-open if this problem still exists in kernel.org 2.6.22