On Mon, 23 Feb 2009, Paul Mackerras wrote: > Andrew Morton writes: > > It looks like we died in ext3_xattr_block_get(): > > > > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs), > > size); > > > > Perhaps entry->e_value_offs is no good. I wonder if the filesystem is > > corrupted and this snuck through the defenses. > > > > I also wonder if there is enough info in that trace for a ppc person to > > be able to determine whether the faulting address is in the source or > > destination of the memcpy() (please)? > > It appears to have faulted on a load, implicating the source. The > address being referenced (0xc00000003f380000) doesn't look > outlandish. I wonder if this kernel has CONFIG_DEBUG_PAGEALLOC turned > on, and what page size is selected? I'm seeing a similar thing on PS3, but not in ext3. During early userspace setup (udevd), it crashes accessing a 0xc00* address in: | NIP setup+0x20/0x130 | LR copy_user_page+0x18/0x6c | Call trace: | do_wp_page+0x5b4/0x89c | do_page_fault+0x3a8/0x58c | handle_page_fault+0x20/0x5c I have CONFIG_DEBUG_PAGEALLOC=y. If I disable it, the system boots fine. If needed, I can probably bisect this tomorrow. It definitely didn't happen in 2.6.29-rc5. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone: +32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: Geert.Uytterhoeven@xxxxxxxxxxx Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
