First some info that might be useful. When I stopped my second run it spit out statistics and I noticed that no instructions actually committed. I tried running with Exec and got the following forever which starts immediately and is easy to see.
145886000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : 145901000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : 145916000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : 145931000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : 145946000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : 145961000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : 145976000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : 145991000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : 146006000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : 146021000: system.cpu T0 : @arch/alpha/kernel/head.S+1153 : call_pal 0 : IntAlu : Second, you're right. It's this one specifically: Revision: 6030 Branch: default Author: Steve Reinhardt <[email protected]> 2009-04-15 13:13:58 Committer: Steve Reinhardt <[email protected]> 2009-04-15 13:13:58 Parent: 6029:007c36616f47 (Get rid of the Unallocated thread context state.) Child: 6031:be16ad28822f (ThreadState: initialize status to Halted in constructor.) Update stats after elimination of Unallocated state. Somehow ending threads with halt() instead of deallocate() reduces the squash count on o3 by 1 (and a few other similarly trivial changes). Steve Reinhardt wrote: > I'm taking a look at this now... I suspect it may be related to my > recent thread status changes. > > Steve > > On Thu, Apr 16, 2009 at 9:27 PM, Steve Reinhardt <[email protected] > <mailto:[email protected]>> wrote: > > Those tests passed on April 5 and took 395 and 440 seconds on > zizzer, respectively. So (1) they must have broken since then and > (2) if they're taking longer than 10 minutes or so (depending on > where you're running them) they're definitely broken. > > Steve > > > On Thu, Apr 16, 2009 at 9:08 PM, Gabe Black <[email protected] > <mailto:[email protected]>> wrote: > > All the regressions passed with my changes applied except for > tsunami-o3 > and tsunami-o3-dual. Those had run for 15 hours and not > finished when I > checked on them which is obviously way to long. I removed my > patches and > tried it on the head, but it's been running there for an hour > and still > hasn't finished. I'll leave it running over night just in > case, but I > think those are broken in the head. In light of that, I'm > going to wait > until that gets fixed to do my push, so don't worry about > holding off > any more. > > Gabe > > Gabriel Michael Black wrote: > > Quoting Korey Sewell <[email protected] > <mailto:[email protected]>>: > > > > > >> Gabe, briefly can you talk about what you're big push is > going to be on? > >> > > > > It's almost all stuff to get an SMP kernel to boot in x86. > There are a > > couple patches that affect things outside of x86, but I > think those > > are limited to the simple CPU. > > > > > >> I'm really scrambling to get these MIPS fixes in for O3 > since a major > >> culprit of it getting continually broken is the lack of a > regression > >> test. People (including me) can change stuff and > unknowingly break > >> MIPS code. Then, I'm back to fixing what already should be > working. > >> > >> If possible, give me a day (hopefully will be quick) to finish > >> cleaning up this MIPS stuff so that I can include that in > the testing > >> of whatever changes you have. Or maybe the changes you have > dont > >> affect this but I'm not sure yet since I dont have the > exact fix for > >> the MIPS code. > >> > > > > I think it's pretty unlikely we'll affect each other, but > I'm going to > > be pushing around 60 patches and I really don't want to have to > > reverify all those as compared to 5 or 6. My almost up to > date patch > > queue is available from m5sim.org <http://m5sim.org> if you > want to take a look. You > > could probably use those patches on your own tree and run your > > uncommitted regression and I'm betting it will pass. I can > hold off if > > you really, really want me to, but I'd prefer not. > > > > Gabe > > > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/mailman/listinfo/m5-dev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
