From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752868AbbIHUv0 (ORCPT ); Tue, 8 Sep 2015 16:51:26 -0400 Received: from smtp01.smtpout.orange.fr ([80.12.242.123]:32524 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751552AbbIHUvW (ORCPT ); Tue, 8 Sep 2015 16:51:22 -0400 X-ME-Helo: belgarion X-ME-Auth: amFyem1pay5yb2JlcnRAb3JhbmdlLmZy X-ME-Date: Tue, 08 Sep 2015 22:51:20 +0200 X-ME-IP: 109.220.179.182 From: Robert Jarzmik To: Russell King - ARM Linux Cc: Dave Martin , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] ARM: fix alignement of __bug_table section entries References: <20150902103955.GF6281@e103592.cambridge.arm.com> <878u8lx9hl.fsf@belgarion.home> <20150905142519.GN21084@n2100.arm.linux.org.uk> <87y4gkx04m.fsf@belgarion.home> <20150905203818.GO21084@n2100.arm.linux.org.uk> <87lhcjwjde.fsf@belgarion.home> <20150906194805.GP21084@n2100.arm.linux.org.uk> <87egibw7yh.fsf@belgarion.home> <20150906235414.GQ21084@n2100.arm.linux.org.uk> <877fo0x2ur.fsf@belgarion.home> <20150908200809.GC21084@n2100.arm.linux.org.uk> X-URL: http://belgarath.falguerolles.org/ Date: Tue, 08 Sep 2015 22:46:30 +0200 In-Reply-To: <20150908200809.GC21084@n2100.arm.linux.org.uk> (Russell King's message of "Tue, 8 Sep 2015 21:08:09 +0100") Message-ID: <8737yowsex.fsf@belgarion.home> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Russell King - ARM Linux writes: > What should happen is: Thanks very much for the explanation, hopefully I have enough material to fly on my own now. > Now, when you get the fault inside arm_copy_from_user(), you can > print the DACR value saved at the time the fault was generated by > printing the word above struct pt_regs on the stack - add to > arch/arm/mm/fault.c:do_DataAbort(): > > if (addr == 0xbf00202c) printk("DACR=0x%08x\n", *(u32 *)(regs + 1)); > > before the "if (!inf->fn(addr, fsr & ~FSR_LNX_PF, regs))" line. > That'll tell us what the DACR register was when we saved it. > > If it isn't 0x75, then the next part of the puzzle is going to be > working out why it isn't. It's 0x55. I'll track down how this happens, there are not that many places where DACR is touched, and I'm in a very controlled environement, so I can cunningly place JTAG breakpoints and watch DACR. I'll report once I have a better idea what is happening, that might take me a couple of days given that most of my workforce is available on weekends only. Thanks again for the free lesson. -- Robert From mboxrd@z Thu Jan 1 00:00:00 1970 From: robert.jarzmik@free.fr (Robert Jarzmik) Date: Tue, 08 Sep 2015 22:46:30 +0200 Subject: [PATCH] ARM: fix alignement of __bug_table section entries In-Reply-To: <20150908200809.GC21084@n2100.arm.linux.org.uk> (Russell King's message of "Tue, 8 Sep 2015 21:08:09 +0100") References: <20150902103955.GF6281@e103592.cambridge.arm.com> <878u8lx9hl.fsf@belgarion.home> <20150905142519.GN21084@n2100.arm.linux.org.uk> <87y4gkx04m.fsf@belgarion.home> <20150905203818.GO21084@n2100.arm.linux.org.uk> <87lhcjwjde.fsf@belgarion.home> <20150906194805.GP21084@n2100.arm.linux.org.uk> <87egibw7yh.fsf@belgarion.home> <20150906235414.GQ21084@n2100.arm.linux.org.uk> <877fo0x2ur.fsf@belgarion.home> <20150908200809.GC21084@n2100.arm.linux.org.uk> Message-ID: <8737yowsex.fsf@belgarion.home> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Russell King - ARM Linux writes: > What should happen is: Thanks very much for the explanation, hopefully I have enough material to fly on my own now. > Now, when you get the fault inside arm_copy_from_user(), you can > print the DACR value saved at the time the fault was generated by > printing the word above struct pt_regs on the stack - add to > arch/arm/mm/fault.c:do_DataAbort(): > > if (addr == 0xbf00202c) printk("DACR=0x%08x\n", *(u32 *)(regs + 1)); > > before the "if (!inf->fn(addr, fsr & ~FSR_LNX_PF, regs))" line. > That'll tell us what the DACR register was when we saved it. > > If it isn't 0x75, then the next part of the puzzle is going to be > working out why it isn't. It's 0x55. I'll track down how this happens, there are not that many places where DACR is touched, and I'm in a very controlled environement, so I can cunningly place JTAG breakpoints and watch DACR. I'll report once I have a better idea what is happening, that might take me a couple of days given that most of my workforce is available on weekends only. Thanks again for the free lesson. -- Robert