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
|
Home