Re: What is the current state of Dom0 kernel support? / crash with 2.6.31-rc5 32bit PAE

[Jeremy Fitzhardinge <jeremy@goop.org>]

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