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 vmx_asm_mov_from_ar@xxxxxxxxxxx
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 <sakaia@xxxxxxxxxxxxxx>
==========================================
Alex Williamson <alex.williamson@xxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|