From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: 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 09:40:29 -0700 (PDT) Message-ID: <81240ce8-4265-431e-b5e6-71c5340e2af3@default> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20100510161703.GA30879@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: konrad.wilk@oracle.com, Gerry Reno Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > >>> 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. ??? >=20 > Dan, thoughts?=20 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! >=20 > 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=3Dbr0') 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. >=20 > 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? >=20 > Well, you know.. job security and such :-) >=20 > 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. >=20 > > > > > >> > >>> enlighten.c, 'd0 domain attempted wrmsr', 'Detected 1226681.732 MHz > >>> processor.'(a 1.2 TeraHz processor??? - the processor is actually a > 3.1 >=20 > 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. >=20 > >>> 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. ??? >=20 > Dan, thoughts? >=20 > > > > > >>> 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=3Ddummy dom0_mem=3D1024M vga=3Dtext-80x50 > loglvl=3Dall guest_loglvl=3Dall 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. >=20 > Ah, OK. > > > > > > > >> .. snip.. > >> > >>> GR: now login prompt shows up immediately: > >>> > >> Hurrayy! > >> > > > > Yeah, no kidding! :-) > > > > Thanks for the help and looking at this. >=20 > Of course.