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
|