[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081121155454.a376d737.nishimura@mxp.nes.nec.co.jp>
Date: Fri, 21 Nov 2008 15:54:54 +0900
From: Daisuke Nishimura <nishimura@....nes.nec.co.jp>
To: Valdis.Kletnieks@...edu
Cc: nishimura@....nes.nec.co.jp,
Andrew Morton <akpm@...ux-foundation.org>,
penguin-kernel@...ove.sakura.ne.jp, linux-kernel@...r.kernel.org
Subject: Re: Random freeze (Re: mmotm 2008-11-19-02-19 uploaded)
Hi.
On Fri, 21 Nov 2008 00:23:18 -0500, Valdis.Kletnieks@...edu wrote:
> On Thu, 20 Nov 2008 15:20:54 PST, Andrew Morton said:
>
> > The traditional cause of the above trace is that someone mucked up the
> > block/driver/irq-routing layer and we lost an IO completion.
>
> Yes, that would explain all the symptoms and tracebacks - everybody comes
> to a screeching halt the next time they try to go to disk, while the actual
> disk drive is showing zero activity.
>
> > It's also of course possible (but less common) that someone mucked up
> > the VFS. It would be interesting to revert
> > do_mpage_readpage-dont-submit-lots-of-small-bios-on-boundary.patch.
>
> I'm seeing an MTBF of about 2-3 hours when actually applying an I/O load to the
> system. I'll try reverting that patch, and if it survives an entire day or
> two it will be pretty strong circumstantial evidence that patch is the culprit...
>
Just FYI, I had seen similar errors with recent mmotms,
but current mmotm(2008-11-20-17-03) seems more stable in my environment.
Thanks,
Daisuke Nishimura.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists