On Thu, Apr 30, 2009 at 3:36 PM, Matthew L. Creech mlcreech@gmail.com wrote:
The problem I'm currently running into is step 2, which throws an error in ubi_io_write() (see below). Googling around turned up a few hits that suggested turning off sub-page writes, so I tried adding NAND_NO_SUBPAGE_WRITE to NAND_SAMSUNG_LP_OPTIONS, but that causes a crash. Actually, it gets to volume table copy #2 in that case, so the crash may be unrelated to subpage writes.
It seems like disabling subpage writes might be the right thing to do, because once in a while now I _can_ at least attach to a UBI partition ("ubi part") without error. But it usually crashes. The backtraces for the crash vary, but here's a typical example:
0x00144280 -- 0x00143cd0 + 0x05b0 ubi_read_volume_table 0x00143130 -- 0x00142d54 + 0x03dc ubi_attach_mtd_dev 0x001435ec -- 0x001434e4 + 0x0108 ubi_init 0x0011ec24 -- 0x0011e9e4 + 0x0240 do_ubi 0x00126234 -- 0x00125a9c + 0x0798 run_list_real 0x00125754 -- 0x00125198 + 0x05bc parse_stream_outer 0x00125960 -- 0x00125910 + 0x0050 parse_file_outer 0x00128854 -- 0x0012874c + 0x0108 main_loop 0x001048e0 -- 0x0010470c + 0x01d4 board_init_r 0x001035e8 -- 0x001035e8 + 0x0000 trap_init
Nothing special. ubi_read_volume_table is always in the backtrace, though sometimes there's 1 or 2 nested calls above it. Sometimes the crashes are at or around create_empty_lvol() -> create_vtbl() -> ubi_scan_find_seb(), so the problem occurs no later than that in the call sequence. And this is always with copy #2 of the volume table.
Anyone familiar with UBI care to chime in? :)