Re: RE: AMD Phenom II 940: Upgrade to 2.6.32.12 fixes it and upgrades CPU from 3.1Ghz to 1.2Thz!

[Gerry Reno <greno@verizon.net>]

"...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
>
>