From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: "Anton Wöllert" <a.woellert@gmail.com>, linuxppc-embedded@ozlabs.org
Subject: [PATCH] 8xx: avoid icbi misbehaviour in __flush_dcache_icache_phys
Date: Wed, 20 Jul 2005 03:29:00 -0300 [thread overview]
Message-ID: <20050720062859.GA8477@dmt.cnet> (raw)
Anton,
Can you please test the following which is equivalent to your=20
suggest changes, the only difference being the location, contained=20
inside flush_dcache_icache_page(). After confirmation that it works
we can send up to the kernel maintainers.
We should still try to understand why this is happening, possibly=20
matching it to a published CPU errata bug, or inform Freescale
otherwise.
I've written that entry down in the 8xx TODO list.
Thanks!
-------------
On 8xx, in the case where a pagefault happens for a process who's not
the owner of the vma in question (ptrace for instance), the flush=20
operation is performed via the physical address.
Unfortunately, that results in a strange, unexplainable "icbi"=20
instruction fault, most likely due to a CPU bug (see oops below).
Avoid that by flushing the page via its kernel virtual address.=20
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tai=
nted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 00000010, DSISR: C2000000
TASK =3D c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
00000001
GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
00000001
GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
C01E0000
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30
Call trace:
[c000b154] update_mmu_cache+0x7c/0xa4
[c005ae98] do_wp_page+0x460/0x5ec
[c005c8a0] handle_mm_fault+0x7cc/0x91c
[c005ccec] get_user_pages+0x2fc/0x65c
[c0027104] access_process_vm+0x9c/0x1d4
[c00076e0] sys_ptrace+0x240/0x4a4
[c0002bd0] ret_from_syscall+0x0/0x44
From: Anton W=F6llert <a.woellert@gmail.com>=20
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
--- a/arch/ppc/mm/init.c.orig 2005-07-20 03:05:44.000000000 -0300
+++ b/arch/ppc/mm/init.c 2005-07-20 03:05:46.000000000 -0300
@@ -577,6 +577,9 @@
#ifdef CONFIG_BOOKE
__flush_dcache_icache(kmap(page));
kunmap(page);
+#elif CONFIG_8xx
+ /* On 8xx there is no need to kmap since highmem is not supported */
+ __flush_dcache_icache(page_address(page));=20
#else
__flush_dcache_icache_phys(page_to_pfn(page) << PAGE_SHIFT);
#endif
next reply other threads:[~2005-07-20 18:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-20 6:29 Marcelo Tosatti [this message]
2005-07-20 23:34 ` [PATCH] 8xx: avoid icbi misbehaviour in __flush_dcache_icache_phys Anton Wöllert
2005-07-23 12:21 ` Marcelo Tosatti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050720062859.GA8477@dmt.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=a.woellert@gmail.com \
--cc=linuxppc-embedded@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.