On Tue, Oct 30, 2012 at 2:21 AM, Jacob Burkholder
<jacob.burkholder@blinqnetworks.com> wrote:
> Greetings!
>
> We are having an issue with linux 3.6.3 on mips64 with mtd and jffs2.
> The platform is a custom Broadcom XLS board. The issue occurs when a
> jffs2 is unmounted. It does not occur with ubifs for what its worth.
>
> What happens is the bdi-default thread gets an unaligned kernel access
> exception. The unaligned exception is a red herring, the address is
> aligned but it is a bad address. A boot log and stack trace from the
> bdi-default thread is included below as well as some gdb debugging
> output. I tracked this down to the backing_dev_info structures that
> are used with mtd devices, mtd_bdi_unmappable, mtd_bdi_ro_mappable,
> mtd_bdi_rw_mappable, in mtdcore.c around line 338. The mtd device in
> question is nand so uses the mtd_bdi_unmappable backing_dev_info is
> used. When the jffs2 is unmounted the the bdi_forker_thread gets a
> KILL_THREAD signal and calls bdi_clear_pending on the backing_dev_info
> structure mentioned above. This is turn calls
> wake_up_bit(&bdi->state, BDI_pending);, wake_up_bit looks up the zone
> for the page that the passed address is in and this seems to be the
> problem. The backing_dev_info structures are statically allocated in
> the kernel data section and these addresses don't seem to have a vm
> zone structure. I set a breakpoint in wake_up_bit and can that it gets
> called on other addresses which all start with 0xa8000000, finally it
> gets passed the address in the mtd_bdi_unmappable structure and then
> crashes. I changed the backing_dev_info structures to be allocated
> with kzalloc and the problem goes away and jffs2 generally works.
> We link our kernel at address 0xffffffff80100000 and this is what our
> bootloader expects. I tried to change this to link at 0xa800000001000000,
> which would seem to put the kernel data section where the bdi thread
> expects its backing_dev_info structures to be allocated, but our
> bootloader won't boot the image and I don't know if its the correct way
> to deal with the problem. I don't think this is an mtd problem since
> other platforms use these files unmodified, so not sure where to start.
>
> Thanks for any hints.
We had seen the same issue here, and worked around it the same way
(i.e use dynamic allocation for the backing dev structures).
I ran across a similar issue in using built-in DTB (basically, kernel
data address does not work for virt_to_phys/phys_to_virt in 64-bit
when the load address is in CKSEG0). There I did something like this:
ptr = phys_to_virt(__pa(kernel_data_ptr));
This works since __pa knows about CKSEG0 addresses in 64bit.
JC.
|