[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] What is the current state of Dom0 kernel support? / crash with 2.6.31-rc5 32bit PAE
On 08/11/09 12:58, Pasi Kärkkäinen wrote: > On Mon, Aug 10, 2009 at 10:27:50PM +0300, Pasi Kärkkäinen wrote: > >> On Mon, Aug 10, 2009 at 09:52:35AM -0700, Jeremy Fitzhardinge wrote: >> >>> On 08/10/09 09:43, Pasi Kärkkäinen wrote: >>> >>>> Did I mess up something here or was this patch against some other tree than >>>> rebase/master? >>>> >>>> >>> No, it needed another change in there. rebase/master now has that fix >>> in it, but I'm seeing other interrupt-related strangeness which I still >>> don't understand. I'd be interested in any reports you have about >>> current rebase/master. >>> >>> >> I just updated rebase/master and rebuilt (now 2.6.31-rc5). >> >> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-11-rebase-master-with-highpte.txt >> >> (gdb) list *0xc058c93f >> 0xc058c93f 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) >> >> >> > > I just added some debug printk()'s to the very beginning of the function and > found out this: > > DEBUG active_evtchns: cpu: 0, sh: 4117237760, idx: 0 > DEBUG sh->evtchn_pending: 4117239808, sh->evtchn_mask: 4117239936 > DEBUG cpu_evtchn_mask(cpu): 0 > > so.. looks like the buggy piece of code (null pointer dereference) is: > cpu_evtchn_mask(cpu)[idx] > Yes; something is trying to use that stuff before the array is allocated. I'm trying to work out a fix now, and I wonder if its related to some (more subtle) interrupt-related problems I'm seeing. J _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |