On Thu, 2013-03-14 at 11:13 +0200, Artem Bityutskiy wrote:
> On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
> > Sorry ... this just locks up the unit.
>
> OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
> below. The patch I proposed did not get the error path correct
On Thu, 2013-03-14 at 13:40 +, Mark Jackson wrote:
> On 14/03/13 12:23, Artem Bityutskiy wrote:
> > On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
> >>> Is this size larger than the allocated buffer ?
> >>
> >> I believe so.
> >
> > Err, I mean, the buffer is large enough. I do not
On 14/03/13 12:23, Artem Bityutskiy wrote:
> On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
>>> Is this size larger than the allocated buffer ?
>>
>> I believe so.
>
> Err, I mean, the buffer is large enough. I do not believe there is a
> stupid bug like too small buffer. This code has
On 14/03/13 13:40, Mark Jackson wrote:
> On 14/03/13 12:23, Artem Bityutskiy wrote:
>> On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
Is this size larger than the allocated buffer ?
>>>
>>> I believe so.
>>
>> Err, I mean, the buffer is large enough. I do not believe there is a
>>
On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
> > Is this size larger than the allocated buffer ?
>
> I believe so.
Err, I mean, the buffer is large enough. I do not believe there is a
stupid bug like too small buffer. This code has worked for years and I
do not think it was changes
On Thu, 2013-03-14 at 12:02 +, Mark Jackson wrote:
> But there's also a call to crc with a size of 122880 bytes, and that's
> when the oops occurs.
>
This is when we do the atomic LEB change.
> Is this size larger than the allocated buffer ?
I believe so.
--
Best Regards,
Artem Bityutskiy
On 14/03/13 11:23, Artem Bityutskiy wrote:
> On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote:
>> [ 28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte=
>> [ 28.545173] Internal error: Oops: 7 [#1] ARM
>> [ 28.549685] CPU: 0Not tainted
>> (3.8.0-next-20130225-2-g6
On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote:
> [ 28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte=
> [ 28.545173] Internal error: Oops: 7 [#1] ARM
> [ 28.549685] CPU: 0Not tainted
> (3.8.0-next-20130225-2-g678576f-dirty #40)
> [ 28.557595] PC is at crc32
On 14/03/13 10:30, Artem Bityutskiy wrote:
> On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
>> On 14/03/13 09:13, Artem Bityutskiy wrote:
>>> On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
>>>
>>> OK, I've reproduced the issue with 3.9-rc2
On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
> On 14/03/13 09:13, Artem Bityutskiy wrote:
> > On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
> >> Sorry ... this just locks up the unit.
> >
> > OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
> > below. The p
On 14/03/13 09:13, Artem Bityutskiy wrote:
> On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
>> Sorry ... this just locks up the unit.
>
> OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
> below. The patch I proposed did not get the error path correctly, but it
> does
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
> Sorry ... this just locks up the unit.
OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
below. The patch I proposed did not get the error path correctly, but it
does fix the issue.
I think what you treat as "lockup" is
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
> > - if (c->space_fixup) {
> > - err = ubifs_fixup_free_space(c);
> > - if (err)
> > - goto out;
> > - }
> > -
> > mutex_unlock(&c->umount_mutex);
> > return err;
> >
>
> Sorry ... this just
On 13/03/13 11:20, Artem Bityutskiy wrote:
> On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
>>> - if (c->space_fixup) {
>>> - err = ubifs_fixup_free_space(c);
>>> - if (err)
>>> - goto out;
>>> - }
>>> -
>>> mutex_unlock(&c->umount_mutex);
>>>
On 12/03/13 11:25, Artem Bityutskiy wrote:
> On Mon, 2013-03-04 at 16:42 +, Mark Jackson wrote:
>> I'm encountering an oops when remounting my ubifs volume as read/write.
>>
>> # mount -o remount,rw /
>> [ 89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
>> [ 89.442122] [
On Mon, 2013-03-04 at 16:42 +, Mark Jackson wrote:
> I'm encountering an oops when remounting my ubifs volume as read/write.
>
> # mount -o remount,rw /
> [ 89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
> [ 89.442122] [] (unwind_backtrace+0x0/0xf0) from []
> (ubifs_w
I'm encountering an oops when remounting my ubifs volume as read/write.
# mount -o remount,rw /
[ 89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
[ 89.442122] [] (unwind_backtrace+0x0/0xf0) from []
(ubifs_write_node+0x180/0x1c4)
[ 89.451896] [] (ubifs_write_node+0x180/0x
17 matches
Mail list logo
