Why is the XSDT at a suspicious address?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
catOS
Member
Member
Posts: 28
Joined: Tue Mar 31, 2020 6:28 pm

Why is the XSDT at a suspicious address?

Post by catOS »

Hello!

I'm currently working on my operating system, and I've encountered an issue with ACPI.

Currently, I have successfully read the RSDP and am now in the process of reading the RSDT and XSDT. However, when I test my code on real hardware, I come across the following:

Code: Select all

DEBUG Memory regions:
DEBUG Bootloader Reclaimable 0x1000 (253952)
DEBUG Usable                 0x3f000 (385024)
DEBUG Reserved               0x9d800 (10240)
DEBUG Reserved               0xe0000 (131072)
DEBUG Usable                 0x100000 (3132174336)
DEBUG ACPI NVS               0xbac13000 (28672)
DEBUG Usable                 0xbac1a000 (4509696)
DEBUG Reserved               0xbb067000 (4796416)
DEBUG Usable                 0xbb4fa000 (280805376)
DEBUG Bootloader Reclaimable 0xcc0c6000 (196608)
DEBUG Kernel and Modules     0xcc0f6000 (118784)
DEBUG Bootloader Reclaimable 0xcc113000 (8372224)
DEBUG Reserved               0xcc90f000 (565248)
DEBUG ACPI Reclaimable       0xcc999000 (401408)
DEBUG ACPI NVS               0xcc9fb000 (13705216)
DEBUG Reserved               0xcd70d000 (9379840)
DEBUG Bootloader Reclaimable 0xcdfff000 (4096)
DEBUG Reserved               0xcf000000 (270532608) 
DEBUG Framebuffer            0xe0000000 (7056000)
DEBUG Reserved               0xf8000080 (67108864) 
DEBUG Reserved               0xfec00000 (4096) 
DEBUG Reserved               0xfed00000 (16384)
DEBUG Reserved               0xfed1c000 (16384)
DEBUG Reserved               0xfee00000 (4096)
DEBUG Reserved               0xff000000 (16777216) 
DEBUG Usable                 0x100000000 (4812963840)
DEBUG Storing memory bitmap at 0xffff00000003f000 (271.4KiB)
INFO  Initiating virtual memory (this may take a second)
INFO  Total virtual address space: 256TiB
INFO  Usable memory: 7.7GiB 
      Used memory: 16.3MiB (0% used)
      Reserved memory: 381MiB
DEBUG struct acpi_rsd_ptr {
          signature: "RSD PTR "
          checksum: 190
          oem_id: "LENOVO"
          revision: 2
          rsdt_addr: 0xcc9ac028
      }
DEBUG struct acpi_rsd_ptr.ext {
          length: 36
          xsdt_addr: 0x2600000000
          xchecksum: 0
      }
PANIC acpi: invalid XSDT @ NULL (NULL because the address is rejected by physical_to_io for being >4GiB)
The RSDT address looks fine. The revision number is 2, so the XSDT should also be fine to use. However 0x2600000000 is a suspiciously large address and does not appear anywhere in the memory map provided by limine.

To ensure I haven't missed anything, I have double-checked the struct definition for the RSDP, and it matches the one provided on the OSDev Wiki page: https://wiki.osdev.org/RSDP


If there's any additional information I can provide to assist in troubleshooting, please let me know :D.
Visit ackOS's GitHub page:
>> https://github.com/ackOS-project/ackOS <<
Octocontrabass
Member
Member
Posts: 5560
Joined: Mon Mar 25, 2013 7:01 pm

Re: Why is the XSDT at a suspicious address?

Post by Octocontrabass »

The inner struct is not packed.

Why are you nesting those values inside another struct in the first place?
User avatar
catOS
Member
Member
Posts: 28
Joined: Tue Mar 31, 2020 6:28 pm

Re: Why is the XSDT at a suspicious address?

Post by catOS »

Ohh, I assumed that the packed attribute would apply to the inner struct #-o.

lol, me trying to be smart by using nested structures

Anyway thank you for spotting this. It works as intended now. I'll try not to ask dumb questions like this in the future.
Visit ackOS's GitHub page:
>> https://github.com/ackOS-project/ackOS <<
sounds
Member
Member
Posts: 112
Joined: Sat Feb 04, 2012 5:03 pm

Re: Why is the XSDT at a suspicious address?

Post by sounds »

Just a footnote: it's not a dumb question. If you can make this mistake, so can I. So it's a reminder to me not to do this! :roll:
Post Reply