Bug 77131
| Summary: | acpi reset register implemented in system memory cannot be mapped from interrupt context | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Randy Wright (rwright) |
| Component: | ACPICA-Core | Assignee: | David Box (david.e.box) |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| Severity: | high | CC: | aaron.lu, david.e.box, rjw, rui.zhang |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | v3.15-rc7 and earlier | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
[PATCH] if appropriate create a virtual mapping for acpi reset register
Use acpi_os_map_generic_address to pre-map the reset register |
||
|
Description
Randy Wright
2014-05-29 19:39:05 UTC
Hi Randy, Your patch includes a call to arch_reserve_mem_area() which can't be used in acpica code since it's Linux specific. All code is drivers/acpi/acpica is OS independent, taken mostly as is into Linux and other OS's. Are you sure you need to make this call? Is the reset register address not in an area of memory that's already reserved? Dave Hi Dave, I will research your question carefully, since the answer to your question is that I believe the region containing the reset register should be reserved already and the arch_reserve_mem_area would simply categorize it more precisely. In the particular configuration of the prototype I am using, the reset register is on a page starting at 0xfe062141000. The EFI memmap shows this as type 11 EFI_MEMORY_MAPPED_IO, and it appears in the initial E820 map as reserved: [ 0.000000] BIOS-e820: [mem 0x00000fe060000000-0x00000fe073ffffff] reserved After adding the arch_reserve_mem_area call, it is more accurately recorded in the map as ACPI data but it does seem that "reserved" really should have been okay: [ 0.000000] modified: [mem 0x00000fe060000000-0x00000fe062140027] reserved [ 0.000000] modified: [mem 0x00000fe062140028-0x00000fe06214002f] ACPI data [ 0.000000] modified: [mem 0x00000fe062140030-0x00000fe073ffffff] reserved The check_early_ioremap_leak diagnostic appeared at the same point I did two things to an initial version of the same patch idea. The initial version of the patch ran later, called from acpi_init. I both moved it to be called earlier, from acpi_tb_setup_fadt_registers. and at the same time brought the patch forward from an earlier stable kernel into the latest 3.15 rc kernel. So perhaps in moving it I did something else that triggered the diagnostic. I will research more today. Created attachment 138021 [details]
Use acpi_os_map_generic_address to pre-map the reset register
As I further researched the necessity of using arch_reserve_mem_area, I became convinced there was no point in trying to do the allocation when the early ioremap allocator is in use. By performing the mapping slightly later in the boot sequence, in acpi_os_initialize, the early allocator is avoided, so of course there is no early ioremap leak diagnostic. As an additional benefit, the patch logically fits very well with the existing calls to acpi_os_map_generic_address already made in acpi_os_initialize.
|