2.6.37-rc1 dom0 kernel

[M A Young]

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

[M A 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

[Boris Derzhavets]

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

From: M A Young 
Subject: Re: [Fedora-xen] 2.6.37-rc1 dom0 kernel
To: [e-mail]
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
[e-mail]
https://admin.fedoraproject.org/mailman/listinfo/xen

[M A Young]

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

[Boris Derzhavets]

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

From: M A Young 
Subject: Re: [Fedora-xen] 2.6.37-rc1 dom0 kernel
To: "Boris Derzhavets" 
Cc: [e-mail]
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

[Boris Derzhavets]

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

[Boris Derzhavets]

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

From: Boris Derzhavets 
Subject: Re: [Fedora-xen] 2.6.37-rc1 dom0 kernel
To: "M A Young" 
Cc: [e-mail]
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
[e-mail]
https://admin.fedoraproject.org/mailman/listinfo/xen

[Jerry Amundson]

On Sat, Nov 13, 2010 at 6:41 AM, M A Young  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.

2.6.37-rc2 dom0 kernel

[M A Young]

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

2.6.37-rc2 dom0 kernel

[Boris Derzhavets]

Thank you for this build.

Boris.

--- On Tue, 11/16/10, M A Young  wrote:

From: M A Young 
Subject: [Fedora-xen] 2.6.37-rc2 dom0 kernel
To: [e-mail]
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
[e-mail]
https://admin.fedoraproject.org/mailman/listinfo/xen

2.6.37-rc3 dom0 kernel

[M A Young]

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

2.6.37-rc3 dom0 kernel

[Digimer]

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!

2.6.37-rc3 dom0 kernel

[Digimer]

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. :)

2.6.37-rc4-git1 dom0 kernel

[M A Young]

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

2.6.37-rc5 dom0 kernel

[M A 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

2.6.37 dom0 kernel

[M A 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

2.6.37 dom0 kernel

[Pasi Kärkkäinen]

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

2.6.37 dom0 kernel

[Pasi Kärkkäinen]

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