On Tue, Jan 26, 2010 at 11:09 PM, Igor Kovalenko <igor.v.kovale...@gmail.com> wrote: > On Fri, Jan 22, 2010 at 11:32 PM, Blue Swirl <blauwir...@gmail.com> wrote: >> On Tue, Jan 19, 2010 at 10:25 PM, Igor V. Kovalenko >> <igor.v.kovale...@gmail.com> wrote: >>> From: Igor V. Kovalenko <igor.v.kovale...@gmail.com> >>> >>> sparc64 timer has tick counter which can be set and read, >>> and tick compare value used as deadline to fire timer interrupt. >>> The timer is not used as periodic timer, instead deadline >>> is set each time new timer interrupt is needed. >>> >>> v2 -> v3: >>> - added missing timer debug output macro >>> - CPUTimer struct and typedef moved to cpu.h >>> - change CPU_SAVE_VERSION to 6, older save formats not supported >>> >>> v1 -> v2: >>> - new conversion helpers cpu_to_timer_ticks and timer_to_cpu_ticks >>> - save offset from clock source to implement cpu_tick_set_count >>> - renamed struct sun4u_timer to CPUTimer >>> - load and save cpu timers >>> >>> v0 -> v1: >>> - coding style >> >> My debugging of Linux panic has not been very fruitful. Once I got the >> panic triggered while single stepping calibrate_delay() with GDB and >> keeping enter key pressed. Then I missed the fault though. >> >> One possible problem is that 4dc28134f3d7db0033c6b3c5bc4be9a91adb3e2b >> added interrupt checks to the helpers which means that they can cause >> faults, but translation of the instructions was not changed to take >> this into account. But when I added calls to save_state() in >> translate.c, it didn't change anything. > > The issue is with PUT_CWP64 - linux kernel does read cwp which > happens to be zero, decrements it and writes the result to cwp. > Expected value is max window id but we store zero cwp, > and return path from trap handler does restore wrong window. > > I'll post the fix now, and then try to clean up the rest of timer patch.
Excellent analysis! I await your patch anxiously.
