From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerry Reno Subject: Re: RE: AMD Phenom II 940: Upgrade to 2.6.32.12 fixes it and upgrades CPU from 3.1Ghz to 1.2Thz! Date: Mon, 10 May 2010 13:40:55 -0400 Message-ID: <4BE84527.2000109@verizon.net> References: <482967.72793.qm@web56107.mail.re3.yahoo.com> <4BE44375.1030300@verizon.net> <4BE48BE4.8000607@verizon.net> <20100510141038.GA29517@phenom.dumpdata.com> <4BE82E3D.5090405@verizon.net 20100510161703.GA30879@phenom.dumpdata.com> <81240ce8-4265-431e-b5e6-71c5340e2af3@default> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <81240ce8-4265-431e-b5e6-71c5340e2af3@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: xen-devel@lists.xensource.com, konrad.wilk@oracle.com List-Id: xen-devel@lists.xenproject.org "...and I'm not sure what Xen bits you are testing with." I'm using Xen 4.0.0-rc8. Kernel is 2.6.32.12. -Gerry On 05/10/2010 12:40 PM, Dan Magenheimer wrote: >>>>> 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@lists.xensource.com >> 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@lists.xensource.com > http://lists.xensource.com/xen-devel > >