The patch below seems to fix it. I think there may be a similar issue
with the in order model. There's a bug in the wakeup function of I
believe all the CPU models where it only wakes up from Suspended and
just returns if you're Halted. I have a patch in my queue that fixes it
for the simple CPU, but a more general fix would be appropriate, I
think. I'll leave committing these to you guys since you know your code
best.
Gabe
diff -r be16ad28822f src/cpu/o3/cpu.cc
--- a/src/cpu/o3/cpu.cc Wed Apr 15 13:18:24 2009 -0700
+++ b/src/cpu/o3/cpu.cc Thu Apr 16 22:32:49 2009 -0700
@@ -575,7 +575,7 @@
ThreadContext *src_tc = thread[tid]->getTC();
#endif
// Threads start in the Suspended State
- if (src_tc->status() != ThreadContext::Suspended) {
+ if (src_tc->status() != ThreadContext::Halted) {
continue;
}
Gabe Black wrote:
> 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
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
