[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.