Hi Newbie, or would you prefer to be called VoIP(y)? :-)
Thanks for the advice, It's great to hear from somebody that has
suffered in the same way :-)
I've cc'd in the dev and user lists mostly so that others looking for
the same issue (FXO PCI Master Abort) can find some info! - hope you
dont mind...
On the card itself.
I am assured by the vendor that they had the card up and running in a
machine. Indeed, the vendor has taken one home, called me through it,
and then given it to me... so I'm reasonably sure that under SOME
situations, these cards work.... and I now have 2 of these cards!
I'd be interested to know, are all the 3 cards you have had "identical"
in terms of how they look? Do you still have them? Can we compare notes
- (off list)?
On the Zaptel driver...
There are clearly inconsistencies in the driver, which I feel should
be sorted out.... However, they are in code which people with working
systems say is never reached. So.. yes, the driver should be cleaned up
in order to handle the IRQ's better, but the question remains, why am
I/you getting the Master Aborts in the first place...
If the patch that I've done to the driver is the right thing to do,
then maybe thats an answer for me/you/others. I still seem to have some
problems, so I need to understand those first (see other post). At
least the Master Abort doesn't bring the whole machine down.
What I can't tell is why WE get the Master Aborts in the first place....
Speculation would be good! Any ideas?
Cheers
Mark.
On 17 Aug 2005, at 07:16, VoIP Newbie wrote:
Dear Mark,
I got 3 X101P clone cards from 3 different vendors. One of them has
the same problem like yours. Another one has echo issue. Only one from
www.broad-tel.com works fine for me.
You may want to contact the vendor and get one for yourself instead of
modifying ZAPTEL software.
Newbie
On 8/16/05, Mark Burton <[EMAIL PROTECTED]> wrote:
Hi, I've been trying to debug the problem with the X101P giving FXO
PCI Master Aborts... I'm doing this blind, and I really need some info
on the X101P's register map - or best of all, the conditions under
which it can generate an IRQ with a mask of 0x10.
I have so far set up the mask for the IRQ's in the interrupt handler
(so the poor thing doesn't keep getting them)[as per previous post],
then patched ztcfg so it actually starts the watchdog (which is
assumed
by the driver, but in reality doesn't happen - of course it doesn't
need to, because under normal conditions there is no need for the
watchdog - I guess?)
That much gives me a system which runs, hits a PCI Master abort (or at
least an IRQ with a mask of 0x10), and then stops the dma, masks the
IRQ... then the watchdog starts the dma again, unmasks the IRQ, at
which point it gets another IRQ before the next watchdog beat.... so
the watchdog can't help.
I have tried being a bit more brutal with the activities in the
watchdog routine.... I just caused myself some kernel panic's :-)
Again, any help appreciated!
Cheers
Mark.
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
