WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] What is the current state of Dom0 kernel support? / cras

On Wed, Jul 22, 2009 at 01:25:45PM -0700, Jeremy Fitzhardinge wrote:
> On 07/22/09 12:57, Pasi Kärkkäinen wrote:
> > On Wed, Jul 22, 2009 at 10:35:30PM +0300, Pasi Kärkkäinen wrote:
> >   
> >> On Wed, Jul 22, 2009 at 12:14:37PM -0700, Jeremy Fitzhardinge wrote:
> >>     
> >>> On 07/21/09 06:03, Pasi Kärkkäinen wrote:
> >>>       
> >>>> I just tried the latest 32b PAE rebase/master tree (2.6.31-rc3).
> >>>>
> >>>> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-10-rebase-master-with-highpte.txt
> >>>>
> >>>> Checking if this processor honours the WP bit even in supervisor mode...
> >>>> BUG: unable to handle kernel NULL pointer dereference at (null)
> >>>> IP: [<c058cdcb>] xen_evtchn_do_upcall+0xcc/0x13f
> >>>> *pdpt = 000000003d275001 
> >>>> Thread overran stack, or stack corrupted
> >>>> Oops: 0000 [#1] SMP 
> >>>> last sysfs file: 
> >>>> Modules linked in:
> >>>>
> >>>> Pid: 0, comm: swapper Not tainted (2.6.31-rc3 #20) P8SC8
> >>>> EIP: 0061:[<c058cdcb>] EFLAGS: 00010046 CPU: 0
> >>>> EIP is at xen_evtchn_do_upcall+0xcc/0x13f
> >>>> EAX: 00000000 EBX: ffffffff ECX: 00000000 EDX: 00000000
> >>>> ESI: 00000000 EDI: c08ec558 EBP: c087eedc ESP: c087eea0
> >>>>  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: e021
> >>>> Process swapper (pid: 0, ti=c087e000 task=c083b1a0 task.ti=c087e000)
> >>>> Stack:
> >>>>  00001a6e 00000220 00000200 00000000 00000000 00000000 e3201014 c08ec558
> >>>> <0> c087eee4 f5681000 e3201010 00000000 00000000 c09017f8 f54ff000 
> >>>> c087ef20
> >>>> <0> c0409927 00000000 c09017f8 f54ff000 c09017f8 f54ff000 c087ef20 
> >>>> c0843f70
> >>>> Call Trace:
> >>>>  [<c0409927>] ? xen_do_upcall+0x7/0xc
> >>>>  [<c0404581>] ? xen_pte_clear+0x9/0x12
> >>>>  [<c0427a94>] ? set_pte_vaddr+0xb4/0xc4
> >>>>  [<c0426c8c>] ? __native_set_fixmap+0x25/0x30
> >>>>  [<c040471a>] ? xen_set_fixmap+0xc7/0xcc
> >>>>  [<c0897d86>] ? mem_init+0x24a/0x298
> >>>>  [<c088367e>] ? start_kernel+0x14b/0x2cd
> >>>>  [<c088336f>] ? unknown_bootoption+0x0/0x18e
> >>>>  [<c0883082>] ? i386_start_kernel+0x71/0x79
> >>>>  [<c0886188>] ? xen_start_kernel+0x52a/0x533
> >>>> Code: d0 89 45 cc 89 55 c8 eb 16 0f bc c8 03 4d d4 8b 04 8a 83 f8 ff 74 
> >>>> f8
> >>>> 8b 55 e4 e8 36 de e7 ff 8b 55 f0 8b 45 d0 03 
> >>>> 05 1c 0c 97 c0 <8b> 0c 10 8b 55 e8 8b 45 cc 23 0c 82 8b 45 c8 8b 04 82 
> >>>> 8b 15
> >>>> 18 
> >>>> EIP: [<c058cdcb>] xen_evtchn_do_upcall+0xcc/0x13f SS:ESP e021:c087eea0
> >>>> CR2: 0000000000000000
> >>>> ---[ end trace 4eaa2a86a8e2da22 ]---
> >>>> Kernel panic - not syncing: Fatal exception in interrupt
> >>>>   
> >>>>         
> >>> Haven't seen that one before.  
> >>>
> >>>       
> >> Ok. I've seen many people report crashes during startup with rebase/master
> >> on 32b PAE. I assume they're seeing this same issue.
> >>
> >>     
> >>> The stack backtrace is a bit fuzzy; do you have CONFIG_FRAMEPOINTER 
> >>> enabled?  
> >>> And if you have CONFIG_DEBUGINFO enabled, you can map the eip c058cdcb 
> >>> to a specific source line (its not clear to me which pointer is NULL).
> >>>
> >>>       
> >> [root@dom0test linux-2.6-xen]# grep -i CONFIG_FRAMEPOINTER .config
> >> [root@dom0test linux-2.6-xen]# grep -i CONFIG_DEBUGINFO .config
> >> [root@dom0test linux-2.6-xen]# 
> >>
> >> Unfortunately those were not enabled.. I'll build a new kernel with
> >> CONFIG_DEBUGINFO enabled.
> >>
> >>     
> >
> > Actually CONFIG_DEBUG_INFO was enabled, if you meant that? 
> >   
> 
> Yes, that's it.
> > (gdb) x/i 0xc058cdcb
> >   
> 
> Try "list *0xc058cdcb".
> 

(gdb) list *0xc058cdcb
0xc058cdcb is in active_evtchns (drivers/xen/events.c:237).
232
233     static inline unsigned long active_evtchns(unsigned int cpu,
234                                                struct shared_info *sh,
235                                                unsigned int idx)
236     {
237             return (sh->evtchn_pending[idx] &
238                     cpu_evtchn_mask(cpu)[idx] &
239                     ~sh->evtchn_mask[idx]);
240     }
241
(gdb)


-- Pasi

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

<Prev in Thread] Current Thread [Next in Thread>