Hi, Alex and Aron Thank you for your various comments, I attach the patche which reflect this discussion. Please edit the comment line in patches, as you like. I change the last line of document from previous mail.
Thanks Atsushi SAKAI ========================================== This patch intends to fix the oops message from timer_interrupt on VTI domain. This problem occurred when we test PV-on-HVM driver by ltp-20061121. Typical message shown as follows. ltp Now Running...( Exception mode ) dom=domVTI 1 times Unable to find swap-space signature Oops: timer tick before it's due (itc=ed98bb5849,itm=ed98bb5849) Oops: timer tick before it's due (itc=f20bca8ca3,itm=f20bca8ca3) Oops: timer tick before it's due (itc=f4ea4e2b32,itm=f4ea4e2b32) mmap1(7392): unaligned access to 0x60000fffffffb634, ip=0x200000000004fad0 mmap1(7392): unaligned access to 0x60000fffffffb634, ip=0x200000000004fad0 ltp End These oops messages are generated because timer_interrupt checks the condition itc > itm. Currently Xen-hypervisor outputs following values, max(current_itc,vtm->last_itc), Some occasion, oops message appeared if we use the value of vtm->last_itc as ia64_get_itc() return value, because the vtm->last_itc is same as itm. To fix this issue, it needs to add return value like +1. But, ia64_get_itc() is handled at [EMAIL PROTECTED] and it works same logic of now_itc()@vlsapic.c. And these routines shared vtm->last_itc. So I fix this problem by adding +1 at caller of update_last_itc. Signed-off-by: Atsushi SAKAI <[EMAIL PROTECTED]> ========================================== Alex Williamson <[EMAIL PROTECTED]> wrote: > On Tue, 2007-01-23 at 16:44 -0500, Aron Griffis wrote: > > Atsushi SAKAI wrote: [Mon Jan 22 2007, 07:36:55PM EST] > > > Oops: timer tick before it's due (itc=ed98bb5849,itm=ed98bb5849) > > > Oops: timer tick before it's due (itc=f20bca8ca3,itm=f20bca8ca3) > > > Oops: timer tick before it's due (itc=f4ea4e2b32,itm=f4ea4e2b32) > > ... > > > > > > These oops messages are generated > > > because timer_interrupt checks the condition itc > itm. > > > > Is that the right comparison though? itc isn't guaranteed to return > > different values on subsequent fetches, and the interrupt is generated > > when itc == itm, right? So shouldn't the condition be itc >= itm? > > Good point. With the slower ITC on a Montecito system, I don't know > if anything would prevent you hitting the interrupt handler when itc == > itm. Perhaps a Montecito fix for Linux-ia64 to use time_after_eq() > would eliminate this problem. > > Alex > -- > Alex Williamson HP Open Source & Linux Org. >
fix-vti-oops-take2.patch
Description: Binary data
_______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
