On Tue, Oct 30, 2012 at 2:21 AM, Jacob Burkholder <jacob.burkholder@xxxxxxxxxxxxxxxxx> 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.
