lkml.org 
[lkml]   [2009]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel 2.6.30.4 XFS(..?) regression (& with/2.6.31-rc6)


On Mon, 24 Aug 2009, Justin Piszcz wrote:

>
>
> On Sun, 23 Aug 2009, Christoph Hellwig wrote:
>
>> Ok, let's see where errors could happen then.
>>
>> There are four theoretical possibilities:
>>
>> (a) XFS
>> (b) loop driver
>> (c) crypto loop code
>> (d) block layer
>>
>> Or combinations thereof.
>>
>> I would take (a) and (d) as more unlikely as they tend to get used much
>> more and I would have heard more bug reports already.
>>
>> The cryptoloop code hasn't changed at all since 2.6.29.
>>
>> The loop code howver has a very interesting commit just after 2.6.39:
>>
>> commit 68db1961bbf4e16c220ccec4a780e966bc1fece3
>> Author: Nikanth Karthikesan <knikanth@suse.de>
>> Date: Tue Mar 24 12:29:54 2009 +0100
>>
>> loop: support barrier writes
>>
>> Can you try reverting this one (it cleanly reverse-applies against
>> 2.6.30 and current mainline) and see if that makes a difference?
>>
>
> Hello Christoph,
>
> # patch -p1 -R < ../unpatch.patch
> patching file drivers/block/loop.c
> Hunk #1 succeeded at 473 (offset -1 lines).
> Hunk #2 succeeded at 804 (offset -22 lines).
> #
>
> Patched, we'll see if the problem recurs.. thanks!
>
> Justin.
>

Hi Christoph,

So far the uptime is 2 days, if it does not recur in the next 24-48 hours,
do you recommend I follow up with the linux-crypto folks about this? It
appears this could be the cause (no issues, as of yet).

Justin.


\
 
 \ /
  Last update: 2009-08-26 15:53    [W:0.667 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site