[Xen-devel] RE: AMD Phenom II 940: Upgrade to 2.6.32.12 fixes it and upgrades CPU from 3.1Ghz to 1.2Thz!

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> >>> enlighten.c, 'd0 domain attempted wrmsr', 'Detected 1226681.732 MHz
> >>> processor.'(a 1.2 TeraHz processor??? - the processor is actually a
> 3.1
> > I'm wondering if this bothers delay loop timings, etc. ???
> 
> Dan, thoughts? 

This info is obtained from Xen via the shared_info struct, so
I'd bet the shared_info struct is getting trashed.

Or, for awhile, Jeremy had some code that made it possible
for pvclock to use multiple shared_info structs to detect
TSC skew.  I think that got pulled for 4.0, but not sure
I remember why (or the symptoms)... and I'm not sure what
Xen bits you are testing with.

> -----Original Message-----
> From: Konrad Wilk
> Sent: Monday, May 10, 2010 10:17 AM
> To: Gerry Reno; Dan Magenheimer
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: AMD Phenom II 940: Upgrade to 2.6.32.12 fixes it and upgrades
> CPU from 3.1Ghz to 1.2Thz!
> 
> On Mon, May 10, 2010 at 12:03:09PM -0400, Gerry Reno wrote:
> > On 05/10/2010 10:10 AM, Konrad Rzeszutek Wilk wrote:
> >>> Ok, I tried to adjust bridge parameters and found that I can
> finally get
> >>> pv_ops dom0 to boot in normal timeframe if I comment out all bridge
> >>> related statements in /etc/xen/xend-config.sxp.  Before with
> 2.6.31.6 I
> >>> had (network-script network-bridge) and also tried (network-script
> >>> 'network-bridge bridge=br0') but these do not work with 2.6.32.12.
> >>>
> >> I had this problem when I forgot to have 'CONFIG_BRIDGE' enabled in
> my
> >> .config, and also CONFIG_TAP (but I think that was only used during
> >> guest startup) but I don't think that is your problem. It could be
> related to
> >> this:
> >>
> >> "init: eucalyptus-network (eth0) main process (1156) killed by TERM
> signal"
> >>
> >> which might have mangled the eth0? Why is it being killed?
> >>
> >
> > I'm going to investigate this but I suspect it dies because eth0
> isn't
> > there.  The euca network works fine after I restart networking.
> 
> Uh, why isn't eth0 there? The kernel log looks to have 'eth0' setup.
> Did
> it get renamed?
> >
> >
> >>
> >>> However, there are still errors in the pv_ops dom0 2.6.32.12
> console
> >>> output so I'm attaching the output so someone could see if they are
> >>> serious or if there are workarounds to improve things.  I'm seeing
> >>> things like 'unable to locate IOAPIC for xxx', call trace from
> >>>
> >> Don't worry about that. These are used to setup the GSI and there is
> a
> >> second code path that does that.
> >>
> > Ok.  But then why bother writing these scary messages that just
> confuse
> > things?
> 
> Well, you know.. job security and such :-)
> 
> But in all seriousness - I was thinking about doing something about
> those pesky messages, but haven't yet come up with a good way of doing
> it.
> 
> >
> >
> >>
> >>> enlighten.c, 'd0 domain attempted wrmsr', 'Detected 1226681.732 MHz
> >>> processor.'(a 1.2 TeraHz processor??? - the processor is actually a
> 3.1
> 
> Maybe you should look in a lead case. You know at that speeds your
> CPU might be producing X-rays that could be harmful to you.
> 
> >>> GHz processor), 'No compatible ACPI _PSS objects found.'.
> >>>
> >> Interesting. My AMD prototype board shows the same data (or
> sometimes
> >> even higher number)- completly bogus.
> >>
> > I'm wondering if this bothers delay loop timings, etc. ???
> 
> Dan, thoughts?
> 
> >
> >
> >>> Plus, why do I see slightly different outputs on the consoles?
> Some
> >>> errors only show on one of the consoles but not the other.
> >>>
> >> That is b/c the Xen console (all prefixed with XEN) shouldn't by
> default
> >> be in the Linux domain, unless requested.
> >> .. snip..
> >>
> >>> (XEN) Command line: dummy=dummy dom0_mem=1024M  vga=text-80x50
> loglvl=all guest_loglvl=all sync_console console_to_rin1
> >>>
> >>
> ^'g'
> >>
> >> or unless you use console_to_ring at which point all of the output
> >> should be synced together. Except that you have '1' at the end
> instead
> >> of 'g'.
> >>
> > The '1' is an artifact due to the command line actually being
> truncated.
> > It's actually the last character on the line.
> 
> Ah, OK.
> >
> >
> >
> >> .. snip..
> >>
> >>> GR: now login prompt shows up immediately:
> >>>
> >> Hurrayy!
> >>
> >
> > Yeah, no kidding!  :-)
> >
> > Thanks for the help and looking at this.
> 
> Of course.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel