[Xen-users] Re: [Xen-devel] warning trace while starting domU

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Sep 26, 2011 at 10:24:53AM -0700, Shriganesh Shintre wrote:
> Environment: Xen 4.1.1 with Linux 3.0.4 kernel (compiled with DEBUG enabled)
> 
> I am chasing the warning trace while starting domU. Trace is as follows

Don't worry about it. Ignore it please - I am droping this piece of code in 3.2
as it is causing more headache that it is worth.

> 
> 
> Sep 12 22:18:58 ucs-xen24-srv1 kernel: ------------[ cut here ]------------
> Sep 12 22:18:58 ucs-xen24-srv1 kernel: WARNING: at arch/x86/xen/mmu.c:486
> xen_make_pte_debug+0xdb/0x187()
> Sep 12 22:18:58 ucs-xen24-srv1 kernel: Hardware name: N20-B6625-1
> Sep 12 22:18:58 ucs-xen24-srv1 kernel: 0xec0f1000 is using VM_IO, but it is
> 0xfffff000!
> Sep 12 22:18:58 ucs-xen24-srv1 kernel: Modules linked in: veth raid1 vnp
> iptable_filter ip_tables bridge stp ipmi_si ipmi_devintf ipmi_msghandler nbd
> hoop bonding xt_tcpudp x_tables ipv6 xenfs loop dm_mirror dm_region_hash
> dm_log dm_multipath scsi_dh dm_mod thermal fan parport nvram sg ub enic
> acpi_power_meter hwmon 8250_pnp button 8250 i2c_i801 ehci_hcd serial_core
> ioatdma i2c_core iTCO_wdt iTCO_vendor_support uhci_hcd dca pcspkr mptsas
> mptscsih mptbase scsi_transport_sas sd_mod scsi_mod ext3 jbd mbcache [last
> unloaded: ip_tables]
> Sep 12 22:18:58 ucs-xen24-srv1 kernel: Pid: 16534, comm: xend Tainted:
> G        W   3.0.1-11.xen0 #1
> Sep 12 22:18:58 ucs-xen24-srv1 kernel: Call Trace:
> Sep 12 22:18:58 ucs-xen24-srv1 kernel:  [<c100647f>] ?
> xen_make_pte_debug+0xdb/0x187
> Sep 12 22:18:58 ucs-xen24-srv1 kernel:  [<c10351e0>]
> warn_slowpath_common+0x76/0x8b
> Sep 12 22:18:58 ucs-xen24-srv1 kernel:  [<c100647f>] ?
> xen_make_pte_debug+0xdb/0x187
> Sep 12 22:18:58 ucs-xen24-srv1 kernel:  [<c1035271>]
> warn_slowpath_fmt+0x2e/0x30
> Sep 12 22:18:58 ucs-xen24-srv1 kernel:  [<c100647f>]
> xen_make_pte_debug+0xdb/0x187
> Sep 12 22:18:58 ucs-xen24-srv1 kernel:  [<c100466e>]
> __raw_callee_save_xen_make_pte_debug+0x6/0x8
> Sep 12 22:18:59 ucs-xen24-srv1 kernel:  [<c1004db9>] ?
> remap_area_mfn_pte_fn+0x60/0xf7
> Sep 12 22:18:59 ucs-xen24-srv1 kernel:  [<c10842b9>]
> apply_to_page_range+0x1fe/0x307
> Sep 12 22:18:59 ucs-xen24-srv1 kernel:  [<c100514c>]
> xen_remap_domain_mfn_range+0xd3/0x107
> Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add
> XENBUS_PATH=backend/vbd/1/768
> Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add
> XENBUS_PATH=backend/vbd/1/832
> Sep 12 22:18:59 ucs-xen24-srv1 kernel:  [<c1004d59>] ?
> xen_make_pte+0x113/0x113
> Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add
> XENBUS_PATH=backend/vbd/1/5632
> Sep 12 22:18:59 ucs-xen24-srv1 logger: /etc/xen/scripts/block: add
> XENBUS_PATH=backend/vbd/1/5696
> Sep 12 22:18:59 ucs-xen24-srv1 VRM: TP_SKT.c(1193): m_skt_connect(): Failed
> to connect to remote host, err=No route to host, 113
> Sep 12 22:18:59 ucs-xen24-srv1 kernel:  [<c1007097>] ?
> xen_restore_fl_direct_reloc+0x4/0x4
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c1005352>] ?
> xen_flush_tlb+0x5f/0x6c
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c1024766>] ?
> kernel_map_pages+0xab/0x104
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c107288d>] ?
> get_page_from_freelist+0x255/0x39c
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c10044a5>] ?
> xen_mc_flush+0x101/0x1b6
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c1072b9e>] ?
> __alloc_pages_nodemask+0xd9/0x561
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c10823eb>] ?
> do_wp_page+0x348/0x879
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<f818909b>] mmap_batch_fn+0x3c/0x5b
> [xenfs]
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<f8188c53>]
> traverse_pages+0x75/0x89 [xenfs]
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<f8189022>]
> privcmd_ioctl+0x2ad/0x2ea [xenfs]
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<f818905f>] ?
> privcmd_ioctl+0x2ea/0x2ea [xenfs]
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c10884a7>] ? vma_link+0x4f/0x8d
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<f8188d75>] ?
> free_page_list+0x3b/0x3b [xenfs]
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c10a4734>] vfs_ioctl+0x24/0x37
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c10a48a5>] do_vfs_ioctl+0x8a/0x4df
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c1089284>] ? sys_brk+0x101/0x101
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c1089011>] ?
> do_mmap_pgoff+0x2bb/0x2df
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c10a4d2d>] sys_ioctl+0x33/0x57
> Sep 12 22:19:00 ucs-xen24-srv1 kernel:  [<c1251d9c>]
> sysenter_do_call+0x12/0x2c
> Sep 12 22:19:00 ucs-xen24-srv1 kernel: ---[ end trace 4eaa2a86a8e2da26 ]---
> 
> 
> 
> Following is the code from where the trace is coming. It’s clear from the
> code that this warning trace is observed only when the debug kernel is used.
> Also warning appears only once (WARN_ONCE) while starting first domU.
> 
> 
> File: linux-3.0.4/arch/x86/xen/mmu.c
> 
> #ifdef CONFIG_XEN_DEBUG
> 
> pte_t xen_make_pte_debug(pteval_t pte)
> 
> {
> 
>         phys_addr_t addr = (pte & PTE_PFN_MASK);
> 
>         phys_addr_t other_addr;
> 
>         bool io_page = false;
> 
>         pte_t _pte;
> 
> 
> 
>         if (pte & _PAGE_IOMAP)
> 
>                 io_page = true;
> 
> 
> 
>         _pte = xen_make_pte(pte);
> 
> 
> 
>         if (!addr)
> 
>                 return _pte;
> 
> 
> 
> *        if (io_page
> &&                                                                  *
> 
> *            (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {*
> 
> *                other_addr = pfn_to_mfn(addr >> PAGE_SHIFT) << PAGE_SHIFT;*
> 
> *                WARN_ONCE(addr != other_addr,*
> 
> *                        "0x%lx is using VM_IO, but it is 0x%lx!\n",*
> 
> *                        (unsigned long)addr, (unsigned long)other_addr);*
> 
>         } else {
> 
>                 pteval_t iomap_set = (_pte.pte & PTE_FLAGS_MASK) &
> _PAGE_IOMAP;
> 
>                 other_addr = (_pte.pte & PTE_PFN_MASK);
> 
>                 WARN_ONCE((addr == other_addr) && (!io_page) &&
> (!iomap_set),
> 
>                         "0x%lx is missing VM_IO (and wasn't fixed)!\n",
> 
>                         (unsigned long)addr);
> 
>         }
> 
> 
> 
>         return _pte;
> 
> }
> 
> PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_debug);
> 
> #endif
> 
> 
> 
> When googled, I found this link
> http://www.gossamer-threads.com/lists/xen/devel/217630, but could not find
> the patch he is talking about.
> 
> 
> Could you please help me resolving this warning? or provide me more pointers
> and direction for debugging. Thank you in advance.
> 
> 
> ~Shri

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


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