fc15 xendom0, xen-4.0.1-6.fc14.i686, ATI Rage XL
by Jerry Amundson
Doing well. Screen blank all during boot (didn't init graphics in
either a kms or nms way, messages log attached). KDE desktops on both
the console and VNC server session running fine so far. Kind of
awesome. Though I think this the best of my hardware scenarios. :-)
[root@elm ~]# xm dmesg
__ __ _ _ ___ _ __ __ _ _ _
\ \/ /___ _ __ | || | / _ \ / | / /_ / _| ___/ | || |
\ // _ \ '_ \ | || |_| | | || |__| '_ \ | |_ / __| | || |_
/ \ __/ | | | |__ _| |_| || |__| (_) || _| (__| |__ _|
/_/\_\___|_| |_| |_|(_)___(_)_| \___(_)_| \___|_| |_|
(XEN) Xen version 4.0.1 (mockbuild@(none)) (gcc version 4.5.1 20100924
(Red Hat 4.5.1-4) (GCC) ) Tue Oct 12 22:05:55 UTC 2010
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: console=vga dom0_mem=699050 noreboot
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN) Found 4 MBR signatures
(XEN) Found 4 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 00000000000a0000 (usable)
(XEN) 0000000000100000 - 000000007ffc0000 (usable)
(XEN) 000000007ffc0000 - 000000007ffcfc00 (ACPI data)
(XEN) 000000007ffcfc00 - 000000007ffff000 (reserved)
(XEN) 00000000fec00000 - 00000000fec90000 (reserved)
(XEN) 00000000fed20000 - 00000000fed8ffff (reserved)
(XEN) 00000000fee00000 - 00000000fee10000 (reserved)
(XEN) 00000000ffb00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2047MB (2096512kB)
(XEN) ACPI: RSDP 000FDC40, 0014 (r0 DELL )
(XEN) ACPI: RSDT 000FDC54, 0030 (r1 DELL PE700 1 MSFT 100000A)
(XEN) ACPI: FACP 000FDC84, 0074 (r1 DELL PE700 1 MSFT 100000A)
(XEN) ACPI: DSDT 7FFC0000, 1821 (r1 DELL PE7xx 1 MSFT 100000E)
(XEN) ACPI: FACS 7FFCFC00, 0040
(XEN) ACPI: APIC 000FDCF8, 0074 (r1 DELL PE700 1 MSFT 100000A)
(XEN) ACPI: SPCR 000FDD6C, 0050 (r1 DELL PE700 1 MSFT 100000A)
(XEN) Xen heap: 8MB (8856kB)
(XEN) Domain heap initialised
(XEN) Processor #0 15:3 APIC version 20
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 2, version 32, address 0xfec10000, GSI 24-47
(XEN) Enabling APIC mode: Flat. Using 2 I/O APICs
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2793.152 MHz processor.
(XEN) CPU0: Intel Extended MCE MSRs (12) available
(XEN) I/O virtualisation disabled
(XEN) Total of 1 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Allocated console ring of 16 KiB.
(XEN) Brought up 1 CPUs
(XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 32-bit, PAE, lsb
(XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x400000 -> 0xef5000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000038000000->000000003c000000 (158378 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: c0400000->c0ef5000
(XEN) Init. ramdisk: c0ef5000->c2b77a00
(XEN) Phys-Mach map: c2b78000->c2c22aa8
(XEN) Start info: c2c23000->c2c2347c
(XEN) Page tables: c2c24000->c2c41000
(XEN) Boot stack: c2c41000->c2c42000
(XEN) TOTAL: c0000000->c3000000
(XEN) ENTRY ADDRESS: c0a6c000
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM: .............done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 152kB init memory.
title Xen-test (2.6.37-2.xendom0.fc15.i686.PAE)
root (hd0,0)
kernel /xen.gz console=vga dom0_mem=699050 noreboot
module /vmlinuz-2.6.37-2.xendom0.fc15.i686.PAE ro
root=/dev/mapper/vg_elm-LogVol00
rd_MD_UUID=a6e5ac69:727267da:bef42c99:8f44ead1
rd_LVM_LV=vg_elm/LogVol00 rd_LVM_LV=vg_elm/LogVol01 rd_NO_LUKS
rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
KEYTABLE=us rhgb quiet
module /initramfs-2.6.37-2.xendom0.fc15.i686.PAE.img
lspci:
00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller
Hub (rev 02)
00:03.0 PCI bridge: Intel Corporation 82875P/E7210 Processor to PCI to
CSA Bridge (rev 02)
00:06.0 System peripheral: Intel Corporation 82875P/E7210 Processor to
I/O Memory Interface (rev 02)
00:1c.0 PCI bridge: Intel Corporation 6300ESB 64-bit PCI-X Bridge (rev 02)
00:1d.0 USB Controller: Intel Corporation 6300ESB USB Universal Host
Controller (rev 02)
00:1d.4 System peripheral: Intel Corporation 6300ESB Watchdog Timer (rev 02)
00:1d.5 PIC: Intel Corporation 6300ESB I/O Advanced Programmable
Interrupt Controller (rev 02)
00:1d.7 USB Controller: Intel Corporation 6300ESB USB2 Enhanced Host
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 0a)
00:1f.0 ISA bridge: Intel Corporation 6300ESB LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 6300ESB SATA Storage
Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 6300ESB SMBus Controller (rev 02)
01:01.0 Ethernet controller: Intel Corporation 82547GI Gigabit
Ethernet Controller
02:02.0 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 01)
02:02.1 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 01)
03:02.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 09)
03:03.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
03:0e.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
13 years, 3 months
kernel-2.6.37-2.xendom0.fc15 and encrypted / partition
by Digimer
Hi Michael,
I didn't save the original thread when you posted this, so my
apologies for breaking threading. :)
I just tried this kernel on Fedora 14 x86_64 and, like several of the
previous attempts, it simply reboots after xen.gz finishes booting (at
least, this is what I can guess, as the screen is black). This is
despite hearing other report much better success. So I was wondering if
these kernels have been tested against dom0 with an encrypted ext4 root
partition?
I'm going to try the 4.0.2-rc1 xen hypervisor shortly. In the
meantime, is there anything I can do to help narrow down the potential
source of the problem?
Thanks for the continued hard work. :)
--
Digimer
E-Mail: digimer(a)alteeve.com
AN!Whitepapers: http://alteeve.com
Node Assassin: http://nodeassassin.org
13 years, 3 months
Test of kernel-2.6.37-2.xendom0.fc15
by W. Michael Petullo
I just tested kernel-2.6.37-2.xendom0.fc15 on my MacBook 5,1. I was
interested in this build because I have had problems like Marko with
respect to my graphics hardware. The laptop has a nVidia chipset and I
am using the nouveau driver. Previous Dom0 kernels worked but would not
boot into X -- the screen would go blank.
This version improves things a bit. X loads, but the graphics are severely
distorted. I can see a cursor move with my mouse, but it is rendered as
a fuzzy block. A strange symptom is that using Ctrl-Alt-Fx to change to
a text terminal succeeds, but only briefly. After less than one second,
the system again presents distorted X.
Booting with "nomodeset" causes the screen to go blank. The sound coming
from the hard disk makes me think that the boot process is continuing.
As a side note, the Rawhide 2.6.37-1 kernel boots for me in Dom0. Of
course, X does not work with this version either.
--
Mike
:wq
13 years, 3 months
Re: Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4
by W. Michael Petullo
>>>> This kernel works as expected with one exception. The exception has been
>>>> a nagging problem, but I have not reported it because 1) we are using
>>>> a research OS in DomU and 2) we are not clear if the problem is in our
>>>> code, Linux or Xen. But, here are the symptoms:
>>>>
>>>> Occasionally (this seems to correlate to network activity between Dom0
>>>> and DomU), the system becomes unresponsive. I am running the Michael
>>>> Young kernel at runlevel 3 within Dom0 (very little memory used by
>>>> applications). Our OS runs in DomU and is constrained to 128MB of
>>>> memory. When the system is unresponsive, typing a character into a
>>>> Dom0 console take 2-5 seconds to appear on the screen. Likewise, other
>>>> activity is extremely slow. As I mentioned, we have not been able to
>>>> isolate where the problem is. Running, for example, an OpenWrt Linux
>>>> build in DomU does not have this problem.
>>> I have seen something similar, though I don't know where the fault
>>> lies either.
>> That is somewhat good to hear. I have today solved this problem by running
>> "xm vcpu-set Domain-0 1." By default, Xen assigned Dom0 all of my cores
>> (two). Reducing this to one solves the problem for me. I am working on
>> a better write up that I'll send to fedora-xen and possibly the upstream
>> Xen mailing list. I have not decided if this is a bug and am having some
>> discussions locally that may help me formulate a better inquiry.
> Usually it's better to use dom0_max_vcpus=1 on the grub xen.gz line.
So, is this a known "issue." Is it typically best practice to limit Dom0 to
one core? I've seen systems where this is not a problem (dom0_max_vcpus=n
works fine, where n is the number of cores) and others where it is. Why
would this be?
--
Mike
:wq
13 years, 3 months
