[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-ia64-devel] alt_itlb_miss?
On Tue, 2006-04-18 at 16:08 -0600, Alex Williamson wrote: > Hi, > > I know we had some discussion about this back in February, but I'm > hitting the alt_itlb_miss handler in Xen and blowing up. The scenario > where I see this is when the EFI runtime code doesn't happen to be > covered by the TR inserted for PAL. The box I have with this slightly > different, but perfectly valid, address map dies when calling > efi_gettimeofday(). Back in February, it seemed like we disabled the > alt_itlb_miss handler thinking that everything would be covered by the > TRs inserted for the kernel and PAL, but I don't think we considered > other parts of firmware that might not be in the same granule as PAL. > It's actually surprising to me that we haven't hit this yet. Is there > any reason we should keep the FORCE_CRASH at the end of alt_itlb_miss, > or can I get rid of it? Thanks, FWIW, here's some more data about the system state when I hit the FORCE_CRASH in alt_itlb_miss (this is for the case of dom0 doing efi.get_time via fw_hypercall): cr.ifa = 0xf00000003ea57570 cr.iip = 0xf00000003ea57570 b0 = 0xf000000004086020 (virt_get_time+0x80) psr.cpl = 0 rr0 = 0x0000000000100038 rr1 = 0x0000000001000439 rr2 = 0x0000000002000439 rr3 = 0x0000000003000439 rr4 = 0x0000000004000439 rr5 = 0x0000000005000439 rr6 = 0x0000000006000439 rr7 - 0x0000000007000439 The PAL ITR is at 0xf00000003f000000. The system I'm typically using has the EFI runtime section covered by the PAL ITR. Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |