If we have /etc/dahdi/span-types.conf but it doesn't have any
line, we should avoid using the option -S to astribank_hexload.
Fix the test for this.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Don't run the final astribank_is_starting if asterisk is hotpluggable.
Likewise, if there's no xpp_order file, waiting is pointless as the hook
can't count Astribanks.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* 'time' was added here for debugging and never actually needed.
* It actually causes a minor bashism issue.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* New asynchronous behavior is used only when two conditions are met:
- Finding new $ASTERISK_SUPPORTS_DAHDI_HOTPLUG=yes in /etc/dahdi/init.conf
This should be set only when Asterisk support hotplug and configured
to use it (no_failed_channels==1).
- DAHDI auto_assign_spans==0
* Adapt /usr/share/dahdi/astribank_hook:
- Refactor old twinstar behavior into functions
- Add new behavior in a function (just enable the Asrribank watchdog)
- Call the correct function.
* Adapt init script:
If asynchronous behavior is on, don't wait for all Astribanks to
finish initialization (it's enough that we saw all/some of them)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Do print a message if no semaphore exists. It means that either there
are no Astribanks, or existing Astribanks were already initialized.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Why:
* Doing "clear_halt" is normally the right thing to do on startup.
* The original observed problem is better fixed via USB bios settings.
* Defaulting to no "clear_halt" cause more problems on other platform
combinations (hardware/kernel).
The change:
* We now reverted to do "clear_halt" by default.
* The XTALK_OPTIONS may now contain either "use-clear-halt" (the default)
or "no-use-clear-halt" to override for debugging/testing.
Original commit: ca7c04e9cb
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
DAHDI 2.9.2 added support for -S (span specs). However if this option
was not specified, it fails to run.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
The variable 'default_law' was the result of a partial renaming of the
original variable 'law'. Let's keep all of them in sync.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* Added optional '-S <span-spec>' argument to astribank_hexload:
- Allow passing PRI span specification to EC firmware loader.
- The span specifications is whitespace/comma separate list
of items.
- Each item is: <span>:<type> (Example: 3:T1)
- The <span> may use shell-like globbing (e.g: *:E1 or [12]:T1)
- Any span not matched in the span specification will be set
as without the new '-S' option (i.e: depends on the '-A' option).
* Adapted xpp_fxloader:
- Read specification for both device label and wildcard from
/etc/dahdi/span-types.conf
- If the result is non-empty, pass it as '-S <span-spec>' to
the EC firmware loader.
* Read first from modern configuration files
(/etc/dahdi/span-types.conf)
- Support either exact label match or complete '*' match in the
configuration file.
* Fallback to legacy /etc/dahdi/xpp.conf
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Improvements to the xpp tool dahdi_registration:
* Use the new xpp driver with support for dahdi_registration sysfs
attribute in each device.
* Wait for UDEV to finish handling span assignments (via
dahdi_waitfor_span_assignments).
* Still supports legacy drivers without this, by falling back
to old style iterative "registration" on each xpd.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* Don't use "usb_clear_halt" by default anymore
- It caused problems with specific devices in the past
- Now it cause problems with specific servers as well (64 bits, USB3)
* Add an "XTALK_OPTIONS" environment variable to pass options:
- Use it to implement a "use-clear-halt" boolean option that
restore original behavior.
- Also use it for "no-lock" option which replace the legacy
environment variable "XUSB_NOLOCK".
* Compile with "-Wall -Werror"
* Better dependency calculation:
- Explicit listing of sources, don't use wildcards.
- Pass various CFLAGS to dependency calculation as well.
- Make sure a failure is propagated
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* The "spantypes" generator had E1 default if no 'line-mode' parameter
was passed.
* As a result the new logic in "dahdi_span_types dumpconfig" had no
effect when called from dahdi_genconf, as it was always called
with "--line-mode=" argument.
* Now "dahdi_genconf spantype" behaves just like
"dahdi_span_types dumpconfig":
- The "--line-mode=" forces generation of provided line-mode (E1/J1/T1)
- Without this option, the generated config matches the current spans
state according to new dahd_span_types default logic:
- Wildcard rule if all spans have same line-mode.
- Uncommented specific matches if spans have different line-modes.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixes a regression since 949ea4ca9f
(2.7.0) - allows using an Astribank with no serial.
* Some of the olderst Astribanks don't have a serial number burned in
them. Thus there is no serial attribute for the sysfs USB device node.
* waitfor_xpds identifies the Astribanks by their serial numbers.
* An lone Astribank without serial number would thus block waitfor_xpds
(until timeout).
* Now we warn about them.
* We also try to handle it gracefully. As long as there's only one
of thease, it would be counted as "NO-SERIAL".
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* The system state causing the bug:
- DAHDI has auto_assign_spans==1
- No /etc/dahdi/assigned-spans.conf
* The bug scenario:
- During initial device detection, they are assigned by
DAHDI driver.
- Later we run "dahdi_span_assignment remove"
- Then, a "dahdi_registration on" would not assign any span.
* The fix:
- Using the '-R' option, force "dahdi_registration on" to also
do "dahdi_span_assignment auto" on relevant devices.
- This is the way it's called by /usr/share/dahdi/dahdi_auto_assign_compat
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
auto_assign_spans is an int and may have legal values other than 1. It
is legal (though pointless) to use: modprobe dahdi auto_assign_spans=3.
Any value != 0 is true.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixes a regression introduced in
3572bb5a13 (before 2.7.0) - most of the
dahdi_perl tools will fail for an Astribank with no modules claiming
"No XPDs for '/sys/bus/astribanks/devices/xbus-00'"
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* Add '--line-mode=<E1|T1|J1>' option to dahdi_span_types:
- Will first generate a wildcard entry (* *:<type>)
- All later entries will be commented-out.
- Manually uncommenting any of them will create an "override"
(e.g: mixed system with all spans T1, but some E1)
* Now dahdi_genconf does not generate span-types.conf by default:
- Added '--line-mode=<E1|T1|J1>' option to trigger generation
- This parameter will be passed to "dahdi_span_types dumpconfig"
- Also explicit specification of 'spantypes' as an argument will
trigger a similar generation (with a default of 'E1').
- The line-mode may also be passed to the generator directly
with identical results. Example:
dahdi_genconf spantypes=line-mode=T1
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-By: Russ Meyerriecks <rmeyerriecks@digium.com>
This is a documentation change, that hopefully will help until I can remember
the names of the new generators.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
A sane value for span-types.conf is either "all E1" or "all T1". Either
way it is not hardware-dependent, and hence no point in regenerating on
when the hardware changes.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
All new dahdi tools and utilities will be prefixed with "dahdi_" in order to
avoid any future conflicts with other packages.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>
If you installed dahdi tools and did not specify DAHDI_PINNED=yes on the
makefile, when you run dahdi_genconf you would get an error like the following:
# dahdi_genconf
sh: span_types: command not found
Command failed (status=32512): 'span_types dumpconfig > /etc/dahdi/span-types.conf' at ...
This change allows the generator for span-types.conf and span-assignements.conf
check for the existence of the utilities before attempting to call them.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* If xpp.dahdi_autoreg parameter is 'Y' -- Skip actuall registration.
* If dahdi.auto_assign_spans is '0' and there's no /etc/dahdi/pinned-spans.conf
Than use 'span_assignments auto ...' to assign device spans.
* Since dahdi_registration iterate in correct xpp_order, the span
assignment logic provides migration path for users who did not
generate their pinned-spans.conf configuration yet.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
One line change to re-include a missing header
Reported-By: Anthony Messina
Internal-Issue-ID: DAHTOOL-60
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* This xusb_spec:
- Is a dummy struct used for this xusb instance only.
- Is now passed by reference from caller.
- So caller now manage the life cycle of this struct
* Also, demote one INFO() to DBG() (library should not print
on its own)
* Also minor fix to DBG() output of spec initialization (leading 0)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: Xorcom xtalk (r9303)
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@10711 17933a7a-c749-41c5-a318-cba88f637d49
xtalk: dump_packet() may now be used without debug flags by passing
mask == 0.
Origin: Xorcom xtalk (r9302)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@10710 17933a7a-c749-41c5-a318-cba88f637d49
