[asterisk-users] TE410P (1st) without cables always green

[Shaun Ruffell]

On Tue, Feb 07, 2012 at 05:33:03PM +0100, Patrick Lists wrote:
> On 07-02-12 16:30, Shaun Ruffell wrote:
> [snip]
> >
> >It looks like your development box is having problems with
> >interrupts from the card. Once you run dahdi_cfg for the span  you
> >should be getting 10000 interrupts/sec and above I can see you only
> >got 28.
> >
> >I've seen this recently with some risers which was the reason for
> >commit 10380 "wct4xxp: Fail startup if not generating interrupts."
> >[1]
> >
> >[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10380
> 
> To be honest the "DAHDI startup failed: Input/output error" error
> message provided by dahdi_cfg is not very helpful. Would it perhaps
> be an idea to use the message in the kernel log "wct4xxp
> 0000:02:08.0: Interrupts not detected." also in the error message
> from dahdi_cfg (at least the "interrupts not detected part")? That
> would give a clue what's going on without having to dig through
> logfiles.
> 
> Just my 0.02.
> 
> Regards,
> Patrick

I hear what you're saying although I don't think it's practical in
this case.

For drivers, when there is a general hardware failure the
recommended practice is to return -EIO and log a message in the
kernel log. The EIO is the clue that the log should be checked.
Otherwise what typically happens is driver writers look through all
the different error codes and try to find a one with a description
that matches up with what they feel the problem is. The problem with
this approach is that different error codes mean different things to
different user mode code (EFAULT, ETOBIG, ENOSYS, EINTR, etc..). 

So one alternative would be for dahdi driver to have their own
message log and then users of DAHDI interfaces could call an IOCTL
to read the buffer on failure...but this is more code than
necessary, IMO, for what should be a rare failure condition and
these messages would also become set in stone as part of the API and
couldn't change as necessary within a particular stable branch.

The other alternative would be for dahdi_cfg to assume an EIO from a
startup always means interrupts were failing, but this isn't future
proof in case there are other hardware / platform failures that can
be detected in the startup code.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org