asterisk users - Dec 2004 - Ouch, part reset, quickly

Ouch, part reset, quickly restoring reality (0)
Power alarm on module 1, resetting!

I have looked though a lot of email on this issue, and no one seems to have
the answer.

How many people are seeing this on a TDM400 card?

Does anyone have a "REAL" answer to it.

Yes, I do have the power connected to it!

Regards
Garry Taylor

On December 3, 2004 10:33 am, Garry Taylor wrote:
> Ouch, part reset, quickly restoring reality (0)
> Power alarm on module 1, resetting!
>
> I have looked though a lot of email on this issue, and no one seems to have
> the answer.
>
> How many people are seeing this on a TDM400 card?
I would imagine practically everyone.
> Does anyone have a "REAL" answer to it.
No.  Several of us have brought this up with Digium, and Digium seems awful 
tight-lipped.  They ssh into the system and poke around a bit and nothing 
seems to move forward.  

Combined with the "gotta unload/reload the wctdm module every 4-to-8 weeks
to
get it to work again" ... I dunno there is something wrong in that card 
(likely drivers, I would imagine) and it's taking forever to fix, and
it's
being fixed VERY quietly.  I would like to hear an "OFFICAL no bullshit,
here
is where Digium stands" response but every call for one has fallen on deaf 
ears.  Digium knows of the issue, that much is certain.

The TDM4XXP is a great card, if it worked as reliably as the TE405P...  It's
a
great mid-density solution but it's not one I can currently recommend or use
in any kind of "real" environment (i.e. paying customer).  Whenever
anyone
asks what to use I always suggest T100P+Channel Bank simply because I don't 
want the headaches that the TDM4XXP will bring on at this time.

-A.

I have exactly this problem. When it happens, I lose access to some FXS 
ports and get Geiger counter style clicking on the FXOs. I just opened a 
ticket with Digium on the subject, but given what I just read, perhaps I 
should not have high hopes.

</edg>

--On Friday, December 03, 2004 11:33 PM +0800 Garry Taylor 
<garry@steelclaws.net> wrote:
> Ouch, part reset, quickly restoring reality (0)
> Power alarm on module 1, resetting!
>
> I have looked though a lot of email on this issue, and no one seems to
> have the answer.
>
> How many people are seeing this on a TDM400 card?
>
> Does anyone have a "REAL" answer to it.
>
> Yes, I do have the power connected to it!
>
> Regards
> Garry Taylor
>
> _______________________________________________
> 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

>I have exactly this problem. When it happens, I lose access to some FXS 
>ports and get Geiger counter style clicking on the FXOs. I just opened a 
>ticket with Digium on the subject, but given what I just read, perhaps I 
>should not have high hopes.
Kinda same with me; although on some of my FXS with crappy Vista 100's I get
crackly audio but a brand new Panasonic 2.4g cordless it's solid, no
problems. Doesn't matter if I swap ports, the Panasonic is fine, the
vista's
sound like crap. After a reboot, everything's cool. 

Dealing with the problem by cron'ing a reboot every night.

>I have exactly this problem. When it happens, I lose access to
        some FXS 
        >ports and get Geiger counter style clicking on the FXOs. I just
        opened a 
        >ticket with Digium on the subject, but given what I just read,
        perhaps I 
        >should not have high hopes.
        
        Kinda same with me; although on some of my FXS with crappy Vista
        100's I get
        crackly audio but a brand new Panasonic 2.4g cordless it's
        solid, no solid, no
        problems. Doesn't matter if I swap ports, the Panasonic is fine,
        the vista's
        sound like crap. After a reboot, everything's cool. 
        
        Dealing with the problem by cron'ing a reboot every night. 

I filed a problem report long ago with this issue. Right now, when I
boot, and modprobe the fxs, I include the arg "lowpower=1"

/sbin/modprobe wcfxs lowpower=1

This has somewhat almost eliminated this as a prob, but in recent
builds, I've had to bring down asterisk and restart it because of the
"geiger counter" affect on one or more lines.  (I have One 4-port fxs
card, and two fxo cards).

I have an old moto cordless phone hooked up, and when I drop the phone
in it's cradle, or pull it out, there is some feedback (apparently) into
the lines (what else could it be?) and I get the ouch messages.
Occasionally, the ouch message leads to the geiger affect, but not very 
often. And sometimes the ouch messages come on their own.

To recover, rebooting works, but I can also shut down asterisk, do
rmmod wcfxs
rmmod wcfxo

and then reload them

        /sbin/modprobe wcfxo
        /sbin/modprobe wcfxs lowpower=1
        ztcfg 

and restart asterisk. This has always worked for me, YMMV. It's a bit
faster than a full reboot.

When one of the lines is in a geiger state, make sure to get it's state:

echo regdumps for 3,4,5,6:

./fxstest /dev/zap/3 regdump
./fxstest /dev/zap/4 regdump
./fxstest /dev/zap/5 regdump
./fxstest /dev/zap/6 regdump

echo 
echo stats for 3,4,5,6:
echo

./fxstest /dev/zap/3 stats
echo
./fxstest /dev/zap/4 stats
echo
./fxstest /dev/zap/5 stats
echo
./fxstest /dev/zap/6 stats

fxstest is in the zaptel CVS directory. You may have to compile it.
(make fxstest).

To run the above tests, asterisk can't be running. And, of course, the
exact numbers to use will/may be different on your system. redirect the
output to a file and you'll have some data that might be useful to
Digium.

You might want to run the fxtests when the cards are working right, so
that you can compare working/non-working state. It's basically a dump of
register states, which looks amazingly like what you get from your
typical modem.

murf

> > i've debugged the driver well enough and know that the Ouch
message happens
> > when register 0x08 of the module returns >0, which indicates in
most times
> > that digital loopback is enabled on the card. this register is set to
> > /disable/ digital loopback upon an init.
> 
> > the power alarm happens when the line feed (hookstate) of the module
is not
> > in sync with a driver variable which tracks hookstate. the resetting
bit
> > you see is just informational to let you know that the driver is
setting
> > the on-module registers back to what the internal variable says it
should
> > be.
> 
> Very interesting; thank you for sharing this.  In my experience the card 
> starts to act funny when I get ONE of these -- perhaps in some situations 
> there are more than one register that is going awry and the resetting code 
> doesn't reset them all?  I should hack in some debug code that dumps
the
> registers whenever it detects this "power" alarm.
> 
> I should also grab the datasheets and any erratta for the SLIC chipset and
see
> if anything interesting turns up.  Thanks for giving me a direction to
start
> in.
> 
> > i can explain what the driver does when these things happen, however,
i'm
> > thinking that it's more of a hardware issue than anything else.
based on my
> > (admittedly limited) reading of the Tiger320 ProSLIC datasheet, the
> > registers mentioned shouldnt go awry, yet they do.
> 
> I thought the TJ320 was a PCI bridge that provided an 8-bit parallel 
> interface, timer and a serial interface or two, and that there was a
separate
> SLIC chipset which did the actual interfacing to the phone line.
FYI, the tdm fxo chip set from Silicon Labs ( www.silabs.com ) uses
the 3019 for handling pstn line-side interface (and electrical isolation)
and the 3050 for PCM encode/decode, impedance, hybrid, near-end echo
cancellation, interrupts, etc.  The *.pdf's are rather hard to find on 
their site but very detailed (3050 has 110 pages). A quick check of SI's
revision history tends to suggest very few anomalies since released in
2003. The very first tdm fxo modules sold by digium used the rev-C 
and rev-D chips.

The Tiger320 handles, as you mentioned, the pci v2.2 bus interfacing.

Given the sophistication of the SI chip set, it would appear that at
least some functionality exists that has not been taken advantage of 
within the wctdm/zaptel drivers, etc. Part of that history is probably 
related to attempted reuse of code that was written for the x100p (in 
multiple * modules and drivers).

On December 3, 2004 1:04 pm, Andrew Kohlsmith wrote:
> On December 3, 2004 12:43 pm, Steven Critchfield wrote:
> > Is it possible that your PSU isn't up to the task? If you
aren't running
> > a 400 or 500 watt PSU, I would be suspect of the PSU. That error
message
> > was attributed to not getting enough power before they put a power
plug
> > on the board itself. Now you know you aren't getting strangled by
the
> > PCI bus, but it still might not be enough power if you PSU isn't
up to
> > snuff to hold the power stable and high enough.
> 
> I fully believe that that error is incorrect.  I have been running into
these
> problems on rev E, F and H cards on all manner of systems, from P90 with a 
> 450W power supply to the Supermicro server chassis I hvae upstairs with 
> triple-redundant power.  Hell I even put a 100MHz DSO on the +12V rail and 
> there is nothing there, the voltage doesn't move more than a dozen or
so mV
> from +12.00V.
> 
> For some it may be a power issue, but I believe there is either a power 
> *distribution* issue on the TDM4XXP carrier, an electrical error on the FXS
> modules or even some kind of driver issue.
I just started getting this on my system.  I've been running it over a month
in this system with few problem like this and now they are happening
regularly...

Is there a list of possible remedies for it yet?  Anyone heard from Digium
about the problem?

-- 
-M

There are 10 kinds of people in this world:
	Those who can count in binary and those who cannot.