On 2/7/11 11:12 PM, Ryan Roh wrote:
> Dear Eric,
>
> I don't know how I can make correct form to answer for this thread because
> I'm newbie here. Sorry.
>
> Anyway, this issue was happened from returned HDD from customer which was
> used our PVR STB. And our STB has toggle power switch so I think user turned
> off the power during recording something.
Ok, so you're not sure what happened to the hard drive before this, then.
Other Samsung folks have reported problems after intentionally testing the filesystem under harsh conditions such as poweroff or USB unplugs, so I just wondered...
It seems plausible to me that this could be corruption from lack of proper barrier support, and a poweroff or usb unplug (without barrier support) could cause that.
Mounting a corrupted filesystem should never oops the kernel though, so that is a bug. If you can provide an xfs_metadump image of the filesystem, someone might be able to investigate further.
Does the mount failure persist after an xfs_repair (without using -n?)
If you wish to keep the original filesystem intact, you can make an xfs_metadump image of the filesystem, run xfs_mdrestore to create a new metadata image from that dump, run xfs_repair against that, and try to mount the result.
Does samsung run with CONFIG_XFS_DEBUG enabled? Otherwise, this:
/*
* If we went off the root then we are seriously confused.
*/
ASSERT(lev < cur->bc_nlevels);
would be a no-op:
#ifndef DEBUG
#define ASSERT(expr) ((void)0)
...
(As a side note, running with CONFIG_XFS_DEBUG in production is not recommended.)
However, I'm not quite sure that's what you are hitting, if you tripped an ASSERT you should have seen "Assertion failed" in the messages. This appears to be a null pointer dereference in xfs_free_ag_extent().
-Eric
> Thanks,
> Ryan.
>
>
> -----Original Message-----
> From: Eric Sandeen [mailto:sandeen@xxxxxxxxxxx]
> Sent: Tuesday, February 08, 2011 1:45 PM
> To: Ryan Roh
> Cc: xfs@xxxxxxxxxxx
> Subject: Re: segmentation fault during mount
>
> On 2/7/11 5:01 AM, Ryan Roh wrote:
>> Dear Members,
>>
>> I'm using XFS based on STMicro SH4 based chip (STi7105).
>>
>> and I have some issue on xfs log mounting.
>>
>
> Were the errors after any sort of harsh testing of the filesystem, such as
> usb disconnects or power off?
>
> Or was this after a clean unmount?
>
> -Eric
>
>>
>> 1. chip : sh4 STi7105
>>
>> 2. HDD : 320GB USB HDD USB 2.0 port.
>>
>> 3. OS : Linux 2.6.23.17 + patch for fixing cache aliasing issue.
>>
>> 4. XFSProgs version : 3.1.1
>>
>>
>>
>> mounting and repairing log in the below. This segmentation fault is
>> caused by
>>
>> the assert in xfs_alloc_increment function of xfs_alloc_btree.c file.
>> The btree
>>
>> level is equal to root level in the below code.
>>
>>
>>
>> /*
>>
>> * If we went off the root then we are seriously confused.
>>
>> */
>>
>> ASSERT(lev < cur->bc_nlevels);
>>
>>
>
> ...
>
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
