Well, this is interesting. I left the case open overnight, and the dead bit
is not set (streaming continued). I'll check for a fan/dirt problem.
-----Original Message-----
From: Eric Anderson [mailto:email@hidden]
Sent: Wednesday, October 19, 2005 1:53 PM
To: FW Liste
Subject: Re: Subject: listen DCL program woes
"Receive" is the correct DMA for your listening program.
The "dead" bit in the OHCI status can mean all sorts of things, such as:
a. Program error such as illegal opcode
b. Branch to illegal address
c. Memory error storing payload
d. Memory error fetching program
e. Internal error in DMA or FIFO
f. Illegal PCI activity, perhaps from an add-in card
One thing "dead" should not indicate is overrun; overrun should cause a
branch to zero and a clean stop of the DMA (unless your overrun is a
loop like Tommy described, which should remain alive).
The event code "e" in 0x4000884e indicates "evt_unknown", which seems
to rule out b, c, and d above (each of them has a dedicated event code
other than "e").
Since this is so hard to reproduce, and limited to one machine (?), it
could be a hardware problem, such as AC power noise, thermal excess,
bad DRAM, etc. If you have any third-party RAM, I would definitely
swap it out and see if things change, or duplicate your experiment on a
second G5 system.
Eric
> I've reproduced the issue with the debug firewire stack. Using Mr.
> Registry,
> I see that the receive contextControl is 0x4000884e. It seems that
> the dead
> bit is set here, and I take "receive" to mean listen. In any case I'm
> sure
> that my talk DCL callbacks are continuing to run.
>
> Has anyone else bumped into this? I will try and use
> IOMallocContiguous to
> see
> if that places less stress on the scatter gather engine of the card.
> It's
> strange, but I have problems only with this one G5 machine, and it
> takes
> hours to reproduce.
>
> thanks,
>
> Philip Lukidis
On Oct 19, 2005, at 9:00 AM, Philip Lukidis wrote:
> Thanks for your answer. Could you please point out the source of this
> documentation? Somehow this does not sound familiar to me, though I
> do understand your point. I should read this fully.
>
> As far as I know, I have not detected an overrun, and the same test
> passed OK on a G4, which is quite slower than my problematic G5.
>
> thanks,
>
> Philip Lukidis
>
> -----Original Message-----
> From: Tommy Schell [mailto:email@hidden]
> Sent: Wednesday, October 19, 2005 11:20 AM
> To: Philip Lukidis
> Cc: FW Liste
> Subject: re: Subject: listen DCL program woes
>
>
> This doesn't answer your question, but I put a safety mechanism in my
> Firewire DCL program
> (actually NuDCL program) where if an overrun occurs, I do a self loop
> on the last buffer to
> prevent an actual overrun.
> So I have a 3 buffer safety zone as the documentation suggests, and
> with the 3rd buffer,
> at the end I jump back to the beginning of the 3rd buffer.
> If the hardware gets too far ahead of the software, the hardware is
> then held in check.
> That way in the event of an overrun (which happens from time to time
> on my G4), things don't
> fall apart, I just lose a couple frames (video frames, in my case),
> and then things go back
> to normal.
> And then with each callback, I move the 3 buffer zone forward 1, and
> adjust my jumps appropriately.
>
> Tommy
>
>
> *************************
>
> Message: 1
> Date: Tue, 18 Oct 2005 09:30:17 -0400
> From: Philip Lukidis <email@hidden>
> Subject: listen DCL program woes
> To: email@hidden
> Message-ID: <79710AF8DF7794458457EAF404E82431053E7B68@GCMTLEXC>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello. I have problems with my listen DCL program, in that it
> eventually
> stops running (callbacks cease, as least). It has the overrun
> detection
> system as discussed in the isoch DCL html document (if the overrun
> proc is
> called, it means that the jumps were not modified in time, and
> overrun has
> occurred). I do not believe that overrun has occurred, though, due to
> driver debug output, and that it does not occur on some slower
> machines.
> This problem occurred after many hours only. It seems that my play DCL
> callbacks are being called, though. Unfortunately I don't know if a
> fatal
> OHCI error occurred (handleUnrecoverableErrorInt) because the IOLog is
> swamped with debug output (firelog was not on at the time).
>
> Is there any other reason for a DCL program callbacks to stop being
> called?
> Unfortunately I didn't have debug OHCI installed, and so I cannot use
> mr.
> registry to any effect. I have listed my DCL program below.
>
> thanks,
>
> Philip Lukidis
>
> Record DCL program listed here (note that there is one dummy receive
> at the
> end if overrun is detected- it does not have an update called on it):
> kDCLLabelOp [0x3235a400] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232903c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235a558 (x1)
> kDCLLabelOp [0x3235a558] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232905c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235a6b0 (x1)
> kDCLLabelOp [0x3235a6b0] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232907c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235a810 (x1)
> kDCLLabelOp [0x3235a810] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232909c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235a968 (x1)
> kDCLLabelOp [0x3235a968] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323290bc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235aac0 (x1)
> kDCLLabelOp [0x3235aac0] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323290dc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235ac24 (x1)
> kDCLLabelOp [0x3235ac24] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323290fc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235ad7c (x1)
> kDCLLabelOp [0x3235ad7c] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232911c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235aed4 (x1)
> kDCLLabelOp [0x3235aed4] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232913c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b038 (x1)
> kDCLLabelOp [0x3235b038] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232915c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b190 (x1)
> kDCLLabelOp [0x3235b190] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232917c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b2e8 (x1)
> kDCLLabelOp [0x3235b2e8] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232919c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b44c (x1)
> kDCLLabelOp [0x3235b44c] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323291bc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b5a4 (x1)
> kDCLLabelOp [0x3235b5a4] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323291dc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b6fc (x1)
> kDCLLabelOp [0x3235b6fc] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x323291fc num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b85c (x1)
> kDCLLabelOp [0x3235b85c] (x1)
> kDCLReceivePacketStartOp size = 396 (x12)
> kDCLTimeStampOp timestamp = 0 (x1)
> kDCLUpdateDCLListOp list = 0x3232921c num = 1 (x2)
> kDCLCallProcOp addr = 0x31357838 (x1)
> kDCLJumpOp label = 0x3235b9b4 (x1)
> kDCLLabelOp [0x3235b9b4] (x1)
> kDCLReceivePacketStartOp size = 396 (x1)
> kDCLCallProcOp addr = 0x3135791c (x1)
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Firewire mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/firewire/email@hidden
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Firewire mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/firewire/email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Firewire mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/firewire/email@hidden
This email sent to email@hidden
