I ran tracediff on the two versions (before and after the latest
changeset), and unsurprisingly it looks like enabling tracing on the latest
code suppresses the problem, so there wasn't any difference in the stats
output. However, it did uncover two places where there is some
non-determinism in the execution that didn't affect the stats, one being in
the cpuid instruction and the other being an IN operation. Here are the
relevant tracediff bits, leaving out what appear to be downstream effects
of these two instructions. Does anyone have any insight into what these
differences are?
Steve
@@ -538689555 +538689555 @@
63942514000: system.cpu.[tid:0]: Reading int reg 3 (3) as 0x405.
63942514000: system.cpu.[tid:0]: Reading int reg 1 (1) as 0.
63942514000: system.cpu.[tid:0]: Reading int reg 2 (2) as 0.
-63942514000: system.cpu.[tid:0]: Setting int reg 0 (0) to 0x7273940.
-63942514000: system.cpu.[tid:0]: Setting int reg 3 (3) to 0x1864ffb000.
-63942514000: system.cpu.[tid:0]: Setting int reg 1 (1) to 0x6d86838.
-63942514000: system.cpu.[tid:0]: Setting int reg 2 (2) to 0x7f3f63188eba.
-63942514000: system.cpu + A0 T0 : @identify_cpu+48 : CPUID eax
: IntAlu : D=0x00007f3f63188eba
+63942514000: system.cpu.[tid:0]: Setting int reg 0 (0) to 0x75ae960.
+63942514000: system.cpu.[tid:0]: Setting int reg 3 (3) to 0x18ad95d000.
+63942514000: system.cpu.[tid:0]: Setting int reg 1 (1) to 0x70c1838.
+63942514000: system.cpu.[tid:0]: Setting int reg 2 (2) to 0x7f6cabaeaeba.
+63942514000: system.cpu + A0 T0 : @identify_cpu+48 : CPUID eax
: IntAlu : D=0x00007f6cabaeaeba
63942514000: system.cpu: Fetch
63942514000: system.cpu: Fetch: PC:0xffffffff8078c342
63942514000: system.cpu: Translating address 0xffffffff8078c340
@@ -6685031166 +6685031166 @@
285288349000: system.cpu.dcache: Handling response to 80000000000003f4
285288349000: system.toL2Bus.respLayer: The bus is now busy from tick
285288349000 to 285288351000
285288352000: system.cpu.[tid:0]: Reading int reg 0 (0) as 0x1.
-285288352000: system.cpu.[tid:0]: Setting int reg 0 (0) to 0xd8.
-285288225000: system.cpu + A0 T0 : @set_fdc+135.2 : IN_R_R : ld al,
MS:[t2 + 0x1800000000] : MemRead : D=0x00000000000000d8 A=0x18000003f4
+285288352000: system.cpu.[tid:0]: Setting int reg 0 (0) to 0xe0.
+285288225000: system.cpu + A0 T0 : @set_fdc+135.2 : IN_R_R : ld al,
MS:[t2 + 0x1800000000] : MemRead : D=0x00000000000000e0 A=0x18000003f4
285288352000: system.cpu: Fetch
285288352000: system.cpu: Complete ICache Fetch for addr 0
285288352000: system.cpu.[tid:0]: Setting int reg 16 (16) to 0.
On Mon, Jul 16, 2012 at 7:48 AM, Andreas Hansson <[email protected]>wrote:
> Hi Nilay,
>
> The error only seems to manifest itself with the latest changeset applied.
> However, after a bit of digging, the actual problem seems to be related to
> the conditional flags in the CPU model (valgrind output below):
>
> ==11917== Conditional jump or move depends on uninitialised value(s)
> ==11917== at 0x96A37C: X86ISAInst::WripFlags::execute(TimingSimpleCPU*,
> Trace::InstRecord*) const (timing_simple_cpu_exec.cc:11421)
> ==11917== by 0xF1BDFA: TimingSimpleCPU::completeIfetch(Packet*)
> (timing.cc:685)
> ==11917== by 0xF1C95C: TimingSimpleCPU::fetch() (timing.cc:566)
> ==11917== by 0xF1D9F6:
> TimingSimpleCPU::advanceInst(RefCountingPtr<FaultBase>) (timing.cc:629)
> ==11917== by 0xF1BE9C: TimingSimpleCPU::completeIfetch(Packet*)
> (timing.cc:700)
> ==11917== by 0xF1C95C: TimingSimpleCPU::fetch() (timing.cc:566)
> ==11917== by 0xF1D9F6:
> TimingSimpleCPU::advanceInst(RefCountingPtr<FaultBase>) (timing.cc:629)
> ==11917== by 0xF1BE9C: TimingSimpleCPU::completeIfetch(Packet*)
> (timing.cc:700)
> ==11917== by 0xF1F07B:
> TimingSimpleCPU::IcachePort::recvTimingResp(Packet*) (timing.cc:726)
> ==11917== by 0xD0795C: PacketQueue::trySendTiming()
> (packet_queue.cc:147)
> ==11917== by 0xD07A4A: PacketQueue::sendDeferredPacket()
> (packet_queue.cc:183)
> ==11917== by 0xC4F8A3: EventQueue::serviceOne() (eventq.cc:204)
>
>
> Could you have a look at this (as I believe you were the last one to make
> changes to this bit of the code)?
>
> Thanks,
>
> Andreas
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Nilay Vaish
> Sent: 13 July 2012 09:32
> To: gem5 Developer List
> Subject: Re: [gem5-dev] Cron <m5test@zizzer>
> /z/m5/regression/do-regression quick
>
> On Fri, 13 Jul 2012, Cron Daemon wrote:
>
> > *****
> build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic FAILED!
> > *****
> build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp FAILED!
> > *****
> build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing FAILED!
> > *****
> build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp FAILED!
> > *****
> build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-timing
> FAILED!
> > scons: `build/ALPHA_MOESI_hammer/tests/opt/quick/fs' is up to date.
> > scons: *** Error 1
> > scons: *** Error 1
> > scons: *** Error 1
> > scons: *** Error 1
>
> Can some one checkout the error that occurred in X86 pc-simple-timing?
>
> --
> Nilay
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
