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
There is another kernel to play with (2.6.37-0.1.rc1.git8.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2598434 . This has patches from xen/next-2.6.37 , which includes the gntdev module, so it should in theory be possible to use a userspace blkback.
My testing with a no network or disk guest are as successful as I could expect them to be.
Michael Young
If i just want to build fedora kernel for rc1 & git9 script fails due to listnewconfig_fail = 1
Simple hack :- # Should make listnewconfig fail if there's config options # printed out? %if %{nopatches}%{using_upstream_branch} %define listnewconfig_fail 0 %else %define listnewconfig_fail 0 %endif
I would guess, that it shouldn't happen in general.
Boris.
--- On Sat, 11/13/10, M A Young m.a.young@durham.ac.uk wrote:
From: M A Young m.a.young@durham.ac.uk Subject: Re: [Fedora-xen] 2.6.37-rc1 dom0 kernel To: xen@lists.fedoraproject.org Date: Saturday, November 13, 2010, 7:41 AM
There is another kernel to play with (2.6.37-0.1.rc1.git8.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2598434 . This has patches from xen/next-2.6.37 , which includes the gntdev module, so it should in theory be possible to use a userspace blkback.
My testing with a no network or disk guest are as successful as I could expect them to be.
Michael Young -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
On Sat, 13 Nov 2010, Boris Derzhavets wrote:
If i just want to build fedora kernel for rc1 & git9 script fails due to listnewconfig_fail = 1
That means a new configuration option has been added somewhere. If you look through the output of the failed build it will tell you what the new added option is. So an alternative to your workaround is to set this new option in the config files.
Michael Young
It should be correct patch :-
----------------------------------------------------- %define nopatches 1
%if %{nopatches}%{using_upstream_branch} %define listnewconfig_fail 0 %else %define listnewconfig_fail 1 %endif ---------------------------------------------------
Boris.
--- On Sat, 11/13/10, M A Young m.a.young@durham.ac.uk wrote:
From: M A Young m.a.young@durham.ac.uk Subject: Re: [Fedora-xen] 2.6.37-rc1 dom0 kernel To: "Boris Derzhavets" bderzhavets@yahoo.com Cc: xen@lists.fedoraproject.org Date: Saturday, November 13, 2010, 2:49 PM
On Sat, 13 Nov 2010, Boris Derzhavets wrote:
If i just want to build fedora kernel for rc1 & git9 script fails due to listnewconfig_fail = 1
That means a new configuration option has been added somewhere. If you look through the output of the failed build it will tell you what the new added option is. So an alternative to your workaround is to set this new option in the config files.
Michael Young
I've tested the most recent kernel from Michael Young http://koji.fedoraproject.org/koji/taskinfo?taskID=2598434 kernel vmlinuz-2.6.37-0.1.rc1.git8.xendom0.fc14.x86_64(rc1.git8 + xen-next.patch) as Dom0 kernel under Xen 4.0.1 on top of F14. Attempt to work with NFS remote folder results kernel crash again - unable to handle paging request and stack trace.
Kernel works OK only as vanilla.
Boris. P.S. Same issue is in place for PV DomU running kernel vmlinuz-2.6.37-0.1.rc1.git8.xendom0.fc14.x86_64
Today i've built vmlinuz-2.6.37-0.1.rc1.git8.xendom0.fc14.x86_64 via Michael's http://koji.fedoraproject.org/koji/taskinfo?taskID=2598434 and uncommented xen.pcifront.fixes.patch in kernel.spec, i.e.
# Xen patches ApplyPatch xen.next-2.6.37.patch # ApplyPatch xen.upstream.core.patch ApplyPatch xen.pcifront.fixes.patch # ApplyPatch xen.pvhvm.fixes.patch
as a result i got a kernel wich runs pretty stable NFS client at Xen 4.0.1 F14 Dom0 (2.6.32.25-172.xendom0.fc14.x86_64). I was able several times copied from NFS folder F14's ISO image (3.2 GB) to DomU and scp'ed it back and didn't get any kernel crashing on DomU. On Ubuntu 10.04 this kernel may be built as rc1&git8 patched via xen.next-2.6.37.patch xen.pcifront.fixes.patch All required upstream patches may be taken (as well as 2 above) from link http://koji.fedoraproject.org/koji/taskinfo?taskID=2598434 I believe as soon as xen.pcifront.fixes.patch will be accepted by upstream NFS client issue on F14 will be gone
Boris.
--- On Mon, 11/15/10, Boris Derzhavets bderzhavets@yahoo.com wrote:
From: Boris Derzhavets bderzhavets@yahoo.com Subject: Re: [Fedora-xen] 2.6.37-rc1 dom0 kernel To: "M A Young" m.a.young@durham.ac.uk Cc: xen@lists.fedoraproject.org Date: Monday, November 15, 2010, 1:13 PM
I've tested the most recent kernel from Michael Young http://koji.fedoraproject.org/koji/taskinfo?taskID=2598434 kernel vmlinuz-2.6.37-0.1.rc1.git8.xendom0.fc14.x86_64(rc1.git8 + xen-next.patch) as Dom0 kernel under Xen 4.0.1 on top of F14. Attempt to work with NFS remote folder results kernel crash again - unable to handle paging request and stack trace.
Kernel works OK only as vanilla.
Boris. P.S. Same issue is in place for PV DomU running kernel vmlinuz-2.6.37-0.1.rc1.git8.xendom0.fc14.x86_64
-----Inline Attachment Follows-----
-- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
On Sat, Nov 13, 2010 at 6:41 AM, M A Young m.a.young@durham.ac.uk wrote:
There is another kernel to play with (2.6.37-0.1.rc1.git8.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2598434 . This has patches from xen/next-2.6.37 , which includes the gntdev module, so it should in theory be possible to use a userspace blkback.
I still get a dom0 crash, whereas 2.6.32.25-172.xendom0.fc12.i686.PAE works fine on the same hardware with the same command line.
jerry __ __ _ _ ___ _ __ __ _ _ _ \ / /___ _ __ | || | / _ \ / | / /_ / _| ___/ | || | \ // _ \ '_ \ | || |_| | | || |__| '_ \ | |_ / __| | || |_ / \ __/ | | | |__ _| |_| || |__| (_) || _| (__| |__ _| /_/____|_| |_| |_|(_)___(_)_| ___(_)_| ___|_| |_|
(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) Console output is synchronous. (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: console=com1 com1=38400,8n1 console=com1 sync_console loglvl=all guest_loglvl=all (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) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000007ffc0000 (XEN) Xen heap: 8MB (8856kB) (XEN) Domain heap initialised (XEN) found SMP MP-table at 000fe710 (XEN) DMI 2.3 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[7ffcfc0c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 15:3 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled) (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: IOAPIC (id[0x02] address[0xfec10000] gsi_base[24]) (XEN) IOAPIC[1]: apic_id 2, version 32, address 0xfec10000, GSI 24-47 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 2 I/O APICs (XEN) Using ACPI (MADT) for SMP configuration information (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2793.137 MHz processor. (XEN) CPU: Hyper-Threading is disabled (XEN) CPU0: Intel Extended MCE MSRs (12) available (XEN) Intel machine check reporting enabled (XEN) I/O virtualisation disabled (XEN) Total of 1 processors activated. (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (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) ACPI sleep modes: S3 (XEN) mcheck_poll: Machine check polling timer started. (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 32-bit, PAE, lsb (XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x400000 -> 0x15ac000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000038000000->000000003c000000 (468836 pages to be allocated) (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: c0400000->c15ac000 (XEN) Init. ramdisk: c15ac000->c327da00 (XEN) Phys-Mach map: c327e000->c3457d90 (XEN) Start info: c3458000->c345847c (XEN) Page tables: c3459000->c347a000 (XEN) Boot stack: c347a000->c347b000 (XEN) TOTAL: c0000000->c3800000 (XEN) ENTRY ADDRESS: c0b05000 (XEN) Dom0 has maximum 1 VCPUs (XEN) Scrubbing Free RAM: .done. (XEN) trace.c:89:d32767 calc_tinfo_first_offset: NR_CPUs 128, offset_in_bytes 258, t_info_first_offset 65 (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 152kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... (XEN) d0:v0: unhandled page fault (ec=0003) (XEN) Pagetable walk from c0ce001c: (XEN) L3[0x003] = 000000003943f001 0000143f (XEN) L2[0x006] = 000000003b464067 00003464 (XEN) L1[0x0e0] = 0000000038ce0061 00000ce0 (XEN) domain_crash_sync called from entry.S (ff1cda0e) (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-4.0.1 x86_32p debug=n Tainted: C ]---- (XEN) CPU: 0 (XEN) EIP: e019:[<c0b0a9ed>] (XEN) EFLAGS: 00000246 EM: 1 CONTEXT: pv guest (XEN) eax: 00cdd001 ebx: 00000000 ecx: 00000000 edx: 00000000 (XEN) esi: c0ae7000 edi: c0b00cc0 ebp: c0a2ff84 esp: c0a2fee0 (XEN) cr0: 8005003b cr4: 000006f0 cr3: 38ce0000 cr2: c0ce001c (XEN) ds: e021 es: e021 fs: 00d8 gs: 00e0 ss: e021 cs: e019 (XEN) Guest stack trace from esp=c0a2fee0: (XEN) 00000003 c0b0a9ed 0001e019 00010046 00000000 c0446eee c0a2ff74 c0447e87 (XEN) c0a2ff32 c0971737 00000000 00000000 00000000 0000000f 00000000 00000035 (XEN) c0a2ff41 00000000 00000000 c0a2ff40 205bff40 30202020 3030302e c0a2ffa0 (XEN) c0a20020 c0470186 00000000 c1349428 c1349400 c0984979 0327e000 c0a2ff74 (XEN) c0601371 03bb2a03 00000000 00000000 0327e000 03bb2a03 00000000 00000000 (XEN) 0327e000 c0a2ffa8 c0b05592 c0961622 c0832010 c040385c 03bb2a03 a9827a8d (XEN) 015ac000 015ac000 c0a2ffc8 c0b050ec 0327e000 00000000 c096383a 00409000 (XEN) 015ac000 c0aa6b7c c0a2fffc c0b088be c0a2ffe4 c0a2ffe0 92400018 c04090cd (XEN) 1fc98375 80000401 00010800 00000f34 00000000 c3458000 00000000 00000000 (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
Here is another kernel (kernel-2.6.37-0.1.rc2.git0.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2605399
It has updated patches from xen/next-2.6.37 and xen-pcifront-fixes (some of the previous patches made it into the mainline kernel).
I am still seeing a long delay with a totally blank screen, but it does boot eventually.
Michael Young
Thank you for this build.
Boris.
--- On Tue, 11/16/10, M A Young m.a.young@durham.ac.uk wrote:
From: M A Young m.a.young@durham.ac.uk Subject: [Fedora-xen] 2.6.37-rc2 dom0 kernel To: xen@lists.fedoraproject.org Date: Tuesday, November 16, 2010, 7:45 PM
Here is another kernel (kernel-2.6.37-0.1.rc2.git0.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2605399
It has updated patches from xen/next-2.6.37 and xen-pcifront-fixes (some of the previous patches made it into the mainline kernel).
I am still seeing a long delay with a totally blank screen, but it does boot eventually.
Michael Young -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Here is an rc3 kernel (2.6.37-0.rc3.git0.1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2617730
It updates to the latest next-2.6.37 patch. I haven't tested it yet.
Michael Young
On 11/22/2010 07:28 PM, M A Young wrote:
Here is an rc3 kernel (2.6.37-0.rc3.git0.1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2617730
It updates to the latest next-2.6.37 patch. I haven't tested it yet.
Michael Young
I compiled and installed this and your latest 2.6.32 (174) kernel today. In both cases, on boot at the point where it should scrub the RAM, my system reboots.
My '/' partition is encrypted (ext4), perhaps this is the cause? If not, what could I do to help trace the problem?
Thanks!
On 11/30/2010 05:40 PM, Digimer wrote:
On 11/22/2010 07:28 PM, M A Young wrote:
Here is an rc3 kernel (2.6.37-0.rc3.git0.1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2617730
It updates to the latest next-2.6.37 patch. I haven't tested it yet.
Michael Young
I compiled and installed this and your latest 2.6.32 (174) kernel today. In both cases, on boot at the point where it should scrub the RAM, my system reboots.
My '/' partition is encrypted (ext4), perhaps this is the cause? If not, what could I do to help trace the problem?
Thanks!
Sorry, should have mentioned; It's a Fedora 14 x86_64, lenovo T400s in case it matters. :)
Here is another kernel to test (2.6.37-0.rc4.git1.1.xendom0.fc15). This one has the latest xen/next-2.6.37 patches and is at http://koji.fedoraproject.org/koji/taskinfo?taskID=2639879 .
Michael Young
Here is another kernel to test (2.6.37-0.rc5.git0.1xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2651458 with the latest xen/next-2.6.37 patches.
Michael Young
There is a 2.6.37 kernel to test (2.6.37-1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2703408 I have had mixed success with this as the kernel package doesn't boot, but the kernel-debug package does boot to runlevel 3 (albeit with the couple of minutes delay which I have been seeing in the 2.6.37-rc kernels).
Michael Young
On Wed, Jan 05, 2011 at 11:18:59PM +0000, M A Young wrote:
There is a 2.6.37 kernel to test (2.6.37-1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2703408 I have had mixed success with this as the kernel package doesn't boot, but the kernel-debug package does boot to runlevel 3 (albeit with the couple of minutes delay which I have been seeing in the 2.6.37-rc kernels).
2.6.37-1.xendom0.fc15 x86_64 boots as dom0 for me! I'm using the F14 xen-4.0.1-6 as the hypervisor.
The "only" problem is the display goes all blank when dom0 kernel is booted - I need to check what's going on.
(yeah, I have "nomodeset" specified).
-- Pasi
On Thu, Jan 06, 2011 at 05:20:37PM +0200, Pasi Kärkkäinen wrote:
On Wed, Jan 05, 2011 at 11:18:59PM +0000, M A Young wrote:
There is a 2.6.37 kernel to test (2.6.37-1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2703408 I have had mixed success with this as the kernel package doesn't boot, but the kernel-debug package does boot to runlevel 3 (albeit with the couple of minutes delay which I have been seeing in the 2.6.37-rc kernels).
2.6.37-1.xendom0.fc15 x86_64 boots as dom0 for me! I'm using the F14 xen-4.0.1-6 as the hypervisor.
The "only" problem is the display goes all blank when dom0 kernel is booted - I need to check what's going on.
(yeah, I have "nomodeset" specified).
Forget that, it seems even kms modesetting works with dom0_mem=1024M!
-- Pasi
xen@lists.stg.fedoraproject.org