Re: Fw: crash on x86_64 - mm related?

[Ryan Richter <ryan@tau.solarneutrino.net>]

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/