On Fri, Mar 07 2008, Ingo Molnar wrote:
quoted text
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > > Presumably any hw issues would get noticed (like missing interrupt) 
> > > and trigger the error handler, so it looks like this IO is still 
> > > stuck in the queue somewhere. That mainly points the finger at AS, 
> > > but given that you cannot reproduce I'm not sure how best to proceed 
> > > with this...
> > 
> > me neither... just wanted to give notice that something's brewing in 
> > this area. Will know more after tonight's qa series i guess, if it 
> > gets above 100 bootups ;-)
> 
> no luck - a few hundred successful randconfig bootups overnight (with a 
> rather complex userspace startup to full X plus networking, and the 
> testbox is used via the network to compile the next random kernel as 
> well - etc.) and no failure at all. So there's not much we can do at 
> this point - i'll keep you updated if anything new happens in the tests.

OK, so it could possibly be something else or perhaps something that's
existed for a long time.

To capture vital debugging information for cases like this, I had an
idea for a sysrq key that would dump queue and io scheduler info for all
known block devices. That should help pin point where the problem lies.
If we have any letters left in the sysrq namespace :-)

-- 
Jens Axboe

--
unsubscribe notice
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/