From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 17 Jun 2008 09:26:58 +0200

quoted text
> So since there's no clear bug pattern and no sure reproducability on my 
> side i'd suggest we track this problem separately and "do nothing" right 
> now. I've excluded this warning from my 'is the freshly booted kernel 
> buggy' list of conditions of -tip testing so it's not holding me up.

I'm going to push the revert through just to be safe and I think it's
a good idea to do so because all of those defer accept changes should
be resubmitted as a group for 2.6.27

quoted text
> and i can apply any test-patch if that would be helpful - if it does a 
> WARN_ON() i'll notice it. (pure extra debug printks with no stack trace 
> are much harder to notice in automated tests)

I don't have time to work on your bug, sorry.  Someone else will
have to step forward and help you with it.

FWIW I don't think your TX timeout problem has anything to do with
packet ordering.  The TX element of the network device is totally
stateless, but it's hanging under some set of circumstances to the
point where we timeout and reset the hardware to get it going again.
--
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/