* 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@lists.xensource.com 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@lists.xensource.com 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 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
* 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
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.