On 11/08/2011 04:38 PM, Myron Stowe wrote: > On Mon, Nov 7, 2011 at 7:39 PM, Huang Ying <ying.huang@xxxxxxxxx> wrote: >> On one of our testing machine, the following EINJ command lines: >> >> # echo 0x10000000 > param1 >> # echo 0xfffffffffffff000 > param2 >> # echo 0x8 > error_type >> # echo 1 > error_inject >> >> Will get: >> >> echo: write error: Input/output error >> >> The EIO comes from: >> >> rc = apei_exec_pre_map_gars(&trigger_ctx); >> >> The root cause is as follow. Normally, ACPI atomic IO support is used >> to access IO memory. But in EINJ of that machine, it is used to >> access RAM to trigger the injected error. And the ioremap() called by >> apei_exec_pre_map_gars() can not map the RAM. >> >> This patch add RAM mapping support to ACPI atomic IO support to >> satisfy EINJ requirement. >> >> Signed-off-by: Huang Ying <ying.huang@xxxxxxxxx> >> Tested-by: Tony Luck <tony.luck@xxxxxxxxx> >> --- >> drivers/acpi/atomicio.c | 34 ++++++++++++++++++++++++++++++---- >> 1 file changed, 30 insertions(+), 4 deletions(-) >> > > Hi Huang: > > This patch collides with my series to remove atomicio.[ch]: > https://mail.google.com/mail/?shva=1#label/linux-acpi+list/133805812264a542 > and I don't want such functionality to get lost if/when the removal series > is accepted. I'm interested in working with you, not against you, so would > you like me to do anything with respect to this patch within the osl.c based > mapping routines so this capability would not become lost? > > The obvious choices would be for me to post a new patch, copying this > functionality into osl.c's mapping routines, that would apply on top of the > removal series. Another tact could be for me to do basically the same > thing but within the removal series (by adding this into it, and reposting). > The latter tactic seems like it could be a constant problem if more changes > to atomicio occur during this interim period. Of course you may have other > ideas here as how to progress. > > This type of occurrence, among many others, is a good example of why we > need to get down to just one set of mapping routines as soon as possible. > During this interim period I'll try and monitor the linux-acpi-list > for future such > occurrences but if you could, please try and cc me on any future atomicio > modifications. > > Thanks, > Myron Hi Myron, I've included your 1-3 of "ACPI: Re-factor and remove ./drivers/acpi/atomicio.[ch]" on top of Ying's series "[PATCH 00/11] ACPI, APEI, Patches for 3.3" Can you re-fresh your #4 so it applies on top? Would be delightful to get rid of atomicio. You can pull my branch from git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git next thanks! -Len thanks, -Len -- 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
