All of lore.kernel.org
 help / color / mirror / Atom feed
* kernel BUG at arch/x86/xen/multicalls.c:103!
@ 2009-08-03  9:44 Olivier NOEL
  2009-08-04 23:55 ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 14+ messages in thread
From: Olivier NOEL @ 2009-08-03  9:44 UTC (permalink / raw)
  To: xen-devel

Hi,

I have this bug when I activate java-6-jdk on Tomcat 5.5.26 in a Lenny Guest :

Jul 31 21:24:15 tomcat01 kernel: 1 multicall(s) failed: cpu 3
Jul 31 21:24:15 tomcat01 kernel:   call  1/1: op=14 arg=[b7f1a000] result=-22
Jul 31 21:24:15 tomcat01 kernel: ------------[ cut here ]------------
Jul 31 21:24:15 tomcat01 kernel: kernel BUG at arch/x86/xen/multicalls.c:103!
Jul 31 21:24:15 tomcat01 kernel: invalid opcode: 0000 [#1] SMP
Jul 31 21:24:15 tomcat01 kernel:
Jul 31 21:24:15 tomcat01 kernel: Pid: 2467, comm: jsvc Not tainted (2.6.25.7 #1)
Jul 31 21:24:15 tomcat01 kernel: EIP: 0061:[<c020248b>] EFLAGS: 00010202 CPU: 3
Jul 31 21:24:15 tomcat01 kernel: EIP is at xen_mc_flush+0x16b/0x180
Jul 31 21:24:15 tomcat01 kernel: EAX: 00000000 EBX: 00000000 ECX: 00000003 EDX: 00000000
Jul 31 21:24:15 tomcat01 kernel: ESI: 00000000 EDI: 00000001 EBP: c141a060 ESP: deaadedc
Jul 31 21:24:15 tomcat01 kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
Jul 31 21:24:15 tomcat01 kernel: Process jsvc (pid: 2467, ti=deaac000 task=df6e6000 task.ti=deaac000)
Jul 31 21:24:15 tomcat01 kernel: Stack: c05a5848 00000001 00000001 0000000e b7f1a000 ffffffea 00000200 00000065
Jul 31 21:24:15 tomcat01 kernel:        00000000 00000000 b7f1a000 c02592b4 00000065 00000000 df5c3f50 00000000
Jul 31 21:24:15 tomcat01 kernel:        000b7f1a 00000000 00000000 de827e34 df616210 de827e00 b7f1b000 df616528
Jul 31 21:24:15 tomcat01 kernel: Call Trace:
Jul 31 21:24:15 tomcat01 kernel:  [<c02592b4>] mprotect_fixup+0x4b4/0x610
Jul 31 21:24:15 tomcat01 kernel:  [<c0259554>] sys_mprotect+0x144/0x1d0
Jul 31 21:24:15 tomcat01 kernel:  [<c0206c22>] syscall_call+0x7/0xb
Jul 31 21:24:15 tomcat01 kernel:  =======================
Jul 31 21:24:15 tomcat01 kernel: Code: 00 83 c3 20 89 54 24 08 89 74 24 04 c7 04 24 48 58 5a c0 89 44 24 0c e8 84 fc 01 00 8b 95 00 0b 00 00 39 d6 72 c3 e9 25 ff ff ff <0f> 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 8d bc 27 00 00 00 00
Jul 31 21:24:15 tomcat01 kernel: EIP: [<c020248b>] xen_mc_flush+0x16b/0x180 SS:ESP 0069:deaadedc
Jul 31 21:24:15 tomcat01 kernel: ---[ end trace 9edfe58cbc53ddca ]---


More infos on host OS:

11:39 root@host:~# xm info
host                   : host.ovh.net
release                : 2.6.21.7-xxxx-xen0-ipv4-64
version                : #1 SMP Mon Apr 28 10:19:16 CEST 2008
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2817
hw_caps                : bfebfbff:20100800:00000000:00000140:0008e3fd:00000000:00000001
total_memory           : 8181
free_memory            : 6
node_to_cpu            : node0:0-3
xen_major              : 3
xen_minor              : 2
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : Fri Apr 25 14:03:45 2008 +0100 16881:4073b3ded545
cc_compiler            : gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
cc_compile_by          : root
cc_compile_domain      : ovh.net
cc_compile_date        : Mon Apr 28 09:51:46 CEST 2008
xend_config_format     : 4




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: kernel BUG at arch/x86/xen/multicalls.c:103!
  2009-08-03  9:44 kernel BUG at arch/x86/xen/multicalls.c:103! Olivier NOEL
@ 2009-08-04 23:55 ` Jeremy Fitzhardinge
  2009-08-05  7:10   ` Olivier NOEL
  0 siblings, 1 reply; 14+ messages in thread
From: Jeremy Fitzhardinge @ 2009-08-04 23:55 UTC (permalink / raw)
  To: Olivier NOEL; +Cc: xen-devel

On 08/03/09 02:44, Olivier NOEL wrote:
> Hi,
>
> I have this bug when I activate java-6-jdk on Tomcat 5.5.26 in a Lenny Guest :
>   

Does it happen immediately, or after a while?  Does it happen every
time?  How many VCPUs are there?

> Jul 31 21:24:15 tomcat01 kernel: 1 multicall(s) failed: cpu 3
> Jul 31 21:24:15 tomcat01 kernel:   call  1/1: op=14 arg=[b7f1a000] result=-22
> Jul 31 21:24:15 tomcat01 kernel: ------------[ cut here ]------------
> Jul 31 21:24:15 tomcat01 kernel: kernel BUG at arch/x86/xen/multicalls.c:103!
> Jul 31 21:24:15 tomcat01 kernel: invalid opcode: 0000 [#1] SMP
> Jul 31 21:24:15 tomcat01 kernel:
> Jul 31 21:24:15 tomcat01 kernel: Pid: 2467, comm: jsvc Not tainted (2.6.25.7 #1)
> Jul 31 21:24:15 tomcat01 kernel: EIP: 0061:[<c020248b>] EFLAGS: 00010202 CPU: 3
> Jul 31 21:24:15 tomcat01 kernel: EIP is at xen_mc_flush+0x16b/0x180
> Jul 31 21:24:15 tomcat01 kernel: EAX: 00000000 EBX: 00000000 ECX: 00000003 EDX: 00000000
> Jul 31 21:24:15 tomcat01 kernel: ESI: 00000000 EDI: 00000001 EBP: c141a060 ESP: deaadedc
> Jul 31 21:24:15 tomcat01 kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
> Jul 31 21:24:15 tomcat01 kernel: Process jsvc (pid: 2467, ti=deaac000 task=df6e6000 task.ti=deaac000)
> Jul 31 21:24:15 tomcat01 kernel: Stack: c05a5848 00000001 00000001 0000000e b7f1a000 ffffffea 00000200 00000065
> Jul 31 21:24:15 tomcat01 kernel:        00000000 00000000 b7f1a000 c02592b4 00000065 00000000 df5c3f50 00000000
> Jul 31 21:24:15 tomcat01 kernel:        000b7f1a 00000000 00000000 de827e34 df616210 de827e00 b7f1b000 df616528
> Jul 31 21:24:15 tomcat01 kernel: Call Trace:
> Jul 31 21:24:15 tomcat01 kernel:  [<c02592b4>] mprotect_fixup+0x4b4/0x610
> Jul 31 21:24:15 tomcat01 kernel:  [<c0259554>] sys_mprotect+0x144/0x1d0
> Jul 31 21:24:15 tomcat01 kernel:  [<c0206c22>] syscall_call+0x7/0xb
> Jul 31 21:24:15 tomcat01 kernel:  =======================
> Jul 31 21:24:15 tomcat01 kernel: Code: 00 83 c3 20 89 54 24 08 89 74 24 04 c7 04 24 48 58 5a c0 89 44 24 0c e8 84 fc 01 00 8b 95 00 0b 00 00 39 d6 72 c3 e9 25 ff ff ff <0f> 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 8d bc 27 00 00 00 00
> Jul 31 21:24:15 tomcat01 kernel: EIP: [<c020248b>] xen_mc_flush+0x16b/0x180 SS:ESP 0069:deaadedc
> Jul 31 21:24:15 tomcat01 kernel: ---[ end trace 9edfe58cbc53ddca ]---
>
>   

Do you get any messages on the Xen console (xm dmesg)?

    J

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: kernel BUG at arch/x86/xen/multicalls.c:103!
  2009-08-04 23:55 ` Jeremy Fitzhardinge
@ 2009-08-05  7:10   ` Olivier NOEL
  2009-08-06  6:50     ` Olivier NOEL
  0 siblings, 1 reply; 14+ messages in thread
From: Olivier NOEL @ 2009-08-05  7:10 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 9632 bytes --]

> -----Message d'origine-----
> De : xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] De la part de Jeremy Fitzhardinge
> Envoyé : mercredi 5 août 2009 01:55
> À : Olivier NOEL
> Cc : xen-devel@lists.xensource.com
> Objet : Re: [Xen-devel] kernel BUG at arch/x86/xen/multicalls.c:103!
> 
> On 08/03/09 02:44, Olivier NOEL wrote:
> > Hi,
> >
> > I have this bug when I activate java-6-jdk on Tomcat 5.5.26 in a
> Lenny Guest :
> >
> 
> Does it happen immediately, or after a while?  Does it happen every
> time?  How many VCPUs are there?

At boot time, Tomcat is not running, so I start Tomcat and I have this error. Then I can't do anything, the system is "locked".

It happens every time I start Tomcat with any java runtime which is not java-gcj on Debian Lenny or Etch.

There are 4 VCPUs on each Tomcat.

> 
> > Jul 31 21:24:15 tomcat01 kernel: 1 multicall(s) failed: cpu 3
> > Jul 31 21:24:15 tomcat01 kernel:   call  1/1: op=14 arg=[b7f1a000]
> result=-22
> > Jul 31 21:24:15 tomcat01 kernel: ------------[ cut here ]------------
> > Jul 31 21:24:15 tomcat01 kernel: kernel BUG at
> arch/x86/xen/multicalls.c:103!
> > Jul 31 21:24:15 tomcat01 kernel: invalid opcode: 0000 [#1] SMP
> > Jul 31 21:24:15 tomcat01 kernel:
> > Jul 31 21:24:15 tomcat01 kernel: Pid: 2467, comm: jsvc Not tainted
> (2.6.25.7 #1)
> > Jul 31 21:24:15 tomcat01 kernel: EIP: 0061:[<c020248b>] EFLAGS:
> 00010202 CPU: 3
> > Jul 31 21:24:15 tomcat01 kernel: EIP is at xen_mc_flush+0x16b/0x180
> > Jul 31 21:24:15 tomcat01 kernel: EAX: 00000000 EBX: 00000000 ECX:
> 00000003 EDX: 00000000
> > Jul 31 21:24:15 tomcat01 kernel: ESI: 00000000 EDI: 00000001 EBP:
> c141a060 ESP: deaadedc
> > Jul 31 21:24:15 tomcat01 kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033
> SS: 0069
> > Jul 31 21:24:15 tomcat01 kernel: Process jsvc (pid: 2467, ti=deaac000
> task=df6e6000 task.ti=deaac000)
> > Jul 31 21:24:15 tomcat01 kernel: Stack: c05a5848 00000001 00000001
> 0000000e b7f1a000 ffffffea 00000200 00000065
> > Jul 31 21:24:15 tomcat01 kernel:        00000000 00000000 b7f1a000
> c02592b4 00000065 00000000 df5c3f50 00000000
> > Jul 31 21:24:15 tomcat01 kernel:        000b7f1a 00000000 00000000
> de827e34 df616210 de827e00 b7f1b000 df616528
> > Jul 31 21:24:15 tomcat01 kernel: Call Trace:
> > Jul 31 21:24:15 tomcat01 kernel:  [<c02592b4>]
> mprotect_fixup+0x4b4/0x610
> > Jul 31 21:24:15 tomcat01 kernel:  [<c0259554>]
> sys_mprotect+0x144/0x1d0
> > Jul 31 21:24:15 tomcat01 kernel:  [<c0206c22>] syscall_call+0x7/0xb
> > Jul 31 21:24:15 tomcat01 kernel:  =======================
> > Jul 31 21:24:15 tomcat01 kernel: Code: 00 83 c3 20 89 54 24 08 89 74
> 24 04 c7 04 24 48 58 5a c0 89 44 24 0c e8 84 fc 01 00 8b 95 00 0b 00 00
> 39 d6 72 c3 e9 25 ff ff ff <0f> 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00
> 8d bc 27 00 00 00 00
> > Jul 31 21:24:15 tomcat01 kernel: EIP: [<c020248b>]
> xen_mc_flush+0x16b/0x180 SS:ESP 0069:deaadedc
> > Jul 31 21:24:15 tomcat01 kernel: ---[ end trace 9edfe58cbc53ddca ]---
> >
> >
> 
> Do you get any messages on the Xen console (xm dmesg)?

xm dmesg (complete dmesg) :

(XEN) Xen version 3.2.1 (root@ovh.net) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) Mon Apr 28 09:51:46 CEST 2008
(XEN) Latest ChangeSet: Fri Apr 25 14:03:45 2008 +0100 16881:4073b3ded545
(XEN) Command line: auto BOOT_IMAGE=Xen ro root=801
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000008f000 (usable)
(XEN)  000000000008f000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cf543000 (usable)
(XEN)  00000000cf543000 - 00000000cf54f000 (reserved)
(XEN)  00000000cf54f000 - 00000000cf617000 (usable)
(XEN)  00000000cf617000 - 00000000cf6e8000 (ACPI NVS)
(XEN)  00000000cf6e8000 - 00000000cf6eb000 (usable)
(XEN)  00000000cf6eb000 - 00000000cf6f0000 (ACPI data)
(XEN)  00000000cf6f0000 - 00000000cf6f1000 (usable)
(XEN)  00000000cf6f1000 - 00000000cf6ff000 (ACPI data)
(XEN)  00000000cf6ff000 - 00000000cf700000 (usable)
(XEN)  00000000cf700000 - 00000000d0000000 (reserved)
(XEN)  00000000fff00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000230000000 (usable)
(XEN) System RAM: 8181MB (8377980kB)
(XEN) Xen heap: 14MB (14824kB)
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #2 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) Processor #3 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2817.262 MHz processor.
(XEN) HVM: VMX enabled
(XEN) CPU0: Intel(R) Xeon(R) CPU           X3360  @ 2.83GHz stepping 07
(XEN) Booting processor 1/2 eip 8c000
(XEN) CPU1: Intel(R) Xeon(R) CPU           X3360  @ 2.83GHz stepping 07
(XEN) Booting processor 2/1 eip 8c000
(XEN) CPU2: Intel(R) Xeon(R) CPU           X3360  @ 2.83GHz stepping 07
(XEN) Booting processor 3/3 eip 8c000
(XEN) CPU3: Intel(R) Xeon(R) CPU           X3360  @ 2.83GHz stepping 07
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) Platform timer overflows in 14998 jiffies.
(XEN) Platform timer is 14.318MHz HPET
(XEN) Brought up 4 CPUs
(XEN) xenoprof: Initialization failed. Intel processor model 23 for P6 class family is not supported
(XEN) AMD IOMMU: Disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 -> 0xffffffff8093981c
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000226000000->0000000228000000 (2019706 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80200000->ffffffff8093981c
(XEN)  Init. ramdisk: ffffffff8093a000->ffffffff8093a000
(XEN)  Phys-Mach map: ffffffff8093a000->ffffffff818b2bd0
(XEN)  Start info:    ffffffff818b3000->ffffffff818b34a4
(XEN)  Page tables:   ffffffff818b4000->ffffffff818c5000
(XEN)  Boot stack:    ffffffff818c5000->ffffffff818c6000
(XEN)  TOTAL:         ffffffff80000000->ffffffff81c00000
(XEN)  ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 4 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 100kB init memory.
(XEN) mm.c:665:d14 Error getting mfn a7990 (pfn 22df) from L1 entry 00000000a7990065 for dom14
(XEN) mm.c:645:d14 Non-privileged (14) attempt to map I/O space 64612064
(XEN) mm.c:665:d14 Error getting mfn 1001d3 (pfn 128bd3) from L1 entry 00000001001d3065 for dom14
(XEN) mm.c:645:d21 Non-privileged (21) attempt to map I/O space 00000000
(XEN) mm.c:645:d23 Non-privileged (23) attempt to map I/O space 00000000
(XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space 0d000000
(XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space 49464655
(XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space 00000000
(XEN) mm.c:645:d23 Non-privileged (23) attempt to map I/O space 00000000
(XEN) mm.c:645:d23 Non-privileged (23) attempt to map I/O space 00000000
(XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space 72202020
(XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space 2c222220
(XEN) mm.c:645:d23 Non-privileged (23) attempt to map I/O space 00000000
(XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space 00000000
(XEN) mm.c:645:d24 Non-privileged (24) attempt to map I/O space 00000000
(XEN) mm.c:645:d25 Non-privileged (25) attempt to map I/O space 00000000
(XEN) mm.c:645:d25 Non-privileged (25) attempt to map I/O space 00000000
(XEN) mm.c:645:d24 Non-privileged (24) attempt to map I/O space 00000000
(XEN) mm.c:645:d26 Non-privileged (26) attempt to map I/O space 00000000
(XEN) mm.c:645:d25 Non-privileged (25) attempt to map I/O space 00000000
(XEN) mm.c:645:d26 Non-privileged (26) attempt to map I/O space 00000000
(XEN) mm.c:645:d26 Non-privileged (26) attempt to map I/O space 00000000
(XEN) mm.c:645:d27 Non-privileged (27) attempt to map I/O space 00000000
(XEN) mm.c:645:d27 Non-privileged (27) attempt to map I/O space 00000000
(XEN) mm.c:645:d28 Non-privileged (28) attempt to map I/O space 00000000
(XEN) mm.c:645:d28 Non-privileged (28) attempt to map I/O space 00000000
(XEN) mm.c:645:d27 Non-privileged (27) attempt to map I/O space 00000000
(XEN) mm.c:645:d31 Non-privileged (31) attempt to map I/O space 00000000
(XEN) mm.c:645:d31 Non-privileged (31) attempt to map I/O space 00000000
(XEN) mm.c:645:d31 Non-privileged (31) attempt to map I/O space 00000000
(XEN) mm.c:645:d43 Non-privileged (43) attempt to map I/O space 13f14490
(XEN) mm.c:645:d47 Non-privileged (47) attempt to map I/O space 00000000
(XEN) mm.c:645:d48 Non-privileged (48) attempt to map I/O space 00000000

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: kernel BUG at arch/x86/xen/multicalls.c:103!
  2009-08-05  7:10   ` Olivier NOEL
@ 2009-08-06  6:50     ` Olivier NOEL
  2009-08-06 19:35       ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 14+ messages in thread
From: Olivier NOEL @ 2009-08-06  6:50 UTC (permalink / raw)
  To: Olivier NOEL, xen-devel

[-- Attachment #1: Type: text/plain, Size: 12744 bytes --]

> -----Message d'origine-----
> De : xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] De la part de Olivier NOEL
> Envoyé : mercredi 5 août 2009 09:10
> À : xen-devel@lists.xensource.com
> Objet : RE: [Xen-devel] kernel BUG at arch/x86/xen/multicalls.c:103!
> 
> > -----Message d'origine-----
> > De : xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] De la part de Jeremy Fitzhardinge
> Envoyé
> > : mercredi 5 août 2009 01:55 À : Olivier NOEL Cc :
> > xen-devel@lists.xensource.com Objet : Re: [Xen-devel] kernel BUG at
> > arch/x86/xen/multicalls.c:103!
> >
> > On 08/03/09 02:44, Olivier NOEL wrote:
> > > Hi,
> > >
> > > I have this bug when I activate java-6-jdk on Tomcat 5.5.26 in a
> > Lenny Guest :
> > >
> >
> > Does it happen immediately, or after a while?  Does it happen every
> > time?  How many VCPUs are there?
> 
> At boot time, Tomcat is not running, so I start Tomcat and I have this
> error. Then I can't do anything, the system is "locked".
> 
> It happens every time I start Tomcat with any java runtime which is not
> java-gcj on Debian Lenny or Etch.
> 
> There are 4 VCPUs on each Tomcat.
> 
> >
> > > Jul 31 21:24:15 tomcat01 kernel: 1 multicall(s) failed: cpu 3
> > > Jul 31 21:24:15 tomcat01 kernel:   call  1/1: op=14 arg=[b7f1a000]
> > result=-22
> > > Jul 31 21:24:15 tomcat01 kernel: ------------[ cut here
> > > ]------------ Jul 31 21:24:15 tomcat01 kernel: kernel BUG at
> > arch/x86/xen/multicalls.c:103!
> > > Jul 31 21:24:15 tomcat01 kernel: invalid opcode: 0000 [#1] SMP Jul
> > > 31 21:24:15 tomcat01 kernel:
> > > Jul 31 21:24:15 tomcat01 kernel: Pid: 2467, comm: jsvc Not tainted
> > (2.6.25.7 #1)
> > > Jul 31 21:24:15 tomcat01 kernel: EIP: 0061:[<c020248b>] EFLAGS:
> > 00010202 CPU: 3
> > > Jul 31 21:24:15 tomcat01 kernel: EIP is at xen_mc_flush+0x16b/0x180
> > > Jul 31 21:24:15 tomcat01 kernel: EAX: 00000000 EBX: 00000000 ECX:
> > 00000003 EDX: 00000000
> > > Jul 31 21:24:15 tomcat01 kernel: ESI: 00000000 EDI: 00000001 EBP:
> > c141a060 ESP: deaadedc
> > > Jul 31 21:24:15 tomcat01 kernel:  DS: 007b ES: 007b FS: 00d8 GS:
> > > 0033
> > SS: 0069
> > > Jul 31 21:24:15 tomcat01 kernel: Process jsvc (pid: 2467,
> > > ti=deaac000
> > task=df6e6000 task.ti=deaac000)
> > > Jul 31 21:24:15 tomcat01 kernel: Stack: c05a5848 00000001 00000001
> > 0000000e b7f1a000 ffffffea 00000200 00000065
> > > Jul 31 21:24:15 tomcat01 kernel:        00000000 00000000 b7f1a000
> > c02592b4 00000065 00000000 df5c3f50 00000000
> > > Jul 31 21:24:15 tomcat01 kernel:        000b7f1a 00000000 00000000
> > de827e34 df616210 de827e00 b7f1b000 df616528
> > > Jul 31 21:24:15 tomcat01 kernel: Call Trace:
> > > Jul 31 21:24:15 tomcat01 kernel:  [<c02592b4>]
> > mprotect_fixup+0x4b4/0x610
> > > Jul 31 21:24:15 tomcat01 kernel:  [<c0259554>]
> > sys_mprotect+0x144/0x1d0
> > > Jul 31 21:24:15 tomcat01 kernel:  [<c0206c22>] syscall_call+0x7/0xb
> > > Jul 31 21:24:15 tomcat01 kernel:  ======================= Jul 31
> > > 21:24:15 tomcat01 kernel: Code: 00 83 c3 20 89 54 24 08 89 74
> > 24 04 c7 04 24 48 58 5a c0 89 44 24 0c e8 84 fc 01 00 8b 95 00 0b 00
> > 00
> > 39 d6 72 c3 e9 25 ff ff ff <0f> 0b eb fe 0f 0b eb fe 8d b6 00 00 00
> 00
> > 8d bc 27 00 00 00 00
> > > Jul 31 21:24:15 tomcat01 kernel: EIP: [<c020248b>]
> > xen_mc_flush+0x16b/0x180 SS:ESP 0069:deaadedc
> > > Jul 31 21:24:15 tomcat01 kernel: ---[ end trace 9edfe58cbc53ddca
> > > ]---
> > >
> > >
> >
> > Do you get any messages on the Xen console (xm dmesg)?
> 
> xm dmesg (complete dmesg) :
> 
> (XEN) Xen version 3.2.1 (root@ovh.net) (gcc version 4.1.2 20061115
> (prerelease) (Debian 4.1.1-21)) Mon Apr 28 09:51:46 CEST 2008
> (XEN) Latest ChangeSet: Fri Apr 25 14:03:45 2008 +0100
> 16881:4073b3ded545
> (XEN) Command line: auto BOOT_IMAGE=Xen ro root=801
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
> (XEN)  EDID info not retrieved because no DDC retrieval method detected
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000008f000 (usable)
> (XEN)  000000000008f000 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 00000000cf543000 (usable)
> (XEN)  00000000cf543000 - 00000000cf54f000 (reserved)
> (XEN)  00000000cf54f000 - 00000000cf617000 (usable)
> (XEN)  00000000cf617000 - 00000000cf6e8000 (ACPI NVS)
> (XEN)  00000000cf6e8000 - 00000000cf6eb000 (usable)
> (XEN)  00000000cf6eb000 - 00000000cf6f0000 (ACPI data)
> (XEN)  00000000cf6f0000 - 00000000cf6f1000 (usable)
> (XEN)  00000000cf6f1000 - 00000000cf6ff000 (ACPI data)
> (XEN)  00000000cf6ff000 - 00000000cf700000 (usable)
> (XEN)  00000000cf700000 - 00000000d0000000 (reserved)
> (XEN)  00000000fff00000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000230000000 (usable)
> (XEN) System RAM: 8181MB (8377980kB)
> (XEN) Xen heap: 14MB (14824kB)
> (XEN) Domain heap initialised: DMA width 32 bits
> (XEN) Processor #0 7:7 APIC version 20
> (XEN) Processor #2 7:7 APIC version 20
> (XEN) Processor #1 7:7 APIC version 20
> (XEN) Processor #3 7:7 APIC version 20
> (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2817.262 MHz processor.
> (XEN) HVM: VMX enabled
> (XEN) CPU0: Intel(R) Xeon(R) CPU           X3360  @ 2.83GHz stepping 07
> (XEN) Booting processor 1/2 eip 8c000
> (XEN) CPU1: Intel(R) Xeon(R) CPU           X3360  @ 2.83GHz stepping 07
> (XEN) Booting processor 2/1 eip 8c000
> (XEN) CPU2: Intel(R) Xeon(R) CPU           X3360  @ 2.83GHz stepping 07
> (XEN) Booting processor 3/3 eip 8c000
> (XEN) CPU3: Intel(R) Xeon(R) CPU           X3360  @ 2.83GHz stepping 07
> (XEN) Total of 4 processors activated.
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using new ACK method
> (XEN) Platform timer overflows in 14998 jiffies.
> (XEN) Platform timer is 14.318MHz HPET
> (XEN) Brought up 4 CPUs
> (XEN) xenoprof: Initialization failed. Intel processor model 23 for P6
> class family is not supported
> (XEN) AMD IOMMU: Disabled
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN)  Xen  kernel: 64-bit, lsb, compat32
> (XEN)  Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 ->
> 0xffffffff8093981c
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   0000000226000000->0000000228000000 (2019706 pages
> to be allocated)
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  Loaded kernel: ffffffff80200000->ffffffff8093981c
> (XEN)  Init. ramdisk: ffffffff8093a000->ffffffff8093a000
> (XEN)  Phys-Mach map: ffffffff8093a000->ffffffff818b2bd0
> (XEN)  Start info:    ffffffff818b3000->ffffffff818b34a4
> (XEN)  Page tables:   ffffffff818b4000->ffffffff818c5000
> (XEN)  Boot stack:    ffffffff818c5000->ffffffff818c6000
> (XEN)  TOTAL:         ffffffff80000000->ffffffff81c00000
> (XEN)  ENTRY ADDRESS: ffffffff80200000
> (XEN) Dom0 has maximum 4 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 100kB init memory.
> (XEN) mm.c:665:d14 Error getting mfn a7990 (pfn 22df) from L1 entry
> 00000000a7990065 for dom14
> (XEN) mm.c:645:d14 Non-privileged (14) attempt to map I/O space
> 64612064
> (XEN) mm.c:665:d14 Error getting mfn 1001d3 (pfn 128bd3) from L1 entry
> 00000001001d3065 for dom14
> (XEN) mm.c:645:d21 Non-privileged (21) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d23 Non-privileged (23) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space
> 0d000000
> (XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space
> 49464655
> (XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d23 Non-privileged (23) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d23 Non-privileged (23) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space
> 72202020
> (XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space
> 2c222220
> (XEN) mm.c:645:d23 Non-privileged (23) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d22 Non-privileged (22) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d24 Non-privileged (24) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d25 Non-privileged (25) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d25 Non-privileged (25) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d24 Non-privileged (24) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d26 Non-privileged (26) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d25 Non-privileged (25) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d26 Non-privileged (26) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d26 Non-privileged (26) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d27 Non-privileged (27) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d27 Non-privileged (27) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d28 Non-privileged (28) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d28 Non-privileged (28) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d27 Non-privileged (27) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d31 Non-privileged (31) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d31 Non-privileged (31) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d31 Non-privileged (31) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d43 Non-privileged (43) attempt to map I/O space
> 13f14490
> (XEN) mm.c:645:d47 Non-privileged (47) attempt to map I/O space
> 00000000
> (XEN) mm.c:645:d48 Non-privileged (48) attempt to map I/O space
> 00000000

Update :

Same problem with a simple "javac -version" :

Aug  5 17:18:45 tomcat02 kernel: 1 multicall(s) failed: cpu 1
Aug  5 17:18:45 tomcat02 kernel:   call  1/1: op=14 arg=[b7f9c000] result=-22
Aug  5 17:18:45 tomcat02 kernel: ------------[ cut here ]------------
Aug  5 17:18:45 tomcat02 kernel: kernel BUG at arch/x86/xen/multicalls.c:103!
Aug  5 17:18:45 tomcat02 kernel: invalid opcode: 0000 [#1] SMP
Aug  5 17:18:45 tomcat02 kernel:
Aug  5 17:18:45 tomcat02 kernel: Pid: 2284, comm: javac Not tainted (2.6.25.7 #1)
Aug  5 17:18:45 tomcat02 kernel: EIP: 0061:[<c020248b>] EFLAGS: 00010202 CPU: 1
Aug  5 17:18:45 tomcat02 kernel: EIP is at xen_mc_flush+0x16b/0x180
Aug  5 17:18:45 tomcat02 kernel: EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000000
Aug  5 17:18:45 tomcat02 kernel: ESI: 00000000 EDI: 00000001 EBP: c140a060 ESP: ddd91edc
Aug  5 17:18:45 tomcat02 kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
Aug  5 17:18:45 tomcat02 kernel: Process javac (pid: 2284, ti=ddd90000 task=dddf35c0 task.ti=ddd90000)
Aug  5 17:18:45 tomcat02 kernel: Stack: c05a5848 00000001 00000001 0000000e b7f9c000 ffffffea 00000200 00000065
Aug  5 17:18:45 tomcat02 kernel:        00000000 00000000 b7f9c000 c02592b4 00000065 00000000 df734890 00000000
Aug  5 17:18:45 tomcat02 kernel:        000b7f9c 00000000 00000000 dfce6034 ddec2ec8 dfce6000 b7f9d000 ddc8cbb0
Aug  5 17:18:45 tomcat02 kernel: Call Trace:
Aug  5 17:18:45 tomcat02 kernel:  [<c02592b4>] mprotect_fixup+0x4b4/0x610
Aug  5 17:18:45 tomcat02 kernel:  [<c0259554>] sys_mprotect+0x144/0x1d0
Aug  5 17:18:45 tomcat02 kernel:  [<c0206c22>] syscall_call+0x7/0xb
Aug  5 17:18:45 tomcat02 kernel:  =======================
Aug  5 17:18:45 tomcat02 kernel: Code: 00 83 c3 20 89 54 24 08 89 74 24 04 c7 04 24 48 58 5a c0 89 44 24 0c e8 84 fc 01 00 8b 95 00 0b 00 00 39 d6 72 c3 e9 25 ff ff ff <0f> 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 8d bc 27 00 00 00 00
Aug  5 17:18:45 tomcat02 kernel: EIP: [<c020248b>] xen_mc_flush+0x16b/0x180 SS:ESP 0069:ddd91edc
Aug  5 17:18:45 tomcat02 kernel: ---[ end trace 8011281f462e176f ]---

Xm dmesg :

(XEN) mm.c:645:d50 Non-privileged (50) attempt to map I/O space 00000000
(XEN) mm.c:645:d51 Non-privileged (51) attempt to map I/O space 00000000

Javac and java were configured by update-alternatives to use sun-java-5-jdk, but same problem with sun-java-6-jdk and openjdk-6-jdk, the Guest (Lenny or Etch) crash.

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: kernel BUG at arch/x86/xen/multicalls.c:103!
  2009-08-06  6:50     ` Olivier NOEL
@ 2009-08-06 19:35       ` Jeremy Fitzhardinge
  2009-11-09 23:50         ` mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 14+ messages in thread
From: Jeremy Fitzhardinge @ 2009-08-06 19:35 UTC (permalink / raw)
  To: Olivier NOEL; +Cc: xen-devel

On 08/05/09 23:50, Olivier NOEL wrote:
> Update :
>
> Same problem with a simple "javac -version" :
>   

Well, that's nice and reproducable.  Any chance you could try a more
recent kernel than 2.6.25?

Thanks,
    J

> Aug  5 17:18:45 tomcat02 kernel: 1 multicall(s) failed: cpu 1
> Aug  5 17:18:45 tomcat02 kernel:   call  1/1: op=14 arg=[b7f9c000] result=-22
> Aug  5 17:18:45 tomcat02 kernel: ------------[ cut here ]------------
> Aug  5 17:18:45 tomcat02 kernel: kernel BUG at arch/x86/xen/multicalls.c:103!
> Aug  5 17:18:45 tomcat02 kernel: invalid opcode: 0000 [#1] SMP
> Aug  5 17:18:45 tomcat02 kernel:
> Aug  5 17:18:45 tomcat02 kernel: Pid: 2284, comm: javac Not tainted (2.6.25.7 #1)
> Aug  5 17:18:45 tomcat02 kernel: EIP: 0061:[<c020248b>] EFLAGS: 00010202 CPU: 1
> Aug  5 17:18:45 tomcat02 kernel: EIP is at xen_mc_flush+0x16b/0x180
> Aug  5 17:18:45 tomcat02 kernel: EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000000
> Aug  5 17:18:45 tomcat02 kernel: ESI: 00000000 EDI: 00000001 EBP: c140a060 ESP: ddd91edc
> Aug  5 17:18:45 tomcat02 kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
> Aug  5 17:18:45 tomcat02 kernel: Process javac (pid: 2284, ti=ddd90000 task=dddf35c0 task.ti=ddd90000)
> Aug  5 17:18:45 tomcat02 kernel: Stack: c05a5848 00000001 00000001 0000000e b7f9c000 ffffffea 00000200 00000065
> Aug  5 17:18:45 tomcat02 kernel:        00000000 00000000 b7f9c000 c02592b4 00000065 00000000 df734890 00000000
> Aug  5 17:18:45 tomcat02 kernel:        000b7f9c 00000000 00000000 dfce6034 ddec2ec8 dfce6000 b7f9d000 ddc8cbb0
> Aug  5 17:18:45 tomcat02 kernel: Call Trace:
> Aug  5 17:18:45 tomcat02 kernel:  [<c02592b4>] mprotect_fixup+0x4b4/0x610
> Aug  5 17:18:45 tomcat02 kernel:  [<c0259554>] sys_mprotect+0x144/0x1d0
> Aug  5 17:18:45 tomcat02 kernel:  [<c0206c22>] syscall_call+0x7/0xb
> Aug  5 17:18:45 tomcat02 kernel:  =======================
> Aug  5 17:18:45 tomcat02 kernel: Code: 00 83 c3 20 89 54 24 08 89 74 24 04 c7 04 24 48 58 5a c0 89 44 24 0c e8 84 fc 01 00 8b 95 00 0b 00 00 39 d6 72 c3 e9 25 ff ff ff <0f> 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 8d bc 27 00 00 00 00
> Aug  5 17:18:45 tomcat02 kernel: EIP: [<c020248b>] xen_mc_flush+0x16b/0x180 SS:ESP 0069:ddd91edc
> Aug  5 17:18:45 tomcat02 kernel: ---[ end trace 8011281f462e176f ]---
>
> Xm dmesg :
>
> (XEN) mm.c:645:d50 Non-privileged (50) attempt to map I/O space 00000000
> (XEN) mm.c:645:d51 Non-privileged (51) attempt to map I/O space 00000000
>
> Javac and java were configured by update-alternatives to use sun-java-5-jdk, but same problem with sun-java-6-jdk and openjdk-6-jdk, the Guest (Lenny or Etch) crash.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

^ permalink raw reply	[flat|nested] 14+ messages in thread

* mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a
  2009-08-06 19:35       ` Jeremy Fitzhardinge
@ 2009-11-09 23:50         ` Konrad Rzeszutek Wilk
  2009-11-10  0:20           ` Jeremy Fitzhardinge
  2009-12-01  3:11           ` mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753 Konrad Rzeszutek Wilk
  0 siblings, 2 replies; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2009-11-09 23:50 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Olivier NOEL, xen-devel

> > (XEN) mm.c:645:d50 Non-privileged (50) attempt to map I/O space 00000000
> > (XEN) mm.c:645:d51 Non-privileged (51) attempt to map I/O space 00000000

I can get this with the most recent kernel when PV and QEMU are involved.
But _not_ if only PV is booted and QEMU is not present.

With this entry (basically a FC11 with the latest PV-OPS kernel compiled):

kernel="/mnt/tmp/fc11/vmlinuz-2.6.31.5"
#kernel="/mnt/tmp/fc11/bzImage-domU.3"
ramdisk="/mnt/tmp/fc11/initrd-2.6.31.5.img"
name="fc11"
extra="root=/dev/mapper/VolGroup-lv_root ro earlycon=xen console=hvc0 debug loglevel=10 iommu=off"
memory=4096
vcpus=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="preserve"
disk=[ 'phy:/dev/vg_guest/FC11,hda,w' ]
vif=[ 'mac=00:16:3e:00:00:12,bridge=eth1' ]
pci = ['0000:04:00.0']

it boots fine. If I add:
vfb=['type=vnc,vnclisten=0.0.0.0,vncunused=1']

I get a stream off:

(XEN) mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a

and this is what the xenctx tells me:

[root@tst002 fc11]# ~/xen-unstable.hg/tools/xentrace/xenctx -s /local2/System.map  2
rip: ffffffff810091aa _stext+0x1aa 
flags: 00001212 i nz a
rsp: ffff8800f912bc40
rax: 0000000000000000	rcx: ffffffff810091aa	rdx: ffffc9000000b0a0
rbx: ffffc9000000b060	rsi: 00000000deadbeef	rdi: 00000000deadbeef
rbp: ffff8800f912bca8	 r8: 0000000000000000	 r9: ffffc9000000b060
r10: 0000000000000000	r11: 0000000000000212	r12: 0000000000007ff1
r13: 80000000f995a467	r14: ffffc9000000c160	r15: 0000000000000060
 cs: e033	 ss: e02b	 ds: 0000	 es: 0000
 fs: 0000 @ 00007f77e69fa6f0
 gs: 0000 @ ffffc90000000000/0000000000000000
Code (instr addr ffffffff810091aa)
cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 0d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc 


Stack:
 0000000000008000 0000000000000000 ffffffff8100c873 ffffc9000000b060
 ffffc9000000c160 0000000000000000 00000000c1bce2a6 ffffffff8100d722
 0000000000000001 0000000000007ff1 80000000f995a467 ffffc9000000c160
 ffffea0003698bb0 ffff8800f912bcc8 ffffffff8100dd5b ffffea000367b4c8

Call Trace:
  [<ffffffff810091aa>] _stext+0x1aa  <--
  [<ffffffff8100c873>] xen_mc_flush+0xf4 
  [<ffffffff8100d722>] get_phys_to_machine+0x30 
  [<ffffffff8100dd5b>] xen_mc_issue+0x2e 
  [<ffffffff8100fcf0>] xen_set_domain_pte+0x8a 
  [<ffffffff8100fdc8>] xen_set_pte_at+0x37 
  [<ffffffff8100ccb1>] __raw_callee_save_xen_make_pte+0x11 
  [<ffffffff81150a0d>] __do_fault+0x4a1 
  [<ffffffff8100cced>] __raw_callee_save_xen_pmd_val+0x11 
  [<ffffffff81151700>] handle_mm_fault+0x253 
  [<ffffffff81010dff>] xen_restore_fl_direct_reloc+0x4 
  [<ffffffff816bcd4a>] _spin_unlock_irq+0x3e 
  [<ffffffff8100ffdf>] xen_force_evtchn_callback+0x27 
  [<ffffffff816c091c>] notifier_call_chain+0x30 
  [<ffffffff816bd585>] paranoid_swapgs+0x8 

Looking at the xm console, it is stuck at: "Creating initial devices."

The next invocation of 'xm create' (without changing anything) changes the printout to:
(XEN) mm.c:841:d5 Error getting mfn 7c1b3 (pfn 784e1) from L1 entry 800000007c1b3467 for l1e_owner=5, pg_owner=32753
which also loops around forever.

I booted up RHEL5U4 with the linux-2.6.18.8.hg tree, same parameters, and it worked fine.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a
  2009-11-09 23:50         ` mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a Konrad Rzeszutek Wilk
@ 2009-11-10  0:20           ` Jeremy Fitzhardinge
  2009-12-01  3:11           ` mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753 Konrad Rzeszutek Wilk
  1 sibling, 0 replies; 14+ messages in thread
From: Jeremy Fitzhardinge @ 2009-11-10  0:20 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: Olivier NOEL, xen-devel

On 11/09/09 15:50, Konrad Rzeszutek Wilk wrote:
>>> (XEN) mm.c:645:d50 Non-privileged (50) attempt to map I/O space 00000000
>>> (XEN) mm.c:645:d51 Non-privileged (51) attempt to map I/O space 00000000
>>>       
> I can get this with the most recent kernel when PV and QEMU are involved.
> But _not_ if only PV is booted and QEMU is not present.
>   

I'm sorry to say that I'd noticed this myself and quietly ignored it
hoping someone else would root-cause it ;)

It appears to be something wrong with the xenfb driver's mapping which
Xen is complaining about, but I hadn't got further than that.

    J

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a +  (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
  2009-11-09 23:50         ` mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a Konrad Rzeszutek Wilk
  2009-11-10  0:20           ` Jeremy Fitzhardinge
@ 2009-12-01  3:11           ` Konrad Rzeszutek Wilk
  2009-12-01  6:40             ` Jeremy Fitzhardinge
  2009-12-01  9:26             ` Markus Armbruster
  1 sibling, 2 replies; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2009-12-01  3:11 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, keir.fraser, Ian.Campbell, JBeulich
  Cc: Olivier NOEL, xen-devel

[-- Attachment #1: Type: text/plain, Size: 8664 bytes --]

> (XEN) mm.c:841:d5 Error getting mfn 7c1b3 (pfn 784e1) from L1 entry 800000007c1b3467 for l1e_owner=5, pg_owner=32753
> which also loops around forever.
> 

Jeremy, Keir, Ian, Jan, et. al.:

If you set vfb=['type=vnc,vnclisten=0.0.0.0,vncunused=1']
for your pv-ops domU you get:
(XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
this is the first attempt at the fix.

What essentially happens is the Plymoth (a framebuffer daemon) starts
writing to the frame buffer, causes a page fault and the domU kernel doesn't handle
it too well.

Specifically these are the steps:
user space:
 fd = opens("/dev/fb0");
 handle =mmap(0, len, PROT_WRITE, MAP_SHARED, fd, 0)

and in the kernel the fb_deferred_io_mmap is called which
sets:
 vma->vm_flags = (VM_DONTEXPAND | VM_RESERVED | VM_IO)

 [VM_IO means that subsequent pages will have PAGE_IOMAP set]

next in the user space we do:
 handle[i] = 'a';

which causes a page_fault and we jump to the kernel:
page_fault ->
	handle_mm_fault ->
		__do_fault()
		    |-----vm_ops->fault (fb_deferred_io_fault):
		    |   	fb_deferred_io_page:
		    |   		vmalloc_to_page [We now have a page]
		    |           vmf->page = page [page attached to the user address, good]
                    |----mk_pte( .. ), sets PAGE_IOMAP
                    |
                    |----xen_set_pte_at ():
			[ This is the fun part ]
			  |----if (xen_iomap_pte(pteval)) [ checks if _PAGE_IOMAP is set]
                                  |----xen_set_domain_pte():
					[which makes the PTE belong to DOMID_IO]

And at that point the Xen Hypervisor is called, and spits out:
(XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753

as it interprets the PFN as the MFN.

This is incorrect as the page is vmalloc-ed and has no IO backing.

Poking around I've come up with three ideas to solve this:

1). Inhibit xen_fb_deferred_io_map from setting VM_IO. That fixes the issue, but
    there are drivers (sh_mobile_lcdcfb.c) that have the fb be backed up by a physical
    page, in which case VM_IO is correct. So this is a no go.

2). Inhibit xen_set_pte_at to call xen_set_domain_pte if the page has _PAGE_USER and _PAGE_IOMAP.
    That did not work at all. The Hypervisor seemed to have lost any clue to whom the page belongs.

3). Make xen-fbfront implement its own mmap functionality. This is what linux-2.6.18.hg has.
    I made an attempt at back-porting it (thought it is quite interrupt heavy as each
    page_fault causes it to trigger a HYPERVISOR event channel up call). I will need to redo
    this if this seems to be the right way.

Thoughts? Maybe there is a better way at doing this?

Attached is the test-case, and the patch for 3). Patch inlined for easier view:


>From 6938ff544e7483d7eedb8eac9ccad489cced27e7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 30 Nov 2009 21:24:59 -0500
Subject: [PATCH 1/2] [xen-fb] Provide a fb_mmap function.

Provide a fb_mmap function instead of using fb_deferred_io_mmap
functionality. The reason behind this is that fb_deferred_io_mmap
sets the VM_IO flag which in a Xen environement is reserved for
pages which have a physical device mapped. For Xen FB our "physical
device" is a 2MB vmalloc area. The end result is that Xen MMU sets
PTE's for this 2MB with the wrong MFN b/c it sees the _PAGE_IOMAP set
(which is set when VM_IO is set).
---
 drivers/video/xen-fbfront.c |  125 ++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index 0c6b1c6..ae83653 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -32,6 +32,13 @@
 #include <xen/interface/io/protocols.h>
 #include <xen/xenbus.h>
 
+struct xenfb_mapping {
+	struct list_head	link;
+	struct vm_area_struct	*vma;
+	atomic_t		map_refs;
+	struct xenfb_info	*info;
+};
+
 struct xenfb_info {
 	unsigned char		*fb;
 	struct fb_info		*fb_info;
@@ -48,6 +55,9 @@ struct xenfb_info {
 	int			resize_dpy;	/* ditto */
 	spinlock_t		resize_lock;
 
+	struct list_head	mappings;
+	spinlock_t		mm_lock;
+
 	struct xenbus_device	*xbdev;
 };
 
@@ -321,12 +331,118 @@ static int xenfb_set_par(struct fb_info *info)
 	return 0;
 }
 
+
+static void xenfb_vm_close(struct vm_area_struct *vma)
+{
+	struct xenfb_mapping *map = vma->vm_private_data;
+	struct xenfb_info *info = map->info;
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->mm_lock, flags);
+	if (atomic_dec_and_test(&map->map_refs)) {
+		list_del(&map->link);
+		kfree(map);
+	}
+	spin_unlock_irqrestore(&info->mm_lock, flags);
+}
+
+static void xenfb_vm_open(struct vm_area_struct *vma)
+{
+	struct xenfb_mapping *map = vma->vm_private_data;
+	atomic_inc(&map->map_refs);
+}
+
+
+/* this is to find and return the vmalloc-ed fb pages */
+static int xenfb_vm_fault(struct vm_area_struct *vma,
+			struct vm_fault *vmf)
+{
+	struct xenfb_mapping *map = vma->vm_private_data;
+	struct xenfb_info *info = map->info;
+	unsigned long offset;
+	struct page *page;
+	int y1, y2;
+
+	offset = vmf->pgoff << PAGE_SHIFT;
+	if (offset >= info->fb_info->fix.smem_len)
+		return VM_FAULT_SIGBUS;
+
+	page = vmalloc_to_page(info->fb_info->screen_base + offset);
+	if (!page)
+		return VM_FAULT_SIGBUS;
+
+	get_page(page);
+
+	page->index = vmf->pgoff;
+
+	y1 = vmf->pgoff * PAGE_SIZE / info->fb_info->fix.line_length;
+	y2 = (vmf->pgoff * PAGE_SIZE + PAGE_SIZE - 1) /
+		info->fb_info->fix.line_length;
+	if (y2 > info->fb_info->var.yres)
+		y2 = info->fb_info->var.yres;
+
+	xenfb_refresh(info, 0, y1, info->fb_info->var.xres, y2 - y1);
+
+	vmf->page = page;
+	return 0;
+}
+
+static struct vm_operations_struct xenfb_vm_ops = {
+	.open   = xenfb_vm_open,
+	.close  = xenfb_vm_close,
+	.fault = xenfb_vm_fault,
+};
+
+static int xenfb_mmap(struct fb_info *fb_info, struct vm_area_struct *vma)
+{
+	struct xenfb_info *info = fb_info->par;
+	struct xenfb_mapping *map;
+	int map_pages;
+	unsigned long flags;
+
+	if (!(vma->vm_flags & VM_WRITE))
+		return -EINVAL;
+	if (!(vma->vm_flags & VM_SHARED))
+		return -EINVAL;
+	if (vma->vm_pgoff != 0)
+		return -EINVAL;
+
+	map_pages = (vma->vm_end - vma->vm_start + PAGE_SIZE-1) >> PAGE_SHIFT;
+	if (map_pages > info->nr_pages)
+		return -EINVAL;
+
+	map = kzalloc(sizeof(*map), GFP_KERNEL);
+	if (map == NULL)
+		return -ENOMEM;
+
+	map->vma = vma;
+	map->info = info;
+	atomic_set(&map->map_refs, 1);
+
+	spin_lock_irqsave(&info->mm_lock, flags);
+	list_add(&map->link, &info->mappings);
+	spin_unlock_irqrestore(&info->mm_lock, flags);
+
+	vma->vm_ops = &xenfb_vm_ops;
+	/* It is _extremely_ important that VM_IO is not set here. If you do
+	* set it, the xen_set_pte (called later by __do_fault) will assign
+	* the pte to the DOMID_IO which is reserved for IO pages (ioremap,
+	* and its friends), not vmalloc-ed ones. The result is an ugly
+	* infinite page fault recursion. */
+	vma->vm_flags |= (VM_DONTEXPAND | VM_RESERVED);
+	vma->vm_private_data = map;
+
+	return 0;
+}
+
+
 static struct fb_ops xenfb_fb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_read	= fb_sys_read,
 	.fb_write	= xenfb_write,
 	.fb_setcolreg	= xenfb_setcolreg,
 	.fb_fillrect	= xenfb_fillrect,
+	.fb_mmap	= xenfb_mmap,
 	.fb_copyarea	= xenfb_copyarea,
 	.fb_imageblit	= xenfb_imageblit,
 	.fb_check_var	= xenfb_check_var,
@@ -391,6 +507,9 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->dirty_lock);
 	spin_lock_init(&info->resize_lock);
 
+	spin_lock_init(&info->mm_lock);
+	INIT_LIST_HEAD(&info->mappings);
+
 	info->fb = vmalloc(fb_size);
 	if (info->fb == NULL)
 		goto error_nomem;
@@ -449,8 +568,10 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 		goto error;
 	}
 
+	/* The xen_fb_mmap replaces this.
 	fb_info->fbdefio = &xenfb_defio;
 	fb_deferred_io_init(fb_info);
+	*/
 
 	xenfb_init_shared_page(info, fb_info);
 
@@ -460,7 +581,7 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 
 	ret = register_framebuffer(fb_info);
 	if (ret) {
-		fb_deferred_io_cleanup(fb_info);
+		/* fb_deferred_io_cleanup(fb_info); */
 		fb_dealloc_cmap(&fb_info->cmap);
 		framebuffer_release(fb_info);
 		xenbus_dev_fatal(dev, ret, "register_framebuffer");
@@ -516,7 +637,7 @@ static int xenfb_remove(struct xenbus_device *dev)
 
 	xenfb_disconnect_backend(info);
 	if (info->fb_info) {
-		fb_deferred_io_cleanup(info->fb_info);
+		/* fb_deferred_io_cleanup(info->fb_info); */
 		unregister_framebuffer(info->fb_info);
 		fb_dealloc_cmap(&info->fb_info->cmap);
 		framebuffer_release(info->fb_info);
-- 
1.6.2.5


[-- Attachment #2: mmap_test.c --]
[-- Type: text/plain, Size: 1385 bytes --]

#include <stdio.h>
#include <errno.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <ctype.h>

static char filename[] = "/dev/fb0";
int main(int argc, char *argv[])
{

	int fd = -1;
	unsigned char *fbuf;
	struct stat buf;
	int i;
	int len;

	printf("Starting..[%s]\n", filename);
	fd = open(filename, O_RDWR);
	if (fd <= 0) {
		printf("Could not open; err: %d\n", errno);
		return errno;
	}
	if (stat(filename, &buf) != 0) {
		printf("Could not open; err: %d\n", errno);
		return errno;
	}

	printf("%s: %d\n", filename, buf.st_size);
	len = 2097152;
	if (buf.st_size)
		len = buf.st_size;
	fbuf = mmap(0, len, PROT_WRITE, MAP_SHARED, fd, 0);
	if (fbuf == MAP_FAILED) {
		printf("Could not map: error: %d\n", errno);
		return errno;
	}
        if (argc > 1) {
		int outfd;
		outfd = open(argv[1], O_RDWR|O_CREAT, 0644);
		if (outfd != -1) {
			write(outfd, fbuf, len);
			close(outfd);
		}
	}
	printf("(%lx): DATA:\n", fbuf);

	for (i = 0; i < len; i++) {
		if ((i % 4096) == 0)
			printf("\n%.4x: ", i);
		if (i == 0)
			printf("Whhhwww  ");
		fbuf[i] = (i % 255); 
		if (i == 0)
			printf(" AHA!\n"); /*
		if (isgraph(fbuf[i]))
			printf("%c", fbuf[i]);
		else
			printf("_");*/
	}
	printf("Done!\n");
	if (munmap(fbuf, len)) {
		printf("Could not unmap: %d\n", errno);
		return errno;
	}
	close(fd);
	return 0;
}

[-- Attachment #3: 0001--xen-fb-Provide-a-fb_mmap-function.patch --]
[-- Type: text/plain, Size: 5841 bytes --]

>From 6938ff544e7483d7eedb8eac9ccad489cced27e7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 30 Nov 2009 21:24:59 -0500
Subject: [PATCH 1/2] [xen-fb] Provide a fb_mmap function.

Provide a fb_mmap function instead of using fb_deferred_io_mmap
functionality. The reason behind this is that fb_deferred_io_mmap
sets the VM_IO flag which in a Xen environement is reserved for
pages which have a physical device mapped. For Xen FB our "physical
device" is a 2MB vmalloc area. The end result is that Xen MMU sets
PTE's for this 2MB with the wrong MFN b/c it sees the _PAGE_IOMAP set
(which is set when VM_IO is set).
---
 drivers/video/xen-fbfront.c |  125 ++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index 0c6b1c6..ae83653 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -32,6 +32,13 @@
 #include <xen/interface/io/protocols.h>
 #include <xen/xenbus.h>
 
+struct xenfb_mapping {
+	struct list_head	link;
+	struct vm_area_struct	*vma;
+	atomic_t		map_refs;
+	struct xenfb_info	*info;
+};
+
 struct xenfb_info {
 	unsigned char		*fb;
 	struct fb_info		*fb_info;
@@ -48,6 +55,9 @@ struct xenfb_info {
 	int			resize_dpy;	/* ditto */
 	spinlock_t		resize_lock;
 
+	struct list_head	mappings;
+	spinlock_t		mm_lock;
+
 	struct xenbus_device	*xbdev;
 };
 
@@ -321,12 +331,118 @@ static int xenfb_set_par(struct fb_info *info)
 	return 0;
 }
 
+
+static void xenfb_vm_close(struct vm_area_struct *vma)
+{
+	struct xenfb_mapping *map = vma->vm_private_data;
+	struct xenfb_info *info = map->info;
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->mm_lock, flags);
+	if (atomic_dec_and_test(&map->map_refs)) {
+		list_del(&map->link);
+		kfree(map);
+	}
+	spin_unlock_irqrestore(&info->mm_lock, flags);
+}
+
+static void xenfb_vm_open(struct vm_area_struct *vma)
+{
+	struct xenfb_mapping *map = vma->vm_private_data;
+	atomic_inc(&map->map_refs);
+}
+
+
+/* this is to find and return the vmalloc-ed fb pages */
+static int xenfb_vm_fault(struct vm_area_struct *vma,
+			struct vm_fault *vmf)
+{
+	struct xenfb_mapping *map = vma->vm_private_data;
+	struct xenfb_info *info = map->info;
+	unsigned long offset;
+	struct page *page;
+	int y1, y2;
+
+	offset = vmf->pgoff << PAGE_SHIFT;
+	if (offset >= info->fb_info->fix.smem_len)
+		return VM_FAULT_SIGBUS;
+
+	page = vmalloc_to_page(info->fb_info->screen_base + offset);
+	if (!page)
+		return VM_FAULT_SIGBUS;
+
+	get_page(page);
+
+	page->index = vmf->pgoff;
+
+	y1 = vmf->pgoff * PAGE_SIZE / info->fb_info->fix.line_length;
+	y2 = (vmf->pgoff * PAGE_SIZE + PAGE_SIZE - 1) /
+		info->fb_info->fix.line_length;
+	if (y2 > info->fb_info->var.yres)
+		y2 = info->fb_info->var.yres;
+
+	xenfb_refresh(info, 0, y1, info->fb_info->var.xres, y2 - y1);
+
+	vmf->page = page;
+	return 0;
+}
+
+static struct vm_operations_struct xenfb_vm_ops = {
+	.open   = xenfb_vm_open,
+	.close  = xenfb_vm_close,
+	.fault = xenfb_vm_fault,
+};
+
+static int xenfb_mmap(struct fb_info *fb_info, struct vm_area_struct *vma)
+{
+	struct xenfb_info *info = fb_info->par;
+	struct xenfb_mapping *map;
+	int map_pages;
+	unsigned long flags;
+
+	if (!(vma->vm_flags & VM_WRITE))
+		return -EINVAL;
+	if (!(vma->vm_flags & VM_SHARED))
+		return -EINVAL;
+	if (vma->vm_pgoff != 0)
+		return -EINVAL;
+
+	map_pages = (vma->vm_end - vma->vm_start + PAGE_SIZE-1) >> PAGE_SHIFT;
+	if (map_pages > info->nr_pages)
+		return -EINVAL;
+
+	map = kzalloc(sizeof(*map), GFP_KERNEL);
+	if (map == NULL)
+		return -ENOMEM;
+
+	map->vma = vma;
+	map->info = info;
+	atomic_set(&map->map_refs, 1);
+
+	spin_lock_irqsave(&info->mm_lock, flags);
+	list_add(&map->link, &info->mappings);
+	spin_unlock_irqrestore(&info->mm_lock, flags);
+
+	vma->vm_ops = &xenfb_vm_ops;
+	/* It is _extremely_ important that VM_IO is not set here. If you do
+	* set it, the xen_set_pte (called later by __do_fault) will assign
+	* the pte to the DOMID_IO which is reserved for IO pages (ioremap,
+	* and its friends), not vmalloc-ed ones. The result is an ugly
+	* infinite page fault recursion. */
+	vma->vm_flags |= (VM_DONTEXPAND | VM_RESERVED);
+	vma->vm_private_data = map;
+
+	return 0;
+}
+
+
 static struct fb_ops xenfb_fb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_read	= fb_sys_read,
 	.fb_write	= xenfb_write,
 	.fb_setcolreg	= xenfb_setcolreg,
 	.fb_fillrect	= xenfb_fillrect,
+	.fb_mmap	= xenfb_mmap,
 	.fb_copyarea	= xenfb_copyarea,
 	.fb_imageblit	= xenfb_imageblit,
 	.fb_check_var	= xenfb_check_var,
@@ -391,6 +507,9 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->dirty_lock);
 	spin_lock_init(&info->resize_lock);
 
+	spin_lock_init(&info->mm_lock);
+	INIT_LIST_HEAD(&info->mappings);
+
 	info->fb = vmalloc(fb_size);
 	if (info->fb == NULL)
 		goto error_nomem;
@@ -449,8 +568,10 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 		goto error;
 	}
 
+	/* The xen_fb_mmap replaces this.
 	fb_info->fbdefio = &xenfb_defio;
 	fb_deferred_io_init(fb_info);
+	*/
 
 	xenfb_init_shared_page(info, fb_info);
 
@@ -460,7 +581,7 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 
 	ret = register_framebuffer(fb_info);
 	if (ret) {
-		fb_deferred_io_cleanup(fb_info);
+		/* fb_deferred_io_cleanup(fb_info); */
 		fb_dealloc_cmap(&fb_info->cmap);
 		framebuffer_release(fb_info);
 		xenbus_dev_fatal(dev, ret, "register_framebuffer");
@@ -516,7 +637,7 @@ static int xenfb_remove(struct xenbus_device *dev)
 
 	xenfb_disconnect_backend(info);
 	if (info->fb_info) {
-		fb_deferred_io_cleanup(info->fb_info);
+		/* fb_deferred_io_cleanup(info->fb_info); */
 		unregister_framebuffer(info->fb_info);
 		fb_dealloc_cmap(&info->fb_info->cmap);
 		framebuffer_release(info->fb_info);
-- 
1.6.2.5


[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
  2009-12-01  3:11           ` mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753 Konrad Rzeszutek Wilk
@ 2009-12-01  6:40             ` Jeremy Fitzhardinge
  2009-12-01 21:57               ` Konrad Rzeszutek Wilk
  2009-12-01  9:26             ` Markus Armbruster
  1 sibling, 1 reply; 14+ messages in thread
From: Jeremy Fitzhardinge @ 2009-12-01  6:40 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: Ian.Campbell, xen-devel, Olivier NOEL, keir.fraser, JBeulich

On 11/30/09 19:11, Konrad Rzeszutek Wilk wrote:
> next in the user space we do:
>  handle[i] = 'a';
>
> which causes a page_fault and we jump to the kernel:
> page_fault ->
> 	handle_mm_fault ->
> 		__do_fault()
> 		    |-----vm_ops->fault (fb_deferred_io_fault):
> 		    |   	fb_deferred_io_page:
> 		    |   		vmalloc_to_page [We now have a page]
> 		    |           vmf->page = page [page attached to the user address, good]
>                     |----mk_pte( .. ), sets PAGE_IOMAP
>                     |
>                     |----xen_set_pte_at ():
> 			[ This is the fun part ]
> 			  |----if (xen_iomap_pte(pteval)) [ checks if _PAGE_IOMAP is set]
>                                   |----xen_set_domain_pte():
> 					[which makes the PTE belong to DOMID_IO]
>
> And at that point the Xen Hypervisor is called, and spits out:
> (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
>
> as it interprets the PFN as the MFN.
>   

OK, that makes sense.  Thanks for tracking it down.

> This is incorrect as the page is vmalloc-ed and has no IO backing.
>
> Poking around I've come up with three ideas to solve this:
>
> 1). Inhibit xen_fb_deferred_io_map from setting VM_IO. That fixes the issue, but
>     there are drivers (sh_mobile_lcdcfb.c) that have the fb be backed up by a physical
>     page, in which case VM_IO is correct. So this is a no go.
>   

1a) add a flag to avoid setting VM_IO?  (uncompiled, untested, uneverything)

diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
index 0a7a667..dd03822 100644
--- a/drivers/video/fb_defio.c
+++ b/drivers/video/fb_defio.c
@@ -144,7 +144,9 @@ static const struct address_space_operations fb_deferred_io_aops = {
 static int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
 {
 	vma->vm_ops = &fb_deferred_io_vm_ops;
-	vma->vm_flags |= ( VM_IO | VM_RESERVED | VM_DONTEXPAND );
+	vma->vm_flags |= ( VM_RESERVED | VM_DONTEXPAND );
+	if (!(info->flags & FBINFO_VIRTFB))
+	  vma->vm_flags |= VM_IO;
 	vma->vm_private_data = info;
 	return 0;
 }
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index 0c6b1c6..60d9d61 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -440,7 +440,7 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
 	fb_info->fix.type = FB_TYPE_PACKED_PIXELS;
 	fb_info->fix.accel = FB_ACCEL_NONE;
 
-	fb_info->flags = FBINFO_FLAG_DEFAULT;
+	fb_info->flags = FBINFO_DEFAULT | FBINFO_VIRTFB;
 
 	ret = fb_alloc_cmap(&fb_info->cmap, 256, 0);
 	if (ret < 0) {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index f847df9..65134b5 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -766,6 +766,7 @@ struct fb_tile_ops {
 	 *  Hardware acceleration is turned off.  Software implementations
 	 *  of required functions (copyarea(), fillrect(), and imageblit())
 	 *  takes over; acceleration engine should be in a quiescent state */
+#define FBINFO_VIRTFB		0x0004	/* FB is in system RAM, not device */
 
 /* hints */
 #define FBINFO_PARTIAL_PAN_OK	0x0040 /* otw use pan only for double-buffering */

	J

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
  2009-12-01  3:11           ` mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753 Konrad Rzeszutek Wilk
  2009-12-01  6:40             ` Jeremy Fitzhardinge
@ 2009-12-01  9:26             ` Markus Armbruster
  2009-12-01 16:14               ` Konrad Rzeszutek Wilk
  1 sibling, 1 reply; 14+ messages in thread
From: Markus Armbruster @ 2009-12-01  9:26 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: Jeremy Fitzhardinge, xen-devel, JBeulich, Ian.Campbell,
	Olivier NOEL, keir.fraser

Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> writes:

>> (XEN) mm.c:841:d5 Error getting mfn 7c1b3 (pfn 784e1) from L1 entry 800000007c1b3467 for l1e_owner=5, pg_owner=32753
>> which also loops around forever.
>> 
>
> Jeremy, Keir, Ian, Jan, et. al.:
>
> If you set vfb=['type=vnc,vnclisten=0.0.0.0,vncunused=1']
> for your pv-ops domU you get:
> (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
> this is the first attempt at the fix.
>
> What essentially happens is the Plymoth (a framebuffer daemon) starts
> writing to the frame buffer, causes a page fault and the domU kernel doesn't handle
> it too well.
>
> Specifically these are the steps:
> user space:
>  fd = opens("/dev/fb0");
>  handle =mmap(0, len, PROT_WRITE, MAP_SHARED, fd, 0)
>
> and in the kernel the fb_deferred_io_mmap is called which
> sets:
>  vma->vm_flags = (VM_DONTEXPAND | VM_RESERVED | VM_IO)
>
>  [VM_IO means that subsequent pages will have PAGE_IOMAP set]
>
> next in the user space we do:
>  handle[i] = 'a';
>
> which causes a page_fault and we jump to the kernel:
> page_fault ->
> 	handle_mm_fault ->
> 		__do_fault()
> 		    |-----vm_ops->fault (fb_deferred_io_fault):
> 		    |   	fb_deferred_io_page:
> 		    |   		vmalloc_to_page [We now have a page]
> 		    |           vmf->page = page [page attached to the user address, good]
>                     |----mk_pte( .. ), sets PAGE_IOMAP
>                     |
>                     |----xen_set_pte_at ():
> 			[ This is the fun part ]
> 			  |----if (xen_iomap_pte(pteval)) [ checks if _PAGE_IOMAP is set]
>                                   |----xen_set_domain_pte():
> 					[which makes the PTE belong to DOMID_IO]
>
> And at that point the Xen Hypervisor is called, and spits out:
> (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
>
> as it interprets the PFN as the MFN.
>
> This is incorrect as the page is vmalloc-ed and has no IO backing.
>
> Poking around I've come up with three ideas to solve this:
>
> 1). Inhibit xen_fb_deferred_io_map from setting VM_IO. That fixes the issue, but
>     there are drivers (sh_mobile_lcdcfb.c) that have the fb be backed up by a physical
>     page, in which case VM_IO is correct. So this is a no go.
>
> 2). Inhibit xen_set_pte_at to call xen_set_domain_pte if the page has _PAGE_USER and _PAGE_IOMAP.
>     That did not work at all. The Hypervisor seemed to have lost any clue to whom the page belongs.
>
> 3). Make xen-fbfront implement its own mmap functionality. This is what linux-2.6.18.hg has.
>     I made an attempt at back-porting it (thought it is quite interrupt heavy as each
>     page_fault causes it to trigger a HYPERVISOR event channel up call). I will need to redo
>     this if this seems to be the right way.

I recommend against 3).

2.6.18's xenfb doesn't rely on deferred I/O, because that didn't exist
then.  It rolls its own code to do pretty much the same.  The code is
hairy (it took us a few iterations to get it working reliably), and
there's still a race left in it[*].  It makes much more sense to solve
such a hairy problem in just one place (fb_defio.c), and make that
sufficiently capable for all uses.  Moreover, I'd wager that in-tree
fb_defio.c has been reviewed much more thoroughly than the out-of-tree
2.6.18 xenfb.c.

> Thoughts? Maybe there is a better way at doing this?
>
> Attached is the test-case, and the patch for 3). Patch inlined for easier view:
[...]

[*] https://bugzilla.redhat.com/show_bug.cgi?id=219787

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a +  (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
  2009-12-01  9:26             ` Markus Armbruster
@ 2009-12-01 16:14               ` Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2009-12-01 16:14 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Jeremy Fitzhardinge, xen-devel, JBeulich, Ian.Campbell,
	Olivier NOEL, keir.fraser

> I recommend against 3).
> 
> 2.6.18's xenfb doesn't rely on deferred I/O, because that didn't exist
> then.  It rolls its own code to do pretty much the same.  The code is
> hairy (it took us a few iterations to get it working reliably), and
> there's still a race left in it[*].  It makes much more sense to solve
> such a hairy problem in just one place (fb_defio.c), and make that
> sufficiently capable for all uses.  Moreover, I'd wager that in-tree
> fb_defio.c has been reviewed much more thoroughly than the out-of-tree
> 2.6.18 xenfb.c.

Wow. Thanks for saving me from going into that rat-hole! Will definitly
look at the 1a) solution.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
  2009-12-01  6:40             ` Jeremy Fitzhardinge
@ 2009-12-01 21:57               ` Konrad Rzeszutek Wilk
  2009-12-01 22:44                 ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2009-12-01 21:57 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: xen-devel, armbru, JBeulich, Ian.Campbell, Olivier NOEL, keir.fraser

> 1a) add a flag to avoid setting VM_IO?  (uncompiled, untested, uneverything)

That did it. Tested with Dom0 and DomU succesfully.

Signed off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
> index 0a7a667..dd03822 100644
> --- a/drivers/video/fb_defio.c
> +++ b/drivers/video/fb_defio.c
> @@ -144,7 +144,9 @@ static const struct address_space_operations fb_deferred_io_aops = {
>  static int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
>  {
>  	vma->vm_ops = &fb_deferred_io_vm_ops;
> -	vma->vm_flags |= ( VM_IO | VM_RESERVED | VM_DONTEXPAND );
> +	vma->vm_flags |= ( VM_RESERVED | VM_DONTEXPAND );
> +	if (!(info->flags & FBINFO_VIRTFB))
> +	  vma->vm_flags |= VM_IO;
>  	vma->vm_private_data = info;
>  	return 0;
>  }
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index 0c6b1c6..60d9d61 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -440,7 +440,7 @@ static int __devinit xenfb_probe(struct xenbus_device *dev,
>  	fb_info->fix.type = FB_TYPE_PACKED_PIXELS;
>  	fb_info->fix.accel = FB_ACCEL_NONE;
>  
> -	fb_info->flags = FBINFO_FLAG_DEFAULT;
> +	fb_info->flags = FBINFO_DEFAULT | FBINFO_VIRTFB;
>  
>  	ret = fb_alloc_cmap(&fb_info->cmap, 256, 0);
>  	if (ret < 0) {
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index f847df9..65134b5 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -766,6 +766,7 @@ struct fb_tile_ops {
>  	 *  Hardware acceleration is turned off.  Software implementations
>  	 *  of required functions (copyarea(), fillrect(), and imageblit())
>  	 *  takes over; acceleration engine should be in a quiescent state */
> +#define FBINFO_VIRTFB		0x0004	/* FB is in system RAM, not device */
>  
>  /* hints */
>  #define FBINFO_PARTIAL_PAN_OK	0x0040 /* otw use pan only for double-buffering */
> 
> 	J
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
  2009-12-01 21:57               ` Konrad Rzeszutek Wilk
@ 2009-12-01 22:44                 ` Jeremy Fitzhardinge
  2009-12-01 23:05                   ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 14+ messages in thread
From: Jeremy Fitzhardinge @ 2009-12-01 22:44 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: xen-devel, armbru, JBeulich, Ian.Campbell, Olivier NOEL, keir.fraser

On 12/01/09 13:57, Konrad Rzeszutek Wilk wrote:
>> 1a) add a flag to avoid setting VM_IO?  (uncompiled, untested, uneverything)
>>     
> That did it. Tested with Dom0 and DomU succesfully.
>
> Signed off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>   

Oh, good.  Could you look at splitting it into a pair of patches
(separate fbdev + xen), and see if you can raise a maintainer ACK (Jaya
Kumar <jayakumar.lkml@gmail.com>, by the look of it)?  Also, are there
any other places which should be testing FBDEV_VIRTFB (does
fbmem.c:fb_mmap() come into play)?

Thanks,
    J

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Re: mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753
  2009-12-01 22:44                 ` Jeremy Fitzhardinge
@ 2009-12-01 23:05                   ` Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2009-12-01 23:05 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: xen-devel, armbru, JBeulich, Ian.Campbell, Olivier NOEL, keir.fraser

On Tue, Dec 01, 2009 at 02:44:49PM -0800, Jeremy Fitzhardinge wrote:
> On 12/01/09 13:57, Konrad Rzeszutek Wilk wrote:
> >> 1a) add a flag to avoid setting VM_IO?  (uncompiled, untested, uneverything)
> >>     
> > That did it. Tested with Dom0 and DomU succesfully.
> >
> > Signed off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >   
> 
> Oh, good.  Could you look at splitting it into a pair of patches
> (separate fbdev + xen), and see if you can raise a maintainer ACK (Jaya
> Kumar <jayakumar.lkml@gmail.com>, by the look of it)?  Also, are there
> any other places which should be testing FBDEV_VIRTFB (does
> fbmem.c:fb_mmap() come into play)?

Sure thing, will do it.

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2009-12-01 23:05 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-03  9:44 kernel BUG at arch/x86/xen/multicalls.c:103! Olivier NOEL
2009-08-04 23:55 ` Jeremy Fitzhardinge
2009-08-05  7:10   ` Olivier NOEL
2009-08-06  6:50     ` Olivier NOEL
2009-08-06 19:35       ` Jeremy Fitzhardinge
2009-11-09 23:50         ` mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a Konrad Rzeszutek Wilk
2009-11-10  0:20           ` Jeremy Fitzhardinge
2009-12-01  3:11           ` mm.c:777:d2 Non-privileged (2) attempt to map I/O space 000f995a + (XEN) mm.c:845:d20 Error getting mfn jd (pfn 84fd) from L1 entry 800000000246d467 for l1e_owner=20, pg_owner=32753 Konrad Rzeszutek Wilk
2009-12-01  6:40             ` Jeremy Fitzhardinge
2009-12-01 21:57               ` Konrad Rzeszutek Wilk
2009-12-01 22:44                 ` Jeremy Fitzhardinge
2009-12-01 23:05                   ` Konrad Rzeszutek Wilk
2009-12-01  9:26             ` Markus Armbruster
2009-12-01 16:14               ` Konrad Rzeszutek Wilk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.