Bug#592187: [stable] Bug#576838: virtio network crashes again
On Tue, 2010-08-31 at 06:35 -0700, Greg KH wrote:
> On Tue, Aug 31, 2010 at 10:16:56AM +0200, Lukas Kolbe wrote:
> > Am Montag, den 30.08.2010, 10:21 -0700 schrieb Greg KH:
> > > On Mon, Aug 30, 2010 at 09:46:36AM -0700, David Miller wrote:
> > > > From: Greg KH <firstname.lastname@example.org>
> > > > Date: Mon, 30 Aug 2010 07:50:17 -0700
> > > >
> > > > > As I stated above, I need the ACK from David to be able to add these
> > > > > patches.
> > > > >
> > > > > David?
> > > >
> > > > I believe there were some regressions caused by these changes that were
> > > > fixed later, a bit after those commites went into the tree.
> > > >
> > > > I'm only confortable ACK'ing this if someone does due diligence and
> > > > checks for any such follow-on fixes to that series.
> > > >
> > > > It's a pretty non-trivial set of patches and has the potential to kill
> > > > performance which would be a very serious regression.
> > >
> > > Fair enough.
> > Yep, thanks!
> > > Who's done the checks to find out any problems with these patches?
> > I'll skim the changelogs in 2.6.3.x to see if there are any related
> > patches.
> > > And what is keeping you from moving to the .35 kernel tree instead?
> > Basically, distribution support. Debian Squeeze will ship with 2.6.32,
> > as Ubuntu already did for their current LTS - and I really want Debian's
> > kernel to be as reliable and stable as possible (btw, that's why I
> > initally reported this as a debian bug, because at that time I wasn't
> > using vanilla kernels. Now that I know how git bisect works, it will
> > hopefully be easier for me to pinpoint regressions in the future).
> > Also, We do not really have enough hardware to test new upstream
> > releases thouroughly before going into production (e.g., we only have
> > one big tape library with one big disk pool, so no test if
> > tape-on-mptsas and aacraid work properly and stable in a newer upstream
> > releases.
> Then how about convincing the Debian kernel developers to accept these
> patches, and work through any regressions that might be found and after
> that, reporting back to us?
The reason I contacted you was precisely because it went into 184.108.40.206,
e.g. was already accepted into a -stalbe release. I didn't expect it to
be such an issue.
> greg k-h