On Wed, Jan 29, 2014 at 8:13 PM, Andrew Ruder wrote:
> On Wed, Jan 29, 2014 at 04:56:04PM +0100, Richard Weinberger wrote:
>> Does the issue also happen if you disable preemption?
>> i.e. CONFIG_PREEMPT_NONE=y
>
> CONFIG_PREEMPT_NONE=y still breaks. I suspect that sync_filesystem
> has some block
On Wed, Jan 29, 2014 at 04:56:04PM +0100, Richard Weinberger wrote:
> Does the issue also happen if you disable preemption?
> i.e. CONFIG_PREEMPT_NONE=y
CONFIG_PREEMPT_NONE=y still breaks. I suspect that sync_filesystem
has some blocking behavior that allows other processes to schedule.
Another
Am 29.01.2014 16:46, schrieb Andrew Ruder:
> On Wed, Jan 29, 2014 at 08:30:45AM +0100, Richard Weinberger wrote:
>> BTW: Can you please share your .config?
>
> No problem. FYI, this is for a board that is still in development so
> not all my changes have been submitted for inclusion yet. I wou
On Wed, Jan 29, 2014 at 08:30:45AM +0100, Richard Weinberger wrote:
> BTW: Can you please share your .config?
No problem. FYI, this is for a board that is still in development so
not all my changes have been submitted for inclusion yet. I would be
happy to share the changes now if necessary but
On Wed, Jan 29, 2014 at 08:17:35AM +0100, Richard Weinberger wrote:
> So you can trigger this by running fsstress on /mnt and then call
> mount -o remount,ro /mnt?
That's all it takes. I actually run the remount until it succeeds,
obviously with fsstress going in the background there is a pretty
Am 29.01.2014 06:32, schrieb Andrew Ruder:
> Ok, I've got some more useful information. I have been adding
> a multitude of WARN_ON's and prink's all over the remount code and have
> come up with the attached log.
>
> A little bit of explanation:
>
> Line 1: sync_filesystem (from do_remount_sb)
Am 29.01.2014 06:32, schrieb Andrew Ruder:
> Ok, I've got some more useful information. I have been adding
> a multitude of WARN_ON's and prink's all over the remount code and have
> come up with the attached log.
>
> A little bit of explanation:
>
> Line 1: sync_filesystem (from do_remount_sb)
Ok, I've got some more useful information. I have been adding
a multitude of WARN_ON's and prink's all over the remount code and have
come up with the attached log.
A little bit of explanation:
Line 1: sync_filesystem (from do_remount_sb)
Line 188: sync_filesystem ends
Line 43, 64, 81, 98, 114,
On Sat, Jan 25, 2014 at 04:02:15PM +0100, Richard Weinberger wrote:
> So ubifs_bgt0_0 stops and the fun begins.
> Can you trigger the issue also by unmounting /mnt?
> I.e umount -l /mnt
> The background thread should only stop after all io is done...
Did some experiments last week to see if I coul
Just expanding distribution a little bit to see if anyone has any ideas.
On Tue, Jan 21, 2014 at 11:15:10PM -0600, Andrew Ruder wrote:
> Problem:
> ubifs corruption to the point where uboot can no longer deal with it and
> it takes multiple mounts to recover filesystem from Linux.
>
> My hardware
10 matches
Mail list logo
