lkml.org 
[lkml]   [2006]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Fw: crash on x86_64 - mm related?
From
On Mon, Jan 09, 2006 at 09:44:26AM +0000, Hugh Dickins wrote:
> On Sun, 8 Jan 2006, Linus Torvalds wrote:
> >
> > Code like that should use "set_page_dirty()", which does the appropriate
> > callbacks to the filesystem for that page. I wonder if the bug is simply
> > because the ST code just sets the dirty bit without telling anybody else
> > about it...
>
> Yes, it should be using set_page_dirty_lock(), and that is already known
> about (I have patches for this and similar sg.c, but the sg.c case is
> tougher and not yet finished); but entirely irrelevant to Ryan's case.
>
> Quite apart from the fact that he's doing backups to tape (not dirtying
> the memory from this driver), you'll find that it even passes dirty 0
> when reading into the memory (another bug; whereas sg.c conversely says
> it's always dirtying when it isn't). So there's no point in Ryan
> fiddling with the SetPageDirty.

One thing I forgot to mention was that 2.6.11.3 had the problem too when
I reverted to it. I remember now that the person who made the debian
bug report for this said it only happened with a 64-bit userspace - and
I switched from a 32- to 64-bit userspace when I did 2.6.11 -> 2.6.14
(and I'm too lazy to switch back).

To get the backups back, I just ran a recent kernel with
try_direct_io=0. If there's nothing further for me to test at this
time, I guess I'll go back to doing that until there's something to try.
Is that OK?

-ryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-09 19:56    [W:1.778 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site