xen January 2011

xen@lists.fedoraproject.org

10 participants
15 discussions

fc15 xendom0, xen-4.0.1-6.fc14.i686, ATI Rage XL
by Jerry Amundson 12 Jan '11

12 Jan '11

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)

2 1

kernel-2.6.37-2.xendom0.fc15 and encrypted / partition
by Digimer 11 Jan '11

11 Jan '11

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

2 2

Test of kernel-2.6.37-2.xendom0.fc15
by W. Michael Petullo 10 Jan '11

10 Jan '11

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

2 1

2.6.37-rc1 dom0 kernel
by M A Young 07 Jan '11

07 Jan '11

I have built another test kernel (2.6.37-0.1.rc1.git0.xendom0.fc15) to play with at http://koji.fedoraproject.org/koji/taskinfo?taskID=2581020 . As with the previous kernel this is entirely based on the upstream kernel and Fedora kernel patches, and is probably close to what the Fedora 15 kernel will look like soon. I haven't tested it yet. Michael Young

5 17

Re: Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4
by W. Michael Petullo 03 Jan '11

03 Jan '11

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

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xen January 2011