Hi Geert,
On 19/03/12 06:03, Geert Uytterhoeven wrote:
On Sun, Mar 18, 2012 at 13:52, Andreas Schwab<schwab@xxxxxxxxxxxxxx> wrote:
Geert Uytterhoeven<geert@xxxxxxxxxxxxxx> writes:
I'm a bit puzzled, as the crash location is not a memory dereference but
the "set_fs(MAKE_MM_SEG(wbs));" in do_040writeback1().
I guess the integer unit can move ahead while the memory unit processes
the write. áTake a look at the places that jump to 0x5da8.
Thanks for the hint!
Given that a1 is zero, and d1 is 64, it looks like it's the movesl at
5e14 that caused the problem:
5e14: 0e91 2800 movesl %d2,%a1@
5e18: 2400 movel %d0,%d2
5e1a: 608c bras 5da8<berr_040cleanup+0x144>
This corresponds to
case BA_SIZE_LONG:
res = put_user(wbd, (int __user *)wba);
in do_040writeback1(). So wba is zero. Oops...
Did this work properly in 3.2?
If so can you git bisect it to find a problem patch?
There has been quite a bit of m68k core change with all the ColdFire
MMU new code coming in for 3.3. I wouldn't expect any specific problems
with existing 040 code... But it does touch a lot of code in little
ways.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@xxxxxxxxxxxx
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
