<div dir="ltr"><br><br><div class="gmail_quote">On Sun, Nov 15, 2009 at 1:29 PM, Eric van der Vlist <span dir="ltr"><<a href="mailto:vdv@dyomedea.com">vdv@dyomedea.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Le samedi 14 novembre 2009 à 20:44 +0100, Eric van der Vlist a écrit :<br>
<div class="im"><br>
> and playing with "udevadm test", I have noticed that the following rule:<br>
><br>
> +++++++++++++++++++++++++++++++++++++++++++<br>
> KERNEL=="[0-9]*", GOTO="xpp_usb_add_end"<br>
> +++++++++++++++++++++++++++++++++++++++++++<br>
><br>
> is always met and that if I comment it, the astribank get initialized.<br>
><br>
> Is that safe to remove this rule or is there a better solution?<br>
<br>
</div>I am doing some more tests and that rule really seems to be doing the<br>
difference.<br>
<br>
I also notice that even when that rule is commented, plugging an<br>
uninitialized astribank after the server has been restarted doesn't seem<br>
to work: for whatever reason, when I try to load the dahdi module in<br>
asterisk I get this error message:<br>
<br>
asterisk*CLI> module load chan_dahdi.so<br>
Unable to load module chan_dahdi.so<br>
Command 'module load chan_dahdi.so' failed.<br>
[Nov 15 11:10:45] WARNING[2640]: pbx.c:5048 ast_register_application2: Already have an application 'DAHDISendKeypadFacility'<br>
== Parsing '/etc/asterisk/chan_dahdi.conf': == Found<br>
== Parsing '/etc/asterisk/dahdi-channels.conf': == Found<br>
== Parsing '/etc/asterisk/users.conf': == Found<br>
[Nov 15 11:10:45] WARNING[2640]: chan_dahdi.c:2121 dahdi_open: Unable to specify channel 1: No such device or address<br>
[Nov 15 11:10:45] ERROR[2640]: chan_dahdi.c:10022 mkintf: Unable to open channel 1: No such device or address<br>
here = 0, tmp->channel = 1, channel = 1<br>
[Nov 15 11:10:45] ERROR[2640]: chan_dahdi.c:15972 build_channels: Unable to register channel '1-2'<br>
<br>
This isn't a big deal since I won't be doing that so often on a<br>
production server, but that may be worth mentioning...<br>
<br>
Another weirdness is that dadhi tools keep complaining<br>
that /sys/bus/xpds/devices/00:0:0/timing_priority is missing:<br>
<br>
vdv@asterisk:~$ sudo lsdahdi<br>
Use of uninitialized value $busnum in sprintf at /usr/local/share/perl/5.10.0/Dahdi/Hardware/USB.pm line 100.<br>
Use of uninitialized value $devnum in sprintf at /usr/local/share/perl/5.10.0/Dahdi/Hardware/USB.pm line 100.<br>
/usr/sbin/lsdahdi: warning - OLD DRIVER: missing '/sys/bus/xpds/devices/00:0:0/timing_priority'. Fall back to /proc<br>
### Span 1: DAHDI_DUMMY/1 "DAHDI_DUMMY/1 (source: HRtimer) 1" (MASTER)<br>
### Span 2: XBUS-00/XPD-00 "Xorcom XPD #00/00: BRI_NT" AMI/CCS<br>
1 BRI_NT Clear (In use) (SWEC: MG2)<br>
2 BRI_NT Clear (In use) (SWEC: MG2)<br>
3 BRI_NT Hardware-assisted HDLC (In use)<br>
### Span 3: XBUS-00/XPD-01 "Xorcom XPD #00/01: BRI_TE" AMI/CCS<br>
4 BRI_TE Clear (In use) (SWEC: MG2)<br>
5 BRI_TE Clear (In use) (SWEC: MG2)<br>
6 BRI_TE Hardware-assisted HDLC (In use)<br>
### Span 4: XBUS-00/XPD-02 "Xorcom XPD #00/02: BRI_NT" AMI/CCS<br>
7 BRI_NT Clear (In use) (SWEC: MG2)<br>
8 BRI_NT Clear (In use) (SWEC: MG2)<br>
9 BRI_NT Hardware-assisted HDLC (In use)<br>
### Span 5: XBUS-00/XPD-03 "Xorcom XPD #00/03: BRI_NT" AMI/CCS<br>
10 BRI_NT Clear (In use) (SWEC: MG2)<br>
11 BRI_NT Clear (In use) (SWEC: MG2)<br>
12 BRI_NT Hardware-assisted HDLC (In use)<br>
<br>
And:<br>
<br>
vdv@asterisk:~$ ls /sys/bus/xpds/devices/00:0:0<br>
blink chipregs driver offhook power span subsystem type uevent<br>
<br>
Also, I have always wondered why dahdi sees 4 spans when my astribank<br>
only has 2 BRIs!<br>
<br>
Thanks for your help, I would really like to know at least how safe it<br>
is to comment that rule!<br>
<div><div></div><div class="h5"><br>
Eric<br>
<br>
<br>
--<br>
Eric van der Vlist <<a href="mailto:vdv@dyomedea.com">vdv@dyomedea.com</a>><br>
Dyomedea (<a href="http://dyomedea.com" target="_blank">http://dyomedea.com</a>)<br>
<br><br></div></div></blockquote><div><br>Probably because it could support four BRIs but it is neutered like a Celeron or whatever. <br><br>It is usually cheaper to have one main assembly process, in this case, four spans, but only enable two as the finished product.<br>
<br>Maybe you can trace it out and see if it is in fact a quad span card, do a hardware hack and save a bunch of people money? I bet.<br><br>Thanks,<br>Steve T <br></div></div></div>