Andrew Morton wrote:
hm, I wonder what could have caused that - we haven't altered fs/ext3/xattr.c in ages. What is the most recent kernel version you know of which didn't do this? Bear in mind that this crash might be triggered by the current contents of the filesystem, so if possible, please test some other kernel versions on that disk.
I am trying to boot a vanilla kernel on this machine for the first time. Haven't tried any other kernels. Will give it a try.
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)?
Some more information if this could be of any help. 0:mon> di 0xc000000000039574 c000000000039574 e9240008 ld r9,8(r4) c000000000039578 409d0010 ble cr7,c000000000039588 # .memcpy+0x88/0x244 c00000000003957c 79290002 rotldi r9,r9,32 c000000000039580 91230000 stw r9,0(r3) c000000000039584 38630004 addi r3,r3,4 c000000000039588 409e0010 bne cr7,c000000000039598 # .memcpy+0x98/0x244 c00000000003958c 79298000 rotldi r9,r9,16 c000000000039590 b1230000 sth r9,0(r3) c000000000039594 38630002 addi r3,r3,2 c000000000039598 409f000c bns cr7,c0000000000395a4 # .memcpy+0xa4/0x244 c00000000003959c 79294000 rotldi r9,r9,8 c0000000000395a0 99230000 stb r9,0(r3) c0000000000395a4 e8610030 ld r3,48(r1) c0000000000395a8 4e800020 blr c0000000000395ac 78a6e8c2 rldicl r6,r5,61,3 c0000000000395b0 38a5fff0 addi r5,r5,-16 0:mon> r R00 = 000000000000e40f R16 = 00000000100edbc8 R01 = c00000003e59b3e0 R17 = 00000000100b0000 R02 = c0000000009c2110 R18 = 0000000000000005 R03 = c000000044bc90e0 R19 = 00000000fff0d7a8 R04 = c000000039cffff4 R20 = 00000000fff0d708 R05 = 0000000000000003 R21 = 00000000000000ff R06 = 0000000000000000 R22 = 0000000000000006 R07 = 0000000000000001 R23 = c00000000079ab49 R08 = 723a7573725f743a R24 = c0000000372fe2a8 R09 = 3a6f626a6563745f R25 = c000000044bc90c8 R10 = c00000003b250968 R26 = c0000000372fe240 R11 = c000000000039500 R27 = c0000000372fe3b0 R12 = d00000000244c590 R28 = c0000000372c5280 R13 = c000000000a53480 R29 = 000000000000001b R14 = 00000000100d0000 R30 = d0000000024654d0 R15 = 0000000000000000 R31 = ffffffffffffffde pc = c000000000039574 .memcpy+0x74/0x244 lr = d00000000244916c .ext3_xattr_get+0x288/0x2f4 [ext3] msr = 8000000000009032 cr = 4400844b ctr = 0000000000000000 xer = 0000000000000001 trap = 300 dar = c000000039d00000 dsisr = 40000000 0:mon> So the other thing i noticed was that this machine was running a kernel with selinux enabled. I turned off selinux and there were no issues during bootup. It was a clean boot. Thanks -Sachin -- --------------------------------- Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India --------------------------------- -- 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
