Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
References: 
 >RE: Subject: listen DCL program woes (From: Philip Lukidis <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.