Scott D. Davilla
2007-10-22 16:05:11 UTC
I've been debugging strange hangs with linux on the AppleTV (2.6.21
kernel). I believe I've tracked down a possible memory map problem
between ACPI derived memory map and the EFI memory map.
Here's the indicators from dmesg (from
http://www.mactel-linux.org/wiki/Dmesg_appletv);
EFI: ioremap of 0xB178000 failed
EFI: ioremap of 0xB19D000 failed
EFI: ioremap of 0xB1C8000 failed
.
.
.
EFI: Failed to allocate res Runtime Service Code : 0xb178000-0xb19cfff
EFI: Failed to allocate res Runtime Service Data : 0xb19d000-0xb1c7fff
EFI: Failed to allocate res Runtime Service Data : 0xb1c8000-0xb1c8fff
The ioremap failures does not cause any problem as right now all
calls to EFI runtime are commented out (via the appletv patch). The
initial ioremap failure is because the memory is already mapped.
The problem is that the EFI memory map has a 35MB section of memory
that is declared conventional memory and the above memory locations
overlap and are also declared in the last three EFI map locations.
ACPI grabs the conventional chuck, then ignores the last three as
they are marked special. "cat /proc/iomem" shows the conventional
memory and you need to enable EFI_DEBUG in arch/i386/kernel/efi.c to
see the EFI memory map in dmesg.
This sets a timebomb that trips when linux happens to overwrite EFI
Runtime Service Code/Data and some EFI service runs possibly via an
ACPI change. I see most of my hangs when waking from a screensaver
blank.
I'm still tracking in source code as to where the linux side memory
map is created, I think it's in some ACPI related code related to the
MCFG section.
Any pointers or suggestions as to how to further debug/fix this
potential problem would be appreciated. Remember this is pure EFI
without any BIOS compatibility layer so e820 mapping does not happen.
Thanks
Scott
kernel). I believe I've tracked down a possible memory map problem
between ACPI derived memory map and the EFI memory map.
Here's the indicators from dmesg (from
http://www.mactel-linux.org/wiki/Dmesg_appletv);
EFI: ioremap of 0xB178000 failed
EFI: ioremap of 0xB19D000 failed
EFI: ioremap of 0xB1C8000 failed
.
.
.
EFI: Failed to allocate res Runtime Service Code : 0xb178000-0xb19cfff
EFI: Failed to allocate res Runtime Service Data : 0xb19d000-0xb1c7fff
EFI: Failed to allocate res Runtime Service Data : 0xb1c8000-0xb1c8fff
The ioremap failures does not cause any problem as right now all
calls to EFI runtime are commented out (via the appletv patch). The
initial ioremap failure is because the memory is already mapped.
The problem is that the EFI memory map has a 35MB section of memory
that is declared conventional memory and the above memory locations
overlap and are also declared in the last three EFI map locations.
ACPI grabs the conventional chuck, then ignores the last three as
they are marked special. "cat /proc/iomem" shows the conventional
memory and you need to enable EFI_DEBUG in arch/i386/kernel/efi.c to
see the EFI memory map in dmesg.
This sets a timebomb that trips when linux happens to overwrite EFI
Runtime Service Code/Data and some EFI service runs possibly via an
ACPI change. I see most of my hangs when waking from a screensaver
blank.
I'm still tracking in source code as to where the linux side memory
map is created, I think it's in some ACPI related code related to the
MCFG section.
Any pointers or suggestions as to how to further debug/fix this
potential problem would be appreciated. Remember this is pure EFI
without any BIOS compatibility layer so e820 mapping does not happen.
Thanks
Scott