[PLUG] local hardware

Steve Bonds 1s7k8uhcd001 at sneakemail.com
Mon Mar 27 08:30:57 UTC 2006


On 3/23/06, Steve Bonds wrote:

> On 3/23/06, Steve Bonds 1s7k8uhcd001-at-sneakemail.com wrote:
>
> > My only concern is VMware now coredumps a lot, which is bad since
> > that's all this box does.  However, I'm a revision behind on their
> > beta server so I'll upgrade and see how it goes.  I'm a bit puzzled
> > why everything else would work great yet have one application choke...
>
> It turns out the problem is the AMD processor.  I figured AMD or Intel
> made little difference-- but I was wrong.
>
> AMD64 processors do not keep themselves in time sync on multiprocessor
> systems.  VMware was getting confused because it would send a SCSI
> command to its virtual disk, then when it checked how long it took it
> came up with a negative number and panicked.
>
> The workaround is to tell each virtual machine to only run on a single
> processor.  This nicely fixed the coredumps.
>
> Description of the source of the problem (SCSI timings):
>
> http://www.vmware.com/community/thread.jspa?threadID=7644

I've also run into another, more severe problem with this
configuration-- also related to the unsynchronized timestamp counters
(TSCs) found on AMD multiprocessor systems.  My keyboard randomly
repeats characters under CentOS4, just as described here:

http://kerneltrap.org/node/6258

I've tried the various fixes, some don't apply (not using a USB
keyboard) and some didn't work ("clock=tsc" on kernel line).  I'll
keep investigating, but right now I'm not hopeful.

I'm continuing to use CentOS3 since it seems to work properly, but am
once again disappointed in my choice of AMD for my multiprocessor
system.  As someone who's used AMD processors wherever possible since
my 386-40 way back in The Day, this is extra disappointing.

  -- Steve



More information about the PLUG mailing list