Bug#524542: Patches to fix bugs related to TSC clocksource on VMware
On Fri, Jul 17, 2009 at 01:25:54PM -0600, dann frazier wrote:
> On Thu, Jul 16, 2009 at 11:53:38AM -0700, Alok Kataria wrote:
> >
> > On Wed, 2009-07-15 at 23:13 -0700, dann frazier wrote:
> > > On Wed, Jul 15, 2009 at 10:09:59PM +0200, Moritz Muehlenhoff wrote:
> > > > On Tue, Jul 14, 2009 at 10:17:24AM -0700, Alok Kataria wrote:
> > > > > Ping....any news on when these patches will be picked ?
> > > > > Please let me know if you have any questions regarding these patches.
> > > >
> > > > We can have to schedule these patches for the next time we bump the
> > > > ABI of the kernel (usually triggered by security fixes requiring
> > > > one).
> > > >
> > > > Or is there already a planned bump, Dann?
> > >
> > > There's not one, but we could create a branch to queue ABI-breaking
> > > fixes.
> >
> > If we do that, would there be an ETA on when I can expect these patches
> > in the kernel ? Does it still have to wait for a security fix requiring
> > ABI bump ?
>
> Nah - ABI bumps can come for non-security reasons too. But, since it
> can be a pain for users (and our installer folks), we try to do queue
> non-critical ABI breakers and do them together.
fyi, I took a shot at backporting these changes. Unfortunately our
source is from before the 32/64 tsc.c merge, and a couple of these
patches can't easily apply (even with the intrepid patches).
Specifically, these are the changesets I had issues with:
commit 83db682
x86: Hypervisor detection and get tsc_freq from hypervisor
commit 0532dac
x86: Skip verification by the watchdog for TSC clocksource
I'm not really comfortable applying the tsc-merge patches themselves
since its not something I can easily spot check. Is it possible to
recode these to apply to the pre-merge tsc files (and demonstrate a
low risk of regression)? If so - and someone want to do that, it, then
it would be an easier push for lenny.
--
dann frazier
Reply to: