| Summary: | DAHLIN-00059: [patch] Support for generic HFC-4S cards | ||
| Reporter: | Tzafrir Cohen (tzafrir) | Labels: | |
| Date Opened: | 2008-11-13 16:17:29.000-0600 | Date Closed: | 2009-07-02 16:33:17 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | wcb4xxp/NewFeature |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) base.c.patch ( 1) base.c.V2.patch ( 2) dahdi_tools.diff ( 3) dahdi-linux-2.1.0.4.diff ( 4) dahdi-tools-2.1.0.2.diff ( 5) hfc4s.diff ( 6) HFC-8S.diff ( 7) patch_b400P ( 8) patch_b400P_2.diff ( 9) wcb4xxp_b4_variety.diff (10) wcb4xxp_extra_cards_dahdi-tools.diff (11) wcb4xxp_extracards_2.diff (12) wcb4xxp_extracards_leds_fixes.diff (13) wcb4xxp_extracards.diff (14) wcb4xxp_v5.diff (15) wcb4xxp.diff (16) wcb4xxp.h.patch | |
| Description: | A patch to add some basic support of other HFC-4S -based PCI cards (such as the ones made by Junghanns). Status: gets rid of the echo canceller messages when not needed, but still needs work. Specifically: * It adds too broad a range of cards (which also include bero.net cards) * The range may include some 2-ports cards, which will probably not work. Not yet tested to work, though it it is at least configured. | ||
| Comments: | By: james.zhu james.zhu (zhulizhong) 2008-11-19 01:53:43.000-0600 hello, i patched the code and test it under openvox B400P/Junghanns, it still does not work. dmesg shows: ---------- dahdi: Telephony Interface Registered on major 196 dahdi: Version: SVN-trunk-r5288M wcb4xxp 0000:02:01.0: probe called for b4xx... ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 21 (level, low) -> IRQ 217 wcb4xxp 0000:02:01.0: Identified HFC-4S PCI (controller rev 1) at 0001a000, IRQ 217 wcb4xxp 0000:02:01.0: NOTE: hardware echo cancellation has been disabled wcb4xxp 0000:02:01.0: Port 1: TE mode wcb4xxp 0000:02:01.0: Port 2: TE mode wcb4xxp 0000:02:01.0: Port 3: TE mode wcb4xxp 0000:02:01.0: Port 4: TE mode wcb4xxp 0000:02:01.0: Did not do the highestorder stuff dahdi: Registered tone zone 0 (United States / North America) wcb4xxp 0000:02:01.0: new card sync source: port 1 ------------------------------ asterisk console can see the dahdi channels, but when i make calls, there is no any response from asterisk. i add a small patch to detect Openvox B400P in te mode: nt = ((gpio & (1 << (i + 4))) != 0); please see the details: ========================================= static void hfc_init_all_st(struct b4xxp *b4) { int i, gpio, nt; struct b4xxp_span *s; gpio = b4xxp_getreg8(b4, R_GPI_IN3); for (i=0; i < 4; i++) { s = &b4->spans[i]; s->parent = b4; s->port = i; nt = ((gpio & (1 << (i + 4))) != 0); /* GPIO=0 = NT mode */ s->te_mode = !nt; dev_info(b4->dev, "Port %d: %s mode\n", i + 1, (nt ? "NT" : "TE")); hfc_reset_st(s); hfc_start_st(s); } } ======================================================== regards! James.zhu By: Jean-Denis Girard (jdg) 2008-11-19 10:53:15.000-0600 Tested the patch with a Junghanns duoBRI card. It does not work. Driver loads and card is recognised, but dahdi_test looks wrong. Nov 19 06:46:42 tiare kernel: dahdi: Telephony Interface Registered on major 196 Nov 19 06:46:42 tiare kernel: dahdi: Version: SVN--r5321M Nov 19 06:46:42 tiare kernel: wcb4xxp 0000:04:01.0: probe called for b4xx... Nov 19 06:46:42 tiare kernel: wcb4xxp 0000:04:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 Nov 19 06:46:42 tiare kernel: wcb4xxp 0000:04:01.0: Identified HFC-4S PCI (controller rev 1) at 0000000000019400, IRQ 19 Nov 19 06:46:42 tiare kernel: wcb4xxp 0000:04:01.0: port 0, B channel 0 [root@tiare ~]# dahdi_cfg -vvvvv DAHDI Tools Version - SVN--r5309 DAHDI Version: SVN--r5321M Echo Canceller(s): Configuration ====================== SPAN 1: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1) SPAN 2: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1) Channel map: Channel 01: Clear channel (Default) (Slaves: 01) Channel 02: Clear channel (Default) (Slaves: 02) Channel 03: Hardware assisted D-channel (Default) (Slaves: 03) Channel 04: Clear channel (Default) (Slaves: 04) Channel 05: Clear channel (Default) (Slaves: 05) Channel 06: Hardware assisted D-channel (Default) (Slaves: 06) 6 channels to configure. Changing signalling on channel 1 from Unused to Clear channel Changing signalling on channel 2 from Unused to Clear channel Changing signalling on channel 3 from Unused to Hardware assisted D-channel Changing signalling on channel 4 from Unused to Clear channel Changing signalling on channel 5 from Unused to Clear channel Changing signalling on channel 6 from Unused to Hardware assisted D-channel [root@tiare ~]# dahdi_test Opened pseudo dahdi interface, measuring accuracy... 49.999% 49.995% 49.998% 49.998% 49.999% 49.999% 49.999% 49.998% 49.999% 49.998% 49.998% 50.000% 49.999% 49.999% 49.999% ^C49.999% 49.999% 49.998% 49.999% ^C --- Results after 19 passes --- Best: 50.000 -- Worst: 49.995 -- Average: 49.998453, Difference: 49.998453 *CLI> pri show span 1 Primary D-channel: 3 Status: Provisioned, Down, Active Switchtype: EuroISDN Type: CPE Window Length: 0/7 Sentrej: 0 SolicitFbit: 0 Retrans: 0 Busy: 0 Overlap Dial: 1 Logical Channel Mapping: 0 T200 Timer: 1000 T203 Timer: 10000 T305 Timer: 30000 T308 Timer: 4000 T309 Timer: -1 T313 Timer: 4000 N200 Counter: 3 Overlap Recv: Yes *CLI> [Nov 19 06:50:56] WARNING[30207]: app_dial.c:1498 dial_exec_full: Unable to create channel of type 'Dahdi' (cause 34 - Circuit/channel congestion) [Nov 19 06:51:13] NOTICE[30179]: chan_dahdi.c:10585 pri_dchannel: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1 [Nov 19 06:51:18] NOTICE[30179]: chan_dahdi.c:10585 pri_dchannel: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1 Also tried to force numspans=2, same result. By: Tzafrir Cohen (tzafrir) 2008-11-19 11:11:27.000-0600 jdb, how does the card show up on lspci -v ? What is the output of lsdahdi (or: 'cat /proc/dahdi/*' ) By: Jean-Denis Girard (jdg) 2008-11-19 11:21:52.000-0600 Ouput of lspci below. It's now working hour here (GMT-10), so I need a functionnal Asterisk, I'm back on bristuff-0.4.0-RC4-xr5. As far as I remember, /proc/dahdi/* looked ok to me. I will be able to do more testing tonight. 04:01.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01) Subsystem: Cologne Chip Designs GmbH HFC-4S [Junghanns DuoDBRI] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at 9400 [size=8] Region 1: Memory at e0005000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 04:01.0 0204: 1397:08b4 (rev 01) Subsystem: 1397:b556 By: james.zhu james.zhu (zhulizhong) 2008-11-19 20:18:30.000-0600 in my environment, few things happened: 1) there is no pri show spans or pri ... under asterisk console? i installed dahdi-linux and dahdi-tools. Version is: SVN-trunk-r5288M 2) the command dahdi show status looks ok. bogon*CLI> dahdi show status Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO B4XXP (PCI) Card 0 Span 1 OK 0 0 0 CCS AMI YEL 399-533 feet (DSX-1) B4XXP (PCI) Card 0 Span 2 RED 0 0 0 CCS AMI YEL 399-533 feet (DSX-1) B4XXP (PCI) Card 0 Span 3 RED 0 0 0 CCS AMI YEL 399-533 feet (DSX-1) B4XXP (PCI) Card 0 Span 4 RED 0 0 0 CCS AMI YEL 399-533 feet (DSX-1) bogon*CLI> the cable is plugged in port 1, if i change to port 2, port 2 shows ok. 3) the result of dahdi_test is same with the result jdg reported. 4) i try to capture the voice using dahdi_monitor, there is no any signal in voice file. By: Tzafrir Cohen (tzafrir) 2008-11-19 20:59:46.000-0600 Please test this with dahdi-linux revision >= 5315, as that revision has fixed an issue with this driver. Is there a timing issue? What do you see on dahdi_test -v ? By: james.zhu james.zhu (zhulizhong) 2008-11-19 21:43:05.000-0600 the version has been updated to: dahdi: Telephony Interface Unloaded dahdi: Telephony Interface Registered on major 196 dahdi: Version: SVN-trunk-r5335M wcb4xxp 0000:02:01.0: probe called for b4xx... ----dahdi_test -v---------- Opened pseudo dahdi interface, measuring accuracy... 8192 samples in 4095.296 system clock sample intervals (49.991%) 8192 samples in 4094.960 system clock sample intervals (49.987%) 8192 samples in 4095.296 system clock sample intervals (49.991%) 8192 samples in 4095.200 system clock sample intervals (49.990%) 8192 samples in 4095.208 system clock sample intervals (49.990%) 8192 samples in 4095.224 system clock sample intervals (49.991%) 8192 samples in 4095.256 system clock sample intervals (49.991%) 8192 samples in 4095.232 system clock sample intervals (49.991%) 8192 samples in 4095.288 system clock sample intervals (49.991%) 8192 samples in 4095.256 system clock sample intervals (49.991%) 8192 samples in 4095.232 system clock sample intervals (49.991%) 8192 samples in 4095.216 system clock sample intervals (49.990%) 8192 samples in 4095.272 system clock sample intervals (49.991%) 8192 samples in 4095.224 system clock sample intervals (49.991%) 8192 samples in 4095.256 system clock sample intervals (49.991%) 8192 samples in 4095.248 system clock sample intervals (49.991%) 8192 samples in 4095.264 system clock sample intervals (49.991%) 8192 samples in 4095.224 system clock sample intervals (49.991%) 8192 samples in 4095.280 system clock sample intervals (49.991%) 8192 samples in 4095.256 system clock sample intervals (49.991%) [1]+ Stopped dahdi_test -v By: Jean-Denis Girard (jdg) 2008-11-22 14:20:30.000-0600 The clock on Junghanns cards seem to be different from B410P. By changing the value of BRG_PCM_CFG, I get normal timing. [jdg@tiare dahdi-linux]$ sudo dahdi_test Opened pseudo dahdi interface, measuring accuracy... 99.999% 99.995% 99.999% 99.999% 99.998% ^C --- Results after 5 passes --- Best: 99.999 -- Worst: 99.995 -- Average: 99.997949, Difference: 99.997951 Then, Asterisk starts but shows notice messages 5-6 times per second: chan_dahdi.c:10395 pri_dchannel: PRI got event: HDLC Abort (6) on Primary D-channel of span 1 Anyway sometimes calls go through, in both direction. Attaching my version of the patch against dahdi-linux 5366. By: james.zhu james.zhu (zhulizhong) 2008-11-24 01:37:46.000-0600 hello: after i changed the BRG_PCM_CFG value, i got this: ================================================== [root@bogon log]# dahdi_test Opened pseudo dahdi interface, measuring accuracy... 99.991% 99.985% 99.990% 99.990% 99.991% 99.989% 99.990% 99.989% 99.990% 99.988% 99.990% 99.988% 99.990% 99.990% 99.990% 99.991% 99.988% 99.989% 99.990% [1]+ Stopped dahdi_test =================================================== but i do not have pri show or bri show command. this is my chan_dahdi.conf file. one more thing, to test HFC card, I installed dahdi-linux and dahdi-tools [channels] ; ; Default language ; ;language=en ; ; Default context ; ; rxgain=5 txgain=6 echocancel=no switchtype = euroisdn ; p2mp TE mode (for connecting ISDN lines in point-to-multipoint mode) signalling = bri_cpe_ptmp ; p2p TE mode (for connecting ISDN lines in point-to-point mode) ;signalling = bri_cpe ; p2mp NT mode (for connecting ISDN phones in point-to-multipoint mode) ;signalling = bri_net_ptmp ; p2p NT mode (for connecting an ISDN pbx in point-to-point mode) ;signalling = bri_net pridialplan = local prilocaldialplan = dynamic nationalprefix = 0 internationalprefix = 00 priindication = passthrough ;echocancel = yes context=demo group = 1 ; S/T port 1 channel => 1-2 group = 2 ; S/T port 2 ====================== i still can not make calls. By: Tzafrir Cohen (tzafrir) 2008-11-24 02:11:26.000-0600 And the errors you're getting are? What do you see on 'pri debug span 1' If nothing: What do you see on 'pri intense debug span 1' ? By: james.zhu james.zhu (zhulizhong) 2008-11-24 02:16:14.000-0600 hello: this is a problem i am thinking, i do not have pri debug span ... and other pri show ..... Do i need to install libpri for HFC cards? this is a error when starting asterisk: =================================== [Nov 24 16:17:10] ERROR[3247]: chan_dahdi.c:13920 process_dahdi: Unknown signalling method 'bri_cpe_ptmp' at line 26. [Nov 24 16:17:10] ERROR[3247]: chan_dahdi.c:13920 process_dahdi: Unknown signalling method 'bri_cpe_ptmp' at line 26. -- Registered channel 1, ISDN PRI signalling -- Registered channel 2, ISDN PRI signalling [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 4: Red Alarm [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 4: Red Alarm -- Registered channel 4, ISDN PRI signalling [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 5: Red Alarm [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 5: Red Alarm -- Registered channel 5, ISDN PRI signalling [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 7: Red Alarm [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 7: Red Alarm -- Registered channel 7, ISDN PRI signalling [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 8: Red Alarm [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 8: Red Alarm -- Registered channel 8, ISDN PRI signalling [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 10: Red Alarm [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 10: Red Alarm -- Registered channel 10, ISDN PRI signalling [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 11: Red Alarm [Nov 24 16:17:10] WARNING[3247]: chan_dahdi.c:4290 handle_alarms: Detected alarm on channel 11: Red Alarm -- Registered channel 11, ISDN PRI signalling =========================== By: Tzafrir Cohen (tzafrir) 2008-11-24 02:21:13.000-0600 Yes. libpri is in fact used for ISDN (both BRI and PRI). You need to install libpri and then rebuild asterisk. What version of asterisk/libpri do you use? By: james.zhu james.zhu (zhulizhong) 2008-11-24 02:29:16.000-0600 hello: asterisk-1.6.0.1 dahdi: Telephony Interface Registered on major 196 dahdi: Version: SVN-trunk-r5335M libpri-1.4.7. i have recompiled few times, but the libpri does not work. By: james.zhu james.zhu (zhulizhong) 2008-11-24 07:44:42.000-0600 i recompiled libpri, asterisk and dahdi, it works now. ============================================== [root@bogon ~]# dahdi_test -v Opened pseudo dahdi interface, measuring accuracy... 8192 samples in 8190.912 system clock sample intervals (99.987%) 8192 samples in 8190.336 system clock sample intervals (99.980%) 8192 samples in 8190.728 system clock sample intervals (99.984%) 8192 samples in 8190.736 system clock sample intervals (99.985%) 8192 samples in 8190.744 system clock sample intervals (99.985%) 8192 samples in 8190.704 system clock sample intervals (99.984%) 8192 samples in 8190.775 system clock sample intervals (99.985%) 8192 samples in 8190.760 system clock sample intervals (99.985%) 8192 samples in 8190.744 system clock sample intervals (99.985%) 8192 samples in 8190.712 system clock sample intervals (99.984%) 8192 samples in 8190.808 system clock sample intervals (99.985%) 8192 samples in 8190.696 system clock sample intervals (99.984%) 8192 samples in 8190.720 system clock sample intervals (99.984%) 8192 samples in 8190.744 system clock sample intervals (99.985%) [1]+ Stopped dahdi_test -v ================================================================= i patched the code: /* * set up the clock controller * we have a 24.576MHz crystal, so the PCM clock is 2x the incoming clock. */ /* b4xxp_setreg8(b4, R_BRG_PCM_CFG, 0x02); */ b4xxp_setreg8(b4, R_BRG_PCM_CFG, V_PCM_CLK); flush_pci(); udelay(100); /* wait a bit for clock to settle */ } ==========will show the samples to 99.99%=============== dahdi: Telephony Interface Registered on major 196 dahdi: Version: SVN-trunk-r5374M wcb4xxp 0000:02:01.0: probe called for b4xx... ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 21 (level, low) -> IRQ 217 wcb4xxp 0000:02:01.0: Identified HFC-4S PCI (controller rev 1) at 0001a000, IRQ 217 wcb4xxp 0000:02:01.0: Port 1: TE mode wcb4xxp 0000:02:01.0: Port 2: TE mode wcb4xxp 0000:02:01.0: Port 3: TE mode wcb4xxp 0000:02:01.0: Port 4: TE mode wcb4xxp 0000:02:01.0: Did not do the highestorder stuff dahdi: Registered tone zone 3 (Netherlands) wcb4xxp 0000:02:01.0: new card sync source: port 1 Bluetooth: HIDP (Human Interface Emulation) ver 1.1 ========================================================= asterisk console: ====================================================== -- Going to extension s|1 because of Complete received -- Accepting call from '82535462' to 's' on channel 0/2, span 1 [Nov 24 21:36:48] WARNING[2851]: chan_dahdi.c:1654 dahdi_enable_ec: Unable to enable echo cancellation on channel 2 (No such device) [Nov 24 21:36:48] WARNING[2851]: chan_dahdi.c:1654 dahdi_enable_ec: Unable to enable echo cancellation on channel 2 (No such device) -- Executing [s@demo:1] Wait("DAHDI/2-1", "1") in new stack -- Executing [s@demo:2] Answer("DAHDI/2-1", "") in new stack -- Executing [s@demo:3] Set("DAHDI/2-1", "TIMEOUT(digit)=5") in new stack -- Digit timeout set to 5 -- Executing [s@demo:4] Set("DAHDI/2-1", "TIMEOUT(response)=10") in new stack -- Response timeout set to 10 -- Executing [s@demo:5] BackGround("DAHDI/2-1", "demo-congrats") in new stack -- <DAHDI/2-1> Playing 'demo-congrats.gsm' (language 'en') -- Channel 0/2, span 1 got hangup request, cause 16 == Spawn extension (demo, s, 5) exited non-zero on 'DAHDI/2-1' -- Hungup 'DAHDI/2-1' ================================================= bogon*CLI> pri show span 1 Primary D-channel: 3 Status: Provisioned, Up, Active Switchtype: EuroISDN Type: CPE Window Length: 0/7 Sentrej: 0 SolicitFbit: 0 Retrans: 0 Busy: 0 Overlap Dial: 0 T200 Timer: 1000 T203 Timer: 10000 T305 Timer: 30000 T308 Timer: 4000 T309 Timer: -1 T313 Timer: 4000 N200 Counter: 3 Overlap Recv: No ====================================== i will take further test for OpenVox B400P. By: james.zhu james.zhu (zhulizhong) 2008-11-24 21:13:45.000-0600 add a patch for OpenVox B200P/B400P/B800P PCI ID ========================================================== --- org_base.c 2008-11-24 21:32:50.000000000 +0800 +++ base.c 2008-11-25 11:05:49.000000000 +0800 @@ -114,11 +114,13 @@ int ports; /* FIXME: Assumed to be 4 */ int has_ec; }; - static struct devtype wcb4xxp = { "Wildcard B410P", .ports = 4, .has_ec = 1 }; -static struct devtype hfc4s = { "HFC-4S PCI", .ports = 4 }; - - +static struct devtype hfc4s = { "HFC-4S Junghanns.NET quadBRI PCI", .ports = 4 }; +static struct devtype hfc2s = { "HFC-4S Junghanns.NET duoBRI PCI", .ports = 2 }; +static struct devtype hfc2s_OpenVox = { "HFC-2S OpenVox B200P", .ports = 2 }; +static struct devtype hfc4s_OpenVox = { "HFC-4S OpenVox B400P", .ports = 4 }; +static struct devtype hfc8s_OpenVox = { "HFC-8S OpenVox B800P", .ports = 8 }; + #if 0 static const char *wcb4xxp_rcsdata = "$RCSfile: base.c,v $ $Revision: 5374 $"; static const char *build_stamp = "" __DATE__ " " __TIME__ ""; @@ -1399,7 +1401,7 @@ gpio = b4xxp_getreg8(b4, R_GPI_IN3); - for (i=0; i < 4; i++) { + for (i=0; i < b4->numspans; i++) { s = &b4->spans[i]; s->parent = b4; s->port = i; @@ -1757,8 +1759,7 @@ * we have a 24.576MHz crystal, so the PCM clock is 2x the incoming clock. */ /* b4xxp_setreg8(b4, R_BRG_PCM_CFG, 0x02); */ - b4xxp_setreg8(b4, R_BRG_PCM_CFG, V_PCM_CLK); - + b4xxp_setreg8(b4, R_BRG_PCM_CFG, V_PCM_CLK); flush_pci(); udelay(100); /* wait a bit for clock to settle */ @@ -2518,7 +2519,8 @@ */ /* TODO: determine whether this is a 2, 4 or 8 port card */ - b4->numspans = 4; + b4->numspans = dt->ports; + vpmsupport = dt->has_ec; b4->syncspan = -1; /* sync span is unknown */ if (b4->numspans > MAX_SPANS_PER_CARD) { dev_err(b4->dev, "Driver does not know how to handle a %d span card!\n", b4->numspans); @@ -2668,7 +2670,11 @@ { 0xd161, 0xb410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (unsigned long)&wcb4xxp }, /* TODO: this is too generic. Replace with specific entries for * specific devices using sub vendor IDs: */ - { 0x1397, 0x08b4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (unsigned long)&hfc4s }, + { 0x1397, 0x08b4, 0x1397, 0xe888, 0, 0, (unsigned long)&hfc4s_OpenVox }, + { 0x1397, 0x08b4, 0x1397, 0xe884, 0, 0, (unsigned long)&hfc2s_OpenVox }, + { 0x1397, 0x08b4, 0x1397, 0xe998, 0, 0, (unsigned long)&hfc8s_OpenVox }, + { 0x1397, 0x08b4, 0x1397, 0xb520, 0, 0, (unsigned long)&hfc4s }, + { 0x1397, 0x08b4, 0x1397, 0xb556, 0, 0, (unsigned long)&hfc2s }, { 0, } }; ========================================================= I will test mote test for B400P+wcb4xxp. there are two problems: 1) the LED of port 4(4 port card)does not turn on, but the calls can go through. 2) the LEDs of ports does not change the status of connection. only red color is there, even call is established or closed. By: james.zhu james.zhu (zhulizhong) 2008-11-25 03:11:51.000-0600 I think the method b4xxp_update_leds() has something wrong when there is OpenVox/Junghanns card. the leds never change the status. ------------------------------------------------------- static void b4xxp_update_leds(struct b4xxp *b4) { int i; struct b4xxp_span *bspan; /* FIXME: abusing has_ec as a marker for leds handling? */ if (!b4->has_ec) return; b4->blinktimer++; for (i=0; i < b4->numspans; i++) { bspan = &b4->spans[i]; ............ } --------------------------------------- for 4 port card, the port 4 shows nothing and inactive. the rest of LEDs are in red. the LEDs never turn to green if call is established. By: james.zhu james.zhu (zhulizhong) 2008-11-27 02:31:45.000-0600 i think the code must be modify to support other HFC bri cards. in ec_write method ===================== static void b4xxp_setleds(struct b4xxp *b4, unsigned char val) { ec_write(b4, 0, 0x1a8 + 3, val); } ====================== i think most of other cards are different from Digium in term of hardware design. they are: 1) hardware based echo cancellation 2) using cpld in digium, but others do not use that. so the extra code should be add to support LEDs of other HFC cards. By: Tzafrir Cohen (tzafrir) 2008-11-27 02:48:54.000-0600 Fine. Please add code to reimplement that function, conditioned on something in struct b4xxp . And PLEASE ATTACH YOUR PATCH AS FILE (use 'upload file'). jdg: sorry for not yet testing your patch. By: james.zhu james.zhu (zhulizhong) 2008-11-27 02:59:26.000-0600 i tested the wcb4xxp.diff. it worked. By: Tzafrir Cohen (tzafrir) 2008-12-04 18:54:01.000-0600 Sorry for the delay. Timing issue has indeed been resolved. However I get poor results trying to connect it to an Astribank BRI I have here (running DAHDI as well). Issues: 1. I get the impression that "TE" and "NT" are mixed. dahdi_scan seems to call my TE spans "NT" and vice versa. 2. I can't get layer 1 working from the NT ports to TE ports on my Astribank. 3. Layer 1 does work well between TE ports on the card and NT ports on my Astribank. However if I disconnect the cable there I get yellow alarm rather than a red alarm. Anyway, while the code is not functional, it seems safe enough to include the extra PCI IDs. Unless someone is concerened about the conflict with mISDN. By: Jean-Denis Girard (jdg) 2008-12-04 21:09:52.000-0600 tzafrir, zhulizhong, Do you get the "HDLC Abort" messages I reported, or am I the only one affected? By: james.zhu james.zhu (zhulizhong) 2008-12-04 21:22:05.000-0600 hello: I do not get the the "HDLC Abort" messages. my problem so far, is status of LEDs. By: Tzafrir Cohen (tzafrir) 2008-12-04 21:56:03.000-0600 Sadly I did not get to test layer 2 yet so no data here. zhulizhong: again, please submit your fixes as attached patches (like the ones of jdg. By: james.zhu james.zhu (zhulizhong) 2008-12-05 00:13:07.000-0600 I do not add any new code. i just add PCI ID for OpenVox. some test results are below: ======= pri show span 1========== [root@bogon wcb4xxp]# asterisk -r Asterisk 1.6.0.1, Copyright (C) 1999 - 2008 Digium, Inc. and others. Created by Mark Spencer <markster@digium.com> Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details. This is free software, with components licensed under the GNU General Public License version 2 and other licenses; you are welcome to redistribute it under certain conditions. Type 'core show license' for details. ========================================================================= -- Remote UNIX connection Connected to Asterisk 1.6.0.1 currently running on bogon (pid = 2879) Verbosity is at least 9 bogon*CLI> bogon*CLI> bogon*CLI> bogon*CLI> pri show span 1 Primary D-channel: 3 Status: Provisioned, Up, Active Switchtype: EuroISDN Type: CPE Window Length: 0/7 Sentrej: 0 SolicitFbit: 0 Retrans: 0 Busy: 0 Overlap Dial: 0 T200 Timer: 1000 T203 Timer: 10000 T305 Timer: 30000 T308 Timer: 4000 T309 Timer: -1 T313 Timer: 4000 N200 Counter: 3 Overlap Recv: No ============dahdi show status===== bogon*CLI> dahdi show status Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO B4XXP (PCI) Card 0 Span 1 OK 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) B4XXP (PCI) Card 0 Span 2 RED 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) B4XXP (PCI) Card 0 Span 3 RED 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) B4XXP (PCI) Card 0 Span 4 RED 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) ================================incoming calls-play demo==== Making new call for cr 4 -- Processing Q.931 Call Setup -- Processing IE 161 (cs0, Sending Complete) -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- Processing IE 30 (cs0, Progress Indicator) -- Processing IE 108 (cs0, Calling Party Number) q931.c:3509 q931_receive: call 4 on channel 2 enters state 6 (Call Present) -- Going to extension s|1 because of Complete received q931.c:2774 q931_call_proceeding: call 4 on channel 2 enters state 9 (Incoming Call Proceeding) > Protocol Discriminator: Q.931 (8) len=7 > Call Ref: len= 1 (reference 4/0x4) (Terminator) > Message type: CALL PROCEEDING (2) > [18 01 8a] > Channel ID (len= 3) [ Ext: 1 IntID: Implicit Other Spare: 0 Exclusive Dchan: 0 > ChanSel: B2 channel ] -- Accepting call from '82535462' to 's' on channel 0/2, span 1 [Dec 5 14:02:06] WARNING[2889]: chan_dahdi.c:1654 dahdi_enable_ec: Unable to enable echo cancellation on channel 2 (No such device) [Dec 5 14:02:06] WARNING[2889]: chan_dahdi.c:1654 dahdi_enable_ec: Unable to enable echo cancellation on channel 2 (No such device) bogon*CLI> -- Executing [s@demo:1] Wait("DAHDI/2-1", "1") in new stack -- Executing [s@demo:1] Wait("DAHDI/2-1", "1") in new stack bogon*CLI> -- Executing [s@demo:2] Answer("DAHDI/2-1", "") in new stack q931.c:2909 q931_connect: call 4 on channel 2 enters state 8 (Connect Request) > Protocol Discriminator: Q.931 (8) len=11 > Call Ref: len= 1 (reference 4/0x4) (Terminator) > Message type: CONNECT (7) > [18 01 8a] > Channel ID (len= 3) [ Ext: 1 IntID: Implicit Other Spare: 0 Exclusive Dchan: 0 > ChanSel: B2 channel ] > [1e 02 81 82] > Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) > Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ] -- Executing [s@demo:2] Answer("DAHDI/2-1", "") in new stack q931.c:2909 q931_connect: call 4 on channel 2 enters state 8 (Connect Request) > Protocol Discriminator: Q.931 (8) len=11 > Call Ref: len= 1 (reference 4/0x4) (Terminator) > Message type: CONNECT (7) > [18 01 8a] > Channel ID (len= 3) [ Ext: 1 IntID: Implicit Other Spare: 0 Exclusive Dchan: 0 > ChanSel: B2 channel ] > [1e 02 81 82] > Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) > Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ] -- Executing [s@demo:3] Set("DAHDI/2-1", "TIMEOUT(digit)=5") in new stack -- Digit timeout set to 5 -- Executing [s@demo:4] Set("DAHDI/2-1", "TIMEOUT(response)=10") in new stack -- Response timeout set to 10 -- Executing [s@demo:5] BackGround("DAHDI/2-1", "demo-congrats") in new stack -- <DAHDI/2-1> Playing 'demo-congrats.gsm' (language 'en') -- Executing [s@demo:3] Set("DAHDI/2-1", "TIMEOUT(digit)=5") in new stack -- Digit timeout set to 5 -- Executing [s@demo:4] Set("DAHDI/2-1", "TIMEOUT(response)=10") in new stack -- Response timeout set to 10 -- Executing [s@demo:5] BackGround("DAHDI/2-1", "demo-congrats") in new stack -- <DAHDI/2-1> Playing 'demo-congrats.gsm' (language 'en') bogon*CLI> < Protocol Discriminator: Q.931 (8) len=4 < Call Ref: len= 1 (reference 4/0x4) (Originator) < Message type: CONNECT ACKNOWLEDGE (15) q931.c:3669 q931_receive: call 4 on channel 2 enters state 10 (Active) < Protocol Discriminator: Q.931 (8) len=4 < Call Ref: len= 1 (reference 4/0x4) (Originator) < Message type: CONNECT ACKNOWLEDGE (15) q931.c:3669 q931_receive: call 4 on channel 2 enters state 10 (Active) < Protocol Discriminator: Q.931 (8) len=17 bogon*CLI> < Protocol Discriminator: Q.931 (8) len=17 < Call Ref: len= 1 (reference 4/0x4) (Originator) < Call Ref: len= 1 (reference 4/0x4) (Originator) bogon*CLI> < Message type: DISCONNECT (69) < Message type: DISCONNECT (69) bogon*CLI> < [08 07 82 90 00 00 00 00 78] < [08 07 82 90 00 00 00 00 78] bogon*CLI> < Cause (len= 9) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Public network serving the local user (2) < Cause (len= 9) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Public network serving the local user (2) bogon*CLI> < Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] < Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] bogon*CLI> < Cause data 1: 00 (0) < Cause data 1: 00 (0) bogon*CLI> < Cause data 2: 00 (0) < Cause data 2: 00 (0) bogon*CLI> < Cause data 3: 00 (0) < Cause data 3: 00 (0) bogon*CLI> < Cause data 4: 00 (0) < Cause data 4: 00 (0) bogon*CLI> < Cause data 5: 78 (120) < Cause data 5: 78 (120) bogon*CLI> < [1e 02 82 88] < [1e 02 82 88] bogon*CLI> < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the local user (2) < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the local user (2) bogon*CLI> < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] bogon*CLI> -- Processing IE 8 (cs0, Cause) -- Processing IE 8 (cs0, Cause) bogon*CLI> -- Processing IE 30 (cs0, Progress Indicator) -- Processing IE 30 (cs0, Progress Indicator) bogon*CLI> q931.c:3784 q931_receive: call 4 on channel 2 enters state 12 (Disconnect Indication) q931.c:3784 q931_receive: call 4 on channel 2 enters state 12 (Disconnect Indication) -- Channel 0/2, span 1 got hangup request, cause 16 bogon*CLI> -- Channel 0/2, span 1 got hangup request, cause 16 == Spawn extension (demo, s, 5) exited non-zero on 'DAHDI/2-1' bogon*CLI> == Spawn extension (demo, s, 5) exited non-zero on 'DAHDI/2-1' NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request q931.c:2925 q931_release: call 4 on channel 2 enters state 19 (Release Request) > Protocol Discriminator: Q.931 (8) len=8 > Call Ref: len= 1 (reference 4/0x4) (Terminator) > Message type: RELEASE (77) > [08 02 81 90] > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) > Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] -- Hungup 'DAHDI/2-1' NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request q931.c:2925 q931_release: call 4 on channel 2 enters state 19 (Release Request) > Protocol Discriminator: Q.931 (8) len=8 > Call Ref: len= 1 (reference 4/0x4) (Terminator) > Message type: RELEASE (77) > [08 02 81 90] > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) > Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] -- Hungup 'DAHDI/2-1' bogon*CLI> < Protocol Discriminator: Q.931 (8) len=4 < Protocol Discriminator: Q.931 (8) len=4 bogon*CLI> < Call Ref: len= 1 (reference 4/0x4) (Originator) < Call Ref: len= 1 (reference 4/0x4) (Originator) bogon*CLI> < Message type: RELEASE COMPLETE (90) < Message type: RELEASE COMPLETE (90) q931.c:3724 q931_receive: call 4 on channel 2 enters state 0 (Null) bogon*CLI> q931.c:3724 q931_receive: call 4 on channel 2 enters state 0 (Null) NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null bogon*CLI> NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null ============================================= [root@bogon wcb4xxp]# dahdi_scan [1] active=yes alarms=OK description=B4XXP (PCI) Card 0 Span 1 name=B4/0/1 manufacturer=Digium devicetype=HFC-4S OpenVox B400P location=PCI Bus 02 Slot 03 basechan=1 totchans=3 irq=217 type=digital-TE syncsrc=0 lbo=0 db (CSU)/0-133 feet (DSX-1) coding_opts=B8ZS,AMI,HDB3 framing_opts=ESF,D4,CCS,CRC4 coding=AMI framing=CCS [2] active=yes alarms=RED description=B4XXP (PCI) Card 0 Span 2 name=B4/0/2 manufacturer=Digium devicetype=HFC-4S OpenVox B400P location=PCI Bus 02 Slot 03 basechan=4 totchans=3 irq=217 type=digital-TE syncsrc=0 lbo=0 db (CSU)/0-133 feet (DSX-1) coding_opts=B8ZS,AMI,HDB3 framing_opts=ESF,D4,CCS,CRC4 coding=AMI framing=CCS [3] active=yes alarms=RED description=B4XXP (PCI) Card 0 Span 3 name=B4/0/3 manufacturer=Digium devicetype=HFC-4S OpenVox B400P location=PCI Bus 02 Slot 03 basechan=7 totchans=3 irq=217 type=digital-TE syncsrc=0 lbo=0 db (CSU)/0-133 feet (DSX-1) coding_opts=B8ZS,AMI,HDB3 framing_opts=ESF,D4,CCS,CRC4 coding=AMI framing=CCS [4] active=yes alarms=RED description=B4XXP (PCI) Card 0 Span 4 name=B4/0/4 manufacturer=Digium devicetype=HFC-4S OpenVox B400P location=PCI Bus 02 Slot 03 basechan=10 totchans=3 irq=217 type=digital-TE syncsrc=0 lbo=0 db (CSU)/0-133 feet (DSX-1) coding_opts=B8ZS,AMI,HDB3 framing_opts=ESF,D4,CCS,CRC4 coding=AMI framing=CCS ============================================== By: Jean-Denis Girard (jdg) 2008-12-05 09:56:34.000-0600 ok, thanks for replies. I'll check again my setup, and see if HDLC errors disappear. By: Jean-Denis Girard (jdg) 2008-12-14 15:05:58.000-0600 Well, I recompiled everything with latest dahdi-tools, dahdi-linux, libpri, and asterisk-1.6.0.2, and I get exactly the same HDLC errors. As I said before, I can make / receive calls, but there is a 'clicking' sound that seems related to HDLC errors. I'd be really happy to have Dahdi working with these generic cards, si I'm willing to do more tests or give access to my setup if anybody wants to have a look. By: Olivier Krief (okrief) 2008-12-16 14:20:58.000-0600 As it might take a long time to address full range of HFC-4S cards and a large feature set, maybe we could momentarily select one board (the most widely sold ?) and a short feature set and focus efforts on it ? Having a given card running should motivate people to provide testing or extend features. By: Tim King (timking) 2009-01-05 05:07:57.000-0600 I have both Junghanns and OpenVox cards here in the UK. Testing using asterisk-1.6.0.3-rc1 and dahdi 2.1.0.3. Testing this patch first on OpenVox B200p. I needed to alter the NT /TE test as described above (nt = ((gpio & (1 << (i + 4))) != 0)) to get TE mode detected; I assume that this is the other way round for Digium cards? I can make and receive calls fine, except that I get D Channel Up and down messages on a regular basis. pri debug is Sending Unnumbered Acknowledgement q921.c:798 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED == Primary D-Channel on span 1 down [Jan 5 11:06:34] WARNING[17400]: chan_dahdi.c:2997 pri_find_dchan: No D-channels available! Using Primary channel 3 as D-channel anyway! Sending Set Asynchronous Balanced Mode Extended q921.c:211 q921_send_sabme: q921_state now is Q921_AWAITING_ESTABLISH -- Got UA from network peer Link up. q921.c:798 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED q921.c:749 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED == Primary D-Channel on span 1 up -- Got Disconnect from peer. Sending Unnumbered Acknowledgement q921.c:798 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED == Primary D-Channel on span 1 down [Jan 5 11:07:25] WARNING[17400]: chan_dahdi.c:2997 pri_find_dchan: No D-channels available! Using Primary channel 3 as D-channel anyway! Sending Set Asynchronous Balanced Mode Extended q921.c:211 q921_send_sabme: q921_state now is Q921_AWAITING_ESTABLISH -- Got UA from network peer Link up. q921.c:798 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED q921.c:749 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED == Primary D-Channel on span 1 up (Later) I can make this error go away by running dahdi_cfg again while asterisk is running. Any suggestions? Also the sample system.conf file says "BRI TE ports should be configured as a slave" which can't be right can it? You might want to ignore timing in NT mode. Someone's confused about NT vs TE here I think. Just to get my understanding right TE mode is what is wanted when you plug Asterisk into an ISDN socket on the wall, right? By: Olivier Krief (okrief) 2009-01-05 12:03:40.000-0600 In Digium B410P manual (page 12), a drawing shows you're right : TE mode is needed to plug into an ISDN socket. PS: Have you tried with a Junghanns board ? PS2: Do you think it would more effective to have this bug report focused on a single type of HFC card to encourage more people to test the provided patch and have it included in next official asterisk version ? By: Tim King (timking) 2009-01-05 12:17:37.000-0600 I think it should be all Junghanns and OpenVox cards, because they are all supported by the bristuff driver called "qozap". The only difference is in the way the LEDs are set, and that varies from board to board - even from the same manufacturer. I can probably crib the code from qozap to put in here, although it would clearly be better if someone from Junghanns did it. I think this is important as us Europeans can finally ditch bristuff and all the bugs it brought with it. I will try a Junghanns card next but it's in an active server rather than my test one I'm using. It may have to wait for a weekend. Any ideas why reconfiguring the driver makes these errors go away? By: james.zhu james.zhu (zhulizhong) 2009-01-05 19:38:17.000-0600 hello: i have tried Junhangs cards and openvox cards. those cards work in the same way including LEDs and configuration. the LEDs of control of those cards are different from digium. some chip addresses are different. in my testing, the call is ok(I have posted the debug message as above). I will do further test for the driver. zhu By: Tim King (timking) 2009-01-06 10:18:25.000-0600 I have applied the patch described in bug 0014031 which stops chan_dahdi moaning when a BRI point to multi-point line changes briefly every minute or so. This then seems to work well. zhu - I suspect you have been testing point to point BRI lines? These two bugs need to be linked. By: james.zhu james.zhu (zhulizhong) 2009-01-06 19:30:18.000-0600 i used signalling = bri_cpe_ptmp. By: Olivier Krief (okrief) 2009-02-06 14:34:43.000-0600 Any update on this one ? could it make it into trunk ? By: odicha (odicha) 2009-02-22 21:21:02.000-0600 Please discard base.c.patch file. Use V2 instead. It's bassed on 2.1.0.4. Adds led control & detection for some boards. Untested in 4,8 ports cards. (if somebody gives me one...) Tested succefully on B200P (2 ports from OpenVox) in bri_cpe mode Needs "code cleaning"... but it provides led support. If it works on 4 & 8 we could clean it and add it to trunk P.D. Sorry for my bad english By: james.zhu james.zhu (zhulizhong) 2009-02-23 23:48:47.000-0600 hello, I tested OpenVox B200P and B400P. B200P is working with the patch; B400P does not work. I plug the cable into Port 1, but Port 3 turns into green. only the port 2 is correctly set. =================================================== if (b4->numspans == 4) { leds = ((led[3] > 0) << 0) | ((led[1] > 0) << 1) | ((led[0] > 0) << 2) | ((led[2] > 0) << 3) | ((led[3] & 1) << 4) | ((led[1] & 1) << 5) | ((led[0] & 1) << 6) | ((led[2] & 1) << 7); printk("testing: leds %d\n", leds); // leds are 71 b4xxp_setreg8(b4, R_GPIO_EN1, leds & 0x0f); b4xxp_setreg8(b4, R_GPIO_OUT1, leds >> 4); } ===================================================== regards! James.zhu By: james.zhu james.zhu (zhulizhong) 2009-02-24 00:45:49.000-0600 hello, all: after dig the code in base.c, if i changed to leds in this way: ======================================================================= if (b4->numspans == 4) { leds = ((led[0] > 0) << 0) | ((led[1] > 0) << 1) | ((led[2] > 0) << 2) | ((led[3] > 0) << 3) | ((led[0] & 1) << 4) | ((led[1] & 1) << 5) | ((led[2] & 1) << 6) | ((led[3] & 1) << 7); b4xxp_setreg8(b4, R_GPIO_EN1, leds & 0x0f); b4xxp_setreg8(b4, R_GPIO_OUT1, leds >> 4); } ========================================================================== openvox B400P does work. regards! James.zhu By: james.zhu james.zhu (zhulizhong) 2009-02-24 01:06:40.000-0600 hello, I have added the patch to support B400P, I tested it under TE mode with OpenVox B400P. it works.I think Junghanns's card should work. the dahdi-linux version is 2.1.0.4. regards! James.zhu By: odicha (odicha) 2009-02-24 12:10:07.000-0600 Hi! Possibly that mod will break generic HFC4s support. --For future adding into trunk What do you think if we rewrite driver code for suporting cards in product ID basis. So instead of looking at numspans we could add a pointer to card model. We could make led instructions for any compatible card, for example. If you think it´s a good point of view, I can try to modify driver. I wait for an answer. By: Tzafrir Cohen (tzafrir) 2009-02-24 12:27:43.000-0600 Odicha: look at the patch. It already does. By: Tzafrir Cohen (tzafrir) 2009-02-24 13:02:17.000-0600 zhulizhong, I'm reformatting the patch a bit. Generally looks good. One small thing: In b4xxp_update_leds_HFC() (I preffered renaming it b4xxp_update_leds_hfc() to comply with naming conventions) you have a number of wrongly-indented if-s: + if (bspan->span.alarms) { + if (b4->blinktimer == (led_fader_table[b4->alarmpos] >> 1)) + led[i] = 2; + lled |= 0 << i; "lled |= 0 << i;" will be run regardless of the condition. And this goes on: + if (b4->blinktimer == 0xf) + led[i] = 0; + lled |= 1 << i; + } else if (bspan->span.mainttimer || bspan->span.maintstat) { + if (b4->blinktimer == (led_fader_table[b4->alarmpos] >> 1)) + led[i] = 1; + lled |= 0 << i; + if (b4->blinktimer == 0xf) + led[i] = 0; + lled |= 1 << i; But unlike: + } else { + /* No Alarm */ + led[i] = 1; + lled |= 0 << i; + } Considering i is not necessarily a single bit, I'm not sure exactly what this code does. By: Tzafrir Cohen (tzafrir) 2009-02-24 13:28:19.000-0600 zhulizhong, uploaded a reformatted patch (patch_b400P_2.diff). Please look at the places in it marked with FIXME . By: odicha (odicha) 2009-02-24 17:54:19.000-0600 tzafrir, Ok. I know. what I mean is recode b4->has_ec & b4xxp_update_leds_hfc in a "more clean" way. We could build a section for each unique card, instead a general 2 ports//4 ports//8 ports led signalling. In that way we could have a function for each brand & model. /* FIXME: should lled be set unconditionally below? */ Yes, I know. It's dirty. All function is a "dirty" port from qozap. It's written only for testing purposes. I think I might rewrite function, but I'd like rewrite it only once... so I'd like to know what we want about it. I can test only b200p cards, so I have no idea if the rest of function will work I think it could written on b4->devtype. So we manage led signalling in a per card basis... & we don´t have -lled- "living la vida loca" if card is not a b800p. BTW Sorry again for my poor english... By: Tzafrir Cohen (tzafrir) 2009-02-24 18:06:26.000-0600 OK. The LEDs parts seems to me a bit trickier than the rest. So I suggest that we'd first commit it without the LEDs changes, and see how to write it properly then. By: odicha (odicha) 2009-02-24 18:09:32.000-0600 Sorry. Respect lled It might be something like this (in the dirty way...) if (bspan->span.flags & DAHDI_FLAG_RUNNING) { + if (bspan->span.alarms) { + if (b4->blinktimer == (led_fader_table[b4->alarmpos] >> 1)) + { + led[i] = 2; + lled |= 0 << i; + } + if (b4->blinktimer == 0xf) + { + led[i] = 0; + lled |= 1 << i; + } + } else if (bspan->span.mainttimer || bspan->span.maintstat) { + if (b4->blinktimer == (led_fader_table[b4->alarmpos] >> 1)) + { + led[i] = 1; + lled |= 0 << i; + } + if (b4->blinktimer == 0xf) + { + led[i] = 0; + lled |= 1 << i; } + } else { + /* No Alarm */ + led[i] = 1; + lled |= 0 << i; + } + } + else + { + led[i] = 0; + lled |= 1 << i; + } + } I added lled for testing b800p and forgot { }... Murphy's laws By: Tzafrir Cohen (tzafrir) 2009-02-24 18:19:02.000-0600 Hmm... could you try to explain that in words or some pseudo code? Why is the code trying to do that? By: odicha (odicha) 2009-02-24 18:27:21.000-0600 Ok. It's all a dirty test. First I tried to get led status so I get 0,1,2 status for each span. Second I took a look to b800p. Only one color (0,1) so i used lled, but I wrote bad... { } forgotten... I write values for 200-400 led[i] & 800 lled then I use what I need. I know... dirty way. That's the reason I'd like to write it again. In a function per devtype perhaps? Something like hfc2s_update_leds ... hfc4s_b4xxp_update_leds and so. 1 main funtion that call for example b200p_update_leds. We can set one funtion for each different signalling mode in a per card basis. What do you think about it? By: james.zhu james.zhu (zhulizhong) 2009-02-24 21:32:32.000-0600 hello, i put Openvox B800P to test that, dahdi_cfg -vvvvvvv report error: ============================================================================ Running dahdi_cfg: DAHDI_SPANCONFIG failed on span 1: Invalid argument (22) ============================================================================ if i use two B400Ps instead of one B800P, it works. this is my system.conf ----------------------------------------------------------------------- # Autogenerated by ./dahdi_genconf on Mon Nov 24 20:13:58 2008 -- do not hand edit # Dahdi Configuration File # # This file is parsed by the Dahdi Configurator, dahdi_cfg # # Global data loadzone=nl defaultzone=nl # qozap span definitions # most of the values should be bogus because we are not really zaptel span=1,1,0,ccs,ami span=2,2,0,ccs,ami span=3,3,0,ccs,ami span=4,4,0,ccs,ami span=5,5,0,ccs,ami span=6,6,0,ccs,ami span=7,7,0,ccs,ami span=8,8,0,ccs,ami bchan=1,2 hardhdlc=3 bchan=4,5 hardhdlc=6 bchan=7,8 hardhdlc=9 bchan=10,11 hardhdlc=12 bchan=13,14 hardhdlc=15 bchan=16,17 hardhdlc=18 bchan=19,20 hardhdlc=21 bchan=22,23 hardhdlc=24 =================================== one more thing, regarding the leds of B400P, if no ISDN cable plug in, the port 1 and 3 keep blinking and port 2 and 4 are in red with no blinking. if plug in the cable, the led turns into green. By: Tzafrir Cohen (tzafrir) 2009-02-25 01:48:17.000-0600 I love it when you hand edit a file and yet leave the comment not to hand-edit it :-) What do you see in /proc/dahdi/1 ? Is it dahdi_dummy by any chance? If not, chances are that the error comes from the spanconfig() function of the module. Add some debug prints to see if the code gets there. By: james.zhu james.zhu (zhulizhong) 2009-02-25 02:55:41.000-0600 test B800P, got this: ======================================================================== [root@bogon ~]# service dahdi start Loading DAHDI hardware modules: wcb4xxp: [ OK ] No hardware timing source found in /proc/dahdi, loading dahdi_dummy Running dahdi_cfg: DAHDI_SPANCONFIG failed on span 1: Invalid argument (22) [FAILED] [root@bogon ~]# ======================================================================= there is no channel under /proc/dahdi, so report the error. By: Tzafrir Cohen (tzafrir) 2009-02-25 03:04:59.000-0600 Looks like the module has failed to load. What's the output of: dahdi_hardware lsdahdi By: james.zhu james.zhu (zhulizhong) 2009-02-25 03:34:54.000-0600 we have to move out the qozap for that. i think it is conflict with B400/B800. [root@bogon ~]# dahdi_hardware pci:0000:02:01.0 qozap- 1397:16b8 Junghanns OctoBRI ISDN card [root@bogon ~]# lsdahdi ### Span 1: DAHDI_DUMMY/1 "DAHDI_DUMMY/1 (source: RTC) 1" (MASTER) [root@bogon ~]# By: odicha (odicha) 2009-02-25 04:29:13.000-0600 It´s posibble for b800p not working at all. First of all, b800p have a lot of diffrences with rest of Bxx.... One thing: recompiling and reboot. For me, I can´t reload DAHDI if it's loading more than one card. I've to reboot for it working. Put your logs for looking at it, please By: Tim King (timking) 2009-02-25 05:27:11.000-0600 I am pretty sure the B800 is never going to work. Did it work with qozap? Surely the 4 in HFC-4S refers to the number of ports on the chip? By: odicha (odicha) 2009-02-25 06:02:41.000-0600 I don't know at all. I'm going to rem all b8xx testing code then By: odicha (odicha) 2009-02-25 10:07:19.000-0600 Hi all! Firsts steps in a "per variety" coding. file-> wcb4xxp_b4_variety.diff zhulizhong: A patch for dahdi_tools, if you get nervous reading Junghanns & qozap... It's only for info. It doesn't matter about driver behavior. Please send some logs about B800P. (or send me one... :) ****EDIT HFC DuoBri & quadBRI sections directly copied from OpenVox ones. Obviusly they need testing. By: james.zhu james.zhu (zhulizhong) 2009-02-25 19:36:41.000-0600 Openvox B800P can work with patched Bristuff and mISDN perfectly. for dahdi, i think the code have to be changed. I will check for B800P. By: james.zhu james.zhu (zhulizhong) 2009-02-25 20:22:33.000-0600 I chage to 1397:08b4 to 1397:168b for B800P, it is not 08b4 base. ============================================================================== # Cologne Chips: # (Still a partial list) '1397:08b4/b556' => { DRIVER => 'qozap', DESCRIPTION => 'Junghanns DuoBRI ISDN card' }, '1397:08b4' => { DRIVER => 'qozap', DESCRIPTION => 'Junghanns QuadBRI ISDN card' }, '1397:08b4/1397:b556' => { DRIVER => 'wcb4xxp', DESCRIPTION => 'Junghanns DuoBRI ISDN card' }, '1397:08b4/1397:b520' => { DRIVER => 'wcb4xxp', DESCRIPTION => 'Junghanns QuadBRI ISDN card' }, '1397:08b4/1397:e884' => { DRIVER => 'wcb4xxp', DESCRIPTION => 'OpenVox B200P' }, '1397:08b4/1397:e888' => { DRIVER => 'wcb4xxp', DESCRIPTION => 'OpenVox B400P' }, + '1397:168b/1397:e998' => { DRIVER => 'wcb4xxp', DESCRIPTION => 'OpenVox B800P' }, '1397:08b4' => { DRIVER => 'qozap', DESCRIPTION => 'Generic Cologne ISDN card' }, '1397:16b8' => { DRIVER => 'qozap', DESCRIPTION => 'Junghanns OctoBRI ISDN card' }, '1397:30b1' => { DRIVER => 'cwain', DESCRIPTION => 'HFC-E1 ISDN E1 card' }, '1397:2bd0' => { DRIVER => 'zaphfc', DESCRIPTION => 'HFC-S ISDN BRI card' }, ============================================================== it still has the error same as i posted, the code have to recode for B800P. By: odicha (odicha) 2009-02-26 04:10:44.000-0600 I've changed dahdi-tools for cards that we have working. Nor b800p working yet -> nor line in dahdi_cfg.c We can add it when it's working By: odicha (odicha) 2009-02-26 04:12:56.000-0600 tzafrir: what do you think about last code? What may I change/tune for include in future dahdi releases? By: Tzafrir Cohen (tzafrir) 2009-02-27 14:18:11.000-0600 Grrr... I don't like the "string comparison". It may just work in just about any case. Until the string will get from somewhere (built dynamically) and then the comparison will mysteriously fail. Please replace it with an enum. By: odicha (odicha) 2009-02-27 16:36:16.000-0600 Ok. Perfect. Enum then. Something else?? Say with me 1,2,3 I won't get angry 4,5,6 All you will see. (jeje) Have a nice weekend By: odicha (odicha) 2009-03-03 16:03:48.000-0600 Hi. New diff file. Take a look at enum id_cards card_type. This way ok? By: odicha (odicha) 2009-03-06 21:01:38.000-0600 Hi Tzafrir! 2,4 & 8 ports cards working. HFC-4S & HFC-8S. (I tested them in TE mode) Looking for testers. Take a look at it for start cleaning code. Regards By: Olivier Krief (okrief) 2009-03-09 09:36:13 What would be the most productive way (ie that could help to test and identify issues) to try this ? As I'm reading here "Openvox B800P can work with patched Bristuff and mISDN perfectly.", shall I understand I can choose "whatever asterisk version is compliant to 2.1.0.4 Dahdi Linux" ? Then, which patches exactly are to be applied ? I'm planning to use a Junghanns QuadBRI. By: Tzafrir Cohen (tzafrir) 2009-03-09 09:45:27 Please test the patches with Asterisk >= 1.6.0, libpri >= 1.4.4 (but please use 1.4.9 for meaningful results) and dahdi (please use -linux 2.1.0.4 or SVN trunk) By: Olivier Krief (okrief) 2009-03-09 10:03:22 I've installed asterisk 1.6.0.6, libpri 1.4.9, dahdi-linux 2.1.0.4, dahdi-tools 2.1.0.2. Then which are the minimum patches to apply ? wcb4xxp_v5.diff and dahdi_tools.diff alone ? By: odicha (odicha) 2009-03-09 10:57:11 okrief: HFC-8S.diff works with HFC-4S & HFC-8S. dahdi-tools diff is only for displaying dahdi_hardware info. It doesn't add any functionality. By: odicha (odicha) 2009-03-09 11:21:19 Hi Tzafrir! I wait for HFC-8S.diff eval. If you could take a look at it, please... By: Olivier Krief (okrief) 2009-03-09 15:39:15 ochida: Thanks for explaining diff between hfc4s and hfc8s files. 1. Could we say hfc4s.diff is not needed anymore (ie hfc8s.diff is enough for 2, 4 and 8 ports boards) ? 2. Beside hfc8s.diff (and dahdi-tools.diff) which patches would you advise me to apply ? By: odicha (odicha) 2009-03-09 16:15:45 Okrief: Tzafrir explained it to you perfectly. Use that versions. If you can wait till tomorrow I´m working on leds now. I'll upload new patch later, including some improvements. At now, you can test hfc8s.diff & dahdi-tools.diff. If your card is not detected please report your card model, brand & hardware id. Thanks in advance By: Olivier Krief (okrief) 2009-03-09 16:48:42 Yes, Tzafir perfectly mentioned which software versions (asterisk, dahdi, ...) I should use but I was still wondering which among those 11 files (hfc4s.diff, wcb4xxp.diff, ... hfc8s.diff) enclosed with this bug, had to be downloaded and applied to source code. (If that makes sense and to encourage other to join in and test, it would be great if files which are needed anymore, could be droped or stored elsewhere.) Hopefully, I'll try your patch tomorrow. By: odicha (odicha) 2009-03-09 16:59:22 Okrief: Ok. As you can see there's a long time making tests & changes. If you want you can make a test using only hfc8s.diff. Your card (quadBRI) might works (perhaps some crazy leds...) By: odicha (odicha) 2009-03-09 20:25:33 Hi! New diff files. dahdi-linux-2.1.0.4.diff & dahdi-tools-2.1.0.2.diff Support for standard HFC-4S & HFC-8S cards. Leds tested on OpenVox cards. For Junghanns and Beronet untested. Error in EC activation fixed (B410P always started EC in previous patches overriding vpmsupport parameter) I think it's time to make all tests. Tzafrir: Please, take a look and tell me. I think there are no many more changes to do. Thanks in advance. By: Tzafrir Cohen (tzafrir) 2009-03-10 00:54:13 Odicha, thanks! Have you tested this on Bero.net cards as well? All the bit manipulation can be done using bit operations macros in newer kernels. See drivers/dahdi/xpp/xdefs.h for compatibility definitions of this for older kernels. By: odicha (odicha) 2009-03-10 05:12:56 Hi, Tzafrir! No. I added BeroNet cards ids for testing purposes. They might work anyway. Fine. But I'm mainly a "windoze" admin. My skills using c++ == -1. I'll take a look at it, trying to understand the way it works. By the way, I'm looking for testers, because really It's only tested on OpenVox cards (the ones I own). Regards & thank you very much for the bit manipulation info. By: andrea lanza (lanzaandrea) 2009-03-11 08:27:09 I see you are looking for testers. I am trying to use dahdi instead of my years-running mISDN. My box include 2 single span HFC cards, in TE mode (p2mp TE mode ) dahdi_hardware recognizes them as: pci:0000:00:09.0 zaphfc- 1397:2bd0 HFC-S ISDN BRI card pci:0000:00:0a.0 zaphfc- 1397:2bd0 HFC-S ISDN BRI card but dahdi_genconf does not produce any valuable configuration. If I try to write by myself a "reasonable" system.conf: loadzone = it defaultzone = it span=1,1,0,ccs,ami span=2,2,0,ccs,ami bchan=1,2 hardhdlc=3 bchan=4,5 hardhdlc=6 using svn trunk ( 6111) and giving : modprobe wcb4xxp -vvv dahdi_cfg -vvv I get: DAHDI Tools Version - SVN-trunk-r6110 DAHDI Version: SVN-trunk-r6096 Echo Canceller(s): Configuration ====================== SPAN 1: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1) SPAN 2: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1) Channel map: Channel 01: Clear channel (Default) (Slaves: 01) Channel 02: Clear channel (Default) (Slaves: 02) Channel 03: Hardware assisted D-channel (Default) (Slaves: 03) Channel 04: Clear channel (Default) (Slaves: 04) Channel 05: Clear channel (Default) (Slaves: 05) Channel 06: Hardware assisted D-channel (Default) (Slaves: 06) 6 channels to configure. DAHDI_SPANCONFIG failed on span 1: No such device or address (6) The question is: should in principle my configuration be acceptable and further testing is required/appreciated, or should I revert to mISDN ? I also own a Beronet card, a duan span BN2S0 card: is better to test also with that card ? asterisk:1.4.23.2 (1.6 strictly needed ?) libpri-1.4.9 dahdi-tools-2.1.0.2 or svn 6111 dahdi-linux-2.1.0.4 or svn 6111 openSUSE 11.1 2.6.27.19-3.2-pae I also tested dahdi-tools-2.1.0.2 and dahdi-linux-2.1.0.4 with the here provided patches dated 9-3-2009 with no difference By: odicha (odicha) 2009-03-11 13:30:27 lanzaandrea: Hi! The patch is intended for other cards. You seem to have a HFC-S card (1 port). It's for 2,4 & 8 ports models (HFC-4S & HFC-8S). You can test with BeroNet BN2S0 (HFC-4S chip), but you might test it on Asterisk 1.6.1 svn trunk because chan_dahdi in 1.4 trunk doesn't have bri signalling When you recompile it, please follow this order. libpri -> dahdi-linux -> dahdi-tools -> asterisk then if you make dahdi_genconf and dahdi_cfg -vv you might have basic support. This creates /etc/dahdi/modules , /etc/dahdi/system.conf & /etc/asterisk/dahdi-channels.conf You might manually edit /etc/dahdi/system.conf and change dchan channels to hardhdlc # Autogenerated by /usr/sbin/dahdi_genconf on Sat Mar 7 02:33:15 2009 -- do not hand edit # Dahdi Configuration File # # This file is parsed by the Dahdi Configurator, dahdi_cfg # # Span 1: B4/0/1 "B4XXP (PCI) Card 0 Span 1" (MASTER) AMI/CCS span=1,1,0,ccs,ami # termtype: te bchan=1-2 hardhdlc=3 echocanceller=mg2,1-2 # Span 2: B4/0/2 "B4XXP (PCI) Card 0 Span 2" AMI/CCS RED span=2,2,0,ccs,ami # termtype: te bchan=4-5 hardhdlc=6 echocanceller=mg2,4-5 It might look like this. asterisk*CLI> pri show spans PRI span 1/0: Provisioned, Up, Active PRI span 2/0: Provisioned, In Alarm, Down, Active Please report results. Thanks in advance By: james.zhu james.zhu (zhulizhong) 2009-03-11 21:20:30 hello, I tested the patch for Openvox cards with TE mode in last week: ------------------------------ B800P works fine. B400P works fine. B200P works fine. ------------------------------ my environment: ------------------------------ dahdi: Telephony Interface Registered on major 196 dahdi: Version: SVN-trunk-r6096M dahdi_tool- svn Asterisk 1.6.0.6 (tar.gz) libpri-1.4.9 Centos-5.0 ------------------------------- I do not test NT mode yet. later i will do that. one more thing, i open the =============test================== #ifdef DEBUG_LOWLEVEL_REGS if (unlikely(DBG_REGS)) drv_dbg(b4->dev, "read 0x%02x from 0x%p\n", ret, b4->addr + reg); #endif if (unlikely(pedanticpci)) { udelay(3); } =================================== it gives me a compilation error for drv_dbg, where define that? i could not find that. By: odicha (odicha) 2009-03-12 03:50:20 zhulizhong: Hi! You might uncomment def section if you want use it. (it's in the beggining of base.c) =============================== #if (DAHDI_CHUNKSIZE != 8) #error Sorry, wcb4xxp does not support chunksize != 8 #endif //#define SIMPLE_BCHAN_FIFO //#define DEBUG_LOWLEVEL_REGS /* debug __pci_in/out, not b4xxp_setreg */ Regards By: james.zhu james.zhu (zhulizhong) 2009-03-12 03:53:05 hello, yes, i uncommented that. By: odicha (odicha) 2009-03-12 04:08:25 zhulizhong: Change all drv_dbg per dev_info in base.c file. By: andrea lanza (lanzaandrea) 2009-03-12 05:03:18 hi Odicha. I tried with : dahdi-linux-svn dahdi-tools-svn asterisk-1.6.1 svn and no patches aty all; And using the Beronet 2S0 card; I also changed box, it is an opensuse 11.0 , kernel 2.6.25.20-0.1-pae I see almost no changes: dahdi_hardware reports: pci:0000:05:00.0 qozap- 1397:08b4 Junghanns QuadBRI ISDN card I have to manually edit system.conf because dahdi_genconf does not produce anything else than loadzone = us defaultzone = us so I added (as you suggested) # Span 1: B4/0/1 "B4XXP (PCI) Card 0 Span 1" (MASTER) AMI/CCS span=1,1,0,ccs,ami # termtype: te bchan=1-2 hardhdlc=3 echocanceller=mg2,1-2 # Span 2: B4/0/2 "B4XXP (PCI) Card 0 Span 2" AMI/CCS RED span=2,2,0,ccs,ami # termtype: te bchan=4-5 hardhdlc=6 echocanceller=mg2,4-5 when I try do manually modprobe wcb4xxp -vvv, I don't see any lins in dmesg.... modprobe wctc4xxp -vvv insmod /lib/modules/2.6.25.20-0.1-pae/dahdi/dahdi.ko insmod /lib/modules/2.6.25.20-0.1-pae/dahdi/dahdi_transcode.ko insmod /lib/modules/2.6.25.20-0.1-pae/dahdi/wctc4xxp/wctc4xxp.ko in dmesg: dahdi: Telephony Interface Unloaded dahdi: Telephony Interface Registered on major 196 dahdi: Version: SVN-trunk-r6126 dahdi_transcode: Loaded. no lines about wctc4xxp; then doing dahdi_cfg -vvv DAHDI Tools Version - SVN-trunk-r6110 DAHDI Version: SVN-trunk-r6126 Echo Canceller(s): Configuration ====================== SPAN 1: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1) SPAN 2: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1) Channel map: Channel 01: Clear channel (Default) (Echo Canceler: mg2) (Slaves: 01) Channel 02: Clear channel (Default) (Echo Canceler: mg2) (Slaves: 02) Channel 03: Hardware assisted D-channel (Default) (Slaves: 03) Channel 04: Clear channel (Default) (Echo Canceler: mg2) (Slaves: 04) Channel 05: Clear channel (Default) (Echo Canceler: mg2) (Slaves: 05) Channel 06: Hardware assisted D-channel (Default) (Slaves: 06) 6 channels to configure. DAHDI_SPANCONFIG failed on span 1: No such device or address (6) I didn't start asterisk, the problem is about loading the card driver. under /dev/dahdi, I can see: dir /dev/dahdi/ total 0 crw-rw---- 1 asterisk asterisk 196, 254 Mar 12 10:57 channel crw-rw---- 1 asterisk asterisk 196, 0 Mar 12 10:57 ctl crw-rw---- 1 asterisk asterisk 196, 255 Mar 12 10:57 pseudo crw-rw---- 1 asterisk asterisk 196, 253 Mar 12 10:57 timer crw-rw---- 1 asterisk asterisk 196, 250 Mar 12 10:57 transcode Is there any other module required, i.s. some hdlc package (???) Is there anything else you want me to test ? By: odicha (odicha) 2009-03-12 05:09:06 ok you have to patch dahdi-linux and dahdi-tools Use dahdi-linux-2.1.0.4.diff and dahdi-tools-2.1.0.2.diff. make && make install them as usual. Then it might works. Don´t forget stop dahdi service before recompiling them. You need also libpri 1.4.9. I'm online so if you have any trouble you can post here and I'll help you ASAP. Dahdi_hardware might report after patching something like this [root@asterisk dahdi-linux-2.1.0.4]# dahdi_hardware pci:0000:01:00.0 wcb4xxp+ 1397:08b4 BeroNet BN2S0 By: andrea lanza (lanzaandrea) 2009-03-12 05:33:37 Sorry for misunderstanding, I thought diff were already into svn version... now: dahdi_hardware rports: pci:0000:05:00.0 wcb4xxp- 1397:08b4 BeroNet BN2S0 (better than before!) modprobing now DOES create the 6 channels !! dir /dev/dahdi/ total 0 crw-rw---- 1 asterisk asterisk 196, 1 Mar 12 11:29 1 crw-rw---- 1 asterisk asterisk 196, 2 Mar 12 11:29 2 crw-rw---- 1 asterisk asterisk 196, 3 Mar 12 11:29 3 crw-rw---- 1 asterisk asterisk 196, 4 Mar 12 11:29 4 crw-rw---- 1 asterisk asterisk 196, 5 Mar 12 11:29 5 crw-rw---- 1 asterisk asterisk 196, 6 Mar 12 11:29 6 crw-rw---- 1 asterisk asterisk 196, 254 Mar 12 11:29 channel crw-rw---- 1 asterisk asterisk 196, 0 Mar 12 11:29 ctl crw-rw---- 1 asterisk asterisk 196, 255 Mar 12 11:29 pseudo crw-rw---- 1 asterisk asterisk 196, 253 Mar 12 11:29 timer and dahdi_cfg : dahdi_cfg -vvv DAHDI Tools Version - 2.1.0.2 DAHDI Version: 2.1.0.4 Echo Canceller(s): Configuration ====================== SPAN 1: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1) SPAN 2: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1) Channel map: Channel 01: Clear channel (Default) (Echo Canceler: mg2) (Slaves: 01) Channel 02: Clear channel (Default) (Echo Canceler: mg2) (Slaves: 02) Channel 03: Hardware assisted D-channel (Default) (Slaves: 03) Channel 04: Clear channel (Default) (Echo Canceler: mg2) (Slaves: 04) Channel 05: Clear channel (Default) (Echo Canceler: mg2) (Slaves: 05) Channel 06: Hardware assisted D-channel (Default) (Slaves: 06) 6 channels to configure. Changing signalling on channel 1 from Unused to Clear channel Setting echocan for channel 1 to mg2 Changing signalling on channel 2 from Unused to Clear channel Setting echocan for channel 2 to mg2 Changing signalling on channel 3 from Unused to Hardware assisted D-channel Changing signalling on channel 4 from Unused to Clear channel Setting echocan for channel 4 to mg2 Changing signalling on channel 5 from Unused to Clear channel Setting echocan for channel 5 to mg2 Changing signalling on channel 6 from Unused to Hardware assisted D-channel when make menuconfig (dahdi-tools) , I see [*] fxotune [ ] fxstest XXX sethdlc [*] dahdi_cfg [*] dahdi_diag [*] dahdi_monitor [*] dahdi_scan [*] dahdi_speed [*] dahdi_test [*] dahdi_tool so something seems to be missing about hdlc: should I care about it ? about dahdi service: it is not possible to start it, because it contains errors. under /etc/init.d it search a "functions" file (does not exist) Than also lines starting with action should be deleted because action does not mean anything to my box wiping out check about functions and removing leading statement action works under my distribution, but perhaps I am missing something... Now I will try to use the card from asterisk 1.6.1 svn By: odicha (odicha) 2009-03-12 05:36:16 lanzaandrea: you have to install libpri before dahdi-linux and dahdi-tols. Have you installed it? By: andrea lanza (lanzaandrea) 2009-03-12 05:39:01 Yes I had (1.4.9) (before compiling) I cannot compile asterisk-addons-1.6.0.1, having an erroro about format_mp3, and I had to remove that. But this does not matter here! By: odicha (odicha) 2009-03-12 05:57:19 compile all in this order: libpri, dahdi-linux dahdi-tools and asterisk. If dahdi-tools is unable to enable sethdlc you are missing some dependences I have a brief doc on installation method you can take a look at http://odicha.wordpress.com/2009/02/27/asterisk_ojos_rojos/ (Sorry it is in spanish and based on CentOs 5.2) but it could help you in install order. By: andrea lanza (lanzaandrea) 2009-03-12 06:02:34 I compiled in that order. I don't know which is the dependancies I am missing anyway.. asterisk started with dahdi support; now I will try to place /receive a call By: odicha (odicha) 2009-03-12 06:30:12 lanzaandrea: It's all chained. WRONG!! Look at below note (sorry). If you don't have hdlc enabled I think it won't work. Try it anyway, but if it fails, redo all install procedure for supporting in the right way all bri/pri stuff *** You need libpri for BRI/PRI signalling over asterisk :( By: Tzafrir Cohen (tzafrir) 2009-03-12 06:49:21 dahdi-tools does not depend on libpri. sethdlc is not needed for ISDN [PB]RI. No module from asterisk-addons is needed for the basic operations here. lanzaandrea: You seem to have everything OK at the DAHDI level. Maybe the error you got before was because dahdi_dummy got loaded. Generally the patch seems to have recieved enough testing. It needs a bit reformatting in some places. I hope to get to that later today. By: odicha (odicha) 2009-03-12 07:27:18 Tzafrir: Hi! Anything I can help you about reformatting, please make me know. There are two minor fixes I tested over last diff. Do I upload new diff including them befor you start reformatting? One is about spans sync, other on DEBUG_LOWLEVEL_REGS By: Tzafrir Cohen (tzafrir) 2009-03-12 07:42:08 Testing with testpatch from the kernel source tree: $ wget -q -O dahdi_linux_sysfs.diff 'http://bugs.digium.com/file_download.php?file_id=21900&type=bug' $ ~/Proj/Kernel/linux-2.6/scripts/checkpatch.pl --no-tree dahdi_linux_sysfs.diff | wc 589 2553 23219 Including many comments about lines longer than 80 characters, trailing white spaces, incorrect indentation and such. Generally DAHDI follows http://kernel.org/doc/Documentation/CodingStyle By: andrea lanza (lanzaandrea) 2009-03-12 07:43:32 Yes, I had dahdi_dummy loaded before now, from asterisk, I can see this: CLI> dahdi show status Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO B4XXP (PCI) Card 0 Span 1 OK 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) B4XXP (PCI) Card 0 Span 2 RED 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) I connected only 1 line to by board. also dahdi_tool reports span 1 is ok now I will search how to place a call on a dahdi trunk: I belive something like DAHDI/g1/$OUTNUM, but I will search the doc... Now I will search By: andrea lanza (lanzaandrea) 2009-03-12 08:35:09 I am not beying succesful on my test: I always get: -- Executing ...Dial("SIP/456-b7b9ede0", "DAHDI/g2/34813xxxx4,30,t") in new stack == Everyone is busy/congested at this time (1:0/0/1) (I scrambled part of the number I am trying to call) I am using g2 because meanwhile I connected a second line to my board, so now I have: *CLI> dahdi show status Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO B4XXP (PCI) Card 0 Span 1 OK 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) B4XXP (PCI) Card 0 Span 2 OK 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) By: odicha (odicha) 2009-03-12 10:09:34 lanzaandrea, by default when you run dahdi genconf and dahdi_cfg D channels are configured in dchan mode # Span 1: B4/0/1 "B4XXP (PCI) Card 0 Span 1" (MASTER) AMI/CCS span=1,1,0,ccs,ami # termtype: te bchan=1-2 dchan=3 echocanceller=mg2,1-2 try to change them to hardhdlc if they changed. if you do dahdi show channels what do you see? Something like this? asterisk*CLI> dahdi show channels Chan Extension Context Language MOH Interpret Blocked State pseudo default default In Service 1 from-pstn default In Service 2 from-pstn default In Service 4 from-pstn default In Service 5 from-pstn default In Service 7 from-pstn default In Service If you don't see channels perhaps you don't have included dahdi-channels.conf in chan_dahdi.conf. Take a look at signalling in dahdi-channels.conf. Perhaps it's bri_cpe_ptmp and you are using point to point BRIs (it might be bri_cpe). Mainly it's what Tzafrir told you before. Dahdi seems to be working fine. It must be something into your config. By: andrea lanza (lanzaandrea) 2009-03-12 10:14:14 I can confirm it is working now... simply I was giving the "bad" name to a file, specifically: mv dahdi-channels.conf chan_dahdi.conf solved the problem... now I see: CLI> dahdi show channels Chan Extension Context Language MOH Interpret Blocked State pseudo default default In Service 1 from-pstn default In Service 2 from-pstn default In Service 4 from-pstn default In Service 5 from-pstn default In Service and can place/receive calls on the outside line The only problem remaining is that it is "very SVN".... I also solved that problem about compilation of format_mp3 (again using asterisk-addons-1.6.1-svn is compiling ok) I am used to integrate with FreePBX, and I saw it works in my env. So.. I think I could try to deploy this in my production env... beying ready to come back to the 1.4 branch/misdn By: james.zhu james.zhu (zhulizhong) 2009-03-12 21:47:03 anyone test that under NT mode? i have an error when loading the chan_dahdi.so. the results are: 1) modprobe wcb4xxp ok. it shows me the card in NT mode 2) changed the TE mode into NT mode in chan_dahdi.conf signalling = bri_net_ptmp pridialplan = local prilocaldialplan = dynamic nationalprefix = 0 internationalprefix = 00 priindication = passthrough echocancel = yes context=from-test group = 1 signalling = bri_net_ptmp ; S/T port 1 channel => 1-2 group = 2 ; S/T port 2 signalling = bri_net_ptmp channel => 4-5 group = 3 ; S/T port 3 signalling = bri_net_ptmp channel => 7-8 group = 4 ; S/T port 4 but when i load the so, asterisk reports this error: ================================================================= [Mar 13 10:33:42] WARNING[2894]: chan_dahdi.c:14282 process_dahdi: How cool would it be if someone implemented this mode! For now, sucks for you. (line 978) [Mar 13 10:33:42] ERROR[2894]: chan_dahdi.c:13781 build_channels: Signalling must be specified before any channels are. [Mar 13 10:33:42] ERROR[2894]: chan_dahdi.c:13781 build_channels: Signalling must be specified before any channels are. == Parsing '/etc/asterisk/users.conf': == Found [Mar 13 10:33:42] WARNING[2894]: chan_dahdi.c:14415 process_dahdi: 'passthrough' is not a valid pri indication value, should be 'inband' or 'outofband' at line 974. [Mar 13 10:33:42] WARNING[2894]: chan_dahdi.c:14415 process_dahdi: 'passthrough' is not a valid pri indication value, should be 'inband' or 'outofband' at line 974. [Mar 13 10:33:42] WARNING[2894]: chan_dahdi.c:14282 process_dahdi: How cool would it be if someone implemented this mode! For now, sucks for you. (line 978) [Mar 13 10:33:42] WARNING[2894]: chan_dahdi.c:14282 process_dahdi: How cool would it be if someone implemented this mode! For now, sucks for you. (line 978) [Mar 13 10:33:42] ERROR[2894]: chan_dahdi.c:13781 build_channels: Signalling must be specified before any channels are. [Mar 13 10:33:42] ERROR[2894]: chan_dahdi.c:13781 build_channels: Signalling must be specified before any channels are. =============================================================== =====================code========================================= static int build_channels(struct dahdi_chan_conf *conf, int iscrv, const char *value, int reload, int lineno, int *found_pseudo) { char *c, *chan; int x, start, finish; struct dahdi_pvt *tmp; #ifdef HAVE_PRI struct dahdi_pri *pri; int trunkgroup, y; #endif if ((reload == 0) && (conf->chan.sig < 0) && !conf->is_sig_auto) { ast_log(LOG_ERROR, "Signalling must be specified before any channels are.\n"); return -1; } c = ast_strdupa(value); ================================================== please double check for that. chan.sig return -1 and is_sig_auto return 0. there is conf file called dahdi_channels.conf under /etc/asterisk? what is purpose for? By: andrea lanza (lanzaandrea) 2009-03-13 05:07:32 First day using dahdi impression: fantastic! Post Delay Dial is dramatically lower (almost istantaneous, while using mISDN I had to wait several seconds, let's say more than 5 and near 10) Also taking calls using *8 is again possible, while using latest mISDN /*1.4.23 wasn't --- I would like to have a patch in order to support also single BRI HFC cards, so I tried to menage it by myself.. with no luck! I started modifing dahdi-tools-2.1.0.2/xpp/perl_modules/Dahdi/Hardware/PCI.pm adding '1397:2bd0/1397:2bd0' => { DRIVER => 'wcb4xxp', DESCRIPTION => 'HFC-1S ISDN BRI card' }, (and removing the corresponding line about 1397:2bd0) then I added HFC1S, /* HFC-1S Generic single BRI PCI */ to the enumeration into dahdi-linux-2.1.0.4/drivers/dahdi/wcb4xxp/wcb4xxp.h and also modified dahdi-linux-2.1.0.4/drivers/dahdi/wcb4xxp/base.c according to what I see you did in the patch, i.e. I added: static struct devtype hfc1s = { "Generic HFC Chipset single BRI PCI", .ports = 1, .has_ec = 0, .card_type = HFC1S }; and aother... The problem I have is that recompiling dahdi_hardware now reports: pci:0000:05:00.0 wcb4xxp+ 1397:2bd0 HFC-S ISDN BRI card lspci -nn -v reports: 05:00.0 Network controller [0280]: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] [1397:2bd0] (rev 02) Subsystem: Cologne Chip Designs GmbH ISDN Board [1397:2bd0] Flags: medium devsel, IRQ 18 I/O ports at d8f8 [size=8] Memory at dffeff00 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 1 Kernel driver in use: wcb4xxp Kernel modules: hisax, wcb4xxp but dmesg, on loading wcb4xxp drivers, says: dahdi: Telephony Interface Registered on major 196 dahdi: Version: 2.1.0.4 wcb4xxp 0000:05:00.0: probe called for b4xx... ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 18 (level, low) -> IRQ 18 wcb4xxp 0000:05:00.0: Unknown/unsupported controller detected (R_CHIP_ID = 0xff) ACPI: PCI interrupt for device 0000:05:00.0 disabled The question is: do you think it would be nice to go on on this road and try to support also this kind of boards ? Do you want me to try to modify something or uploading this patch (I should have a License, having uploaded a patch last summer...). Is it better to start another bug ? By: Tzafrir Cohen (tzafrir) 2009-03-13 05:08:54 I'm refactoring the patch a bit. A few points to consider: 1. Please try to provide a patch that can be applied with patch -p0 . You can use 'svn diff' . The patch you provided uses full path and thus required removing a random number of path elements (4, in this case, thus patch -p4). 2. Now that we have span_type there's no more point in has_ec . I replaced it with: #define CARD_HAS_EC(card) ((card)->card_type == B410P) The name is descriptive enough to remove the need for extra comments in those lines. 3. I'm refactoring the leds handling functions to use the BIT macros. I suddenly ran into: lled |= 0 << j; Is that supposed to be a '&=' ? lled does not seem to be initialized anywhere. Looks like it will take me a bit longer than expected to get this one into shape. By: odicha (odicha) 2009-03-13 05:30:55 Tzafrir: Hi! What led function tries to do is getting a "bitmap" of leds status for write them into card register. If you think it's better way initilize lled before writing bitmap then there's no problem at all. It always write all bitmap (8 leds) but it's a little dirty. Sorry for my "poor performance" writing code, but this is not my main knowledge area. I try to do the best I can, but my skills in this area are low. I left has_ec enabled because I thought perhaps we could have in future time more cards with Echo Cancelling hardware. Anyway we can "or" sections where we could need them. All changes seem me fine. Zhulizhong: You are trying to work in nt ptmp mode (not libpri supported yet) In NT ptp mode (bri_net) works fine. Change test environment from NT point-to-multipoint to point to point. I'm looking at it because I need it in a very strange (ASterisk as "man in the middle") environment I need to set up. If I get any good status I'll make you know. By: andrea lanza (lanzaandrea) 2009-03-13 06:27:11 I succeded in getting "something" to work with a single span HFC dmesg now shows: wcb4xxp 0000:05:00.0: probe called for b4xx... ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 18 (level, low) -> IRQ 18 wcb4xxp 0000:05:00.0: Identified Generic HFC Chipset single BRI PCI (controller rev 31) at 0001d8f8, IRQ 18 wcb4xxp 0000:05:00.0: NOTE: hardware echo cancellation has been disabled wcb4xxp 0000:05:00.0: Port 1: NT mode wcb4xxp 0000:05:00.0: Did not do the highestorder stuff dahdi_echocan_mg2: Registered echo canceler 'MG2' dahdi: Registered tone zone 11 (Italy) and 3 channels are created under /dev/dahdi but way it is in NT Mode ? Under asterisk I defined it as cpe ptmp, in fact: > dahdi show channel 1 File Descriptor: 10 Span: 1 Extension: Dialing: no Context: from-pstn Caller ID: Calling TON: 0 Caller ID name: Mailbox: none Destroy: 0 InAlarm: 1 Signalling Type: ISDN BRI Point to MultiPoint Radio: 0 Owner: <None> Real: <None> Callwait: <None> Threeway: <None> Confno: -1 Propagated Conference: -1 Real in conference: 0 DSP: no Busy Detection: no TDD: no Relax DTMF: no Dialing/CallwaitCAS: 0/0 Default law: alaw Fax Handled: no Pulse phone: no DND: no Echo Cancellation: 128 taps (unless TDM bridged) currently OFF PRI Flags: PRI Logical Span: Implicit Hookstate (FXS only): Onhook So way it starts as NT mode ? (in order to make it starts, I had to trick and add 0xFF : if ((x != 0xc0) && ( x != 0x80) && ( x != 0xFF)) { By: odicha (odicha) 2009-03-13 14:59:05 lanzaandrea: It has a different chip. It could need lots of changes. By: Tzafrir Cohen (tzafrir) 2009-03-15 14:31:45 I reformatted the code according to checkpatch.pl's orders. Along the way I reworked the LED code to be much simpler and readable. Frankly I'm willing to commit this code even if the LEDs functionality does not work properly assuming other things do work properly, as the card can work even without the LEDs blinking along (albeit not nicely. And now the code of the LEDs is more readable, and thus I hope it will be simpler to fix it. Could you please test wcb4xxp_extracards.diff and note in your followup what card model(s) have you tested it with? By: odicha (odicha) 2009-03-16 11:08:25 Hi, Tzafrir! Some minor fixes on led signalling section. I wrote comments here on code changes. Comments are not in diff file. (Poor english & poor skills. If I write on code you surelly must change it) Now looking at code I understand BIT_SET & BIT_CLR... (sorry) svn diff is based on Revision 6168 HFC-8S + if ((bspan->span.flags & DAHDI_FLAG_RUNNING) && (bspan->span.alarms)){ /* Here I changed conditions. It was always on "continue" .... */ + BIT_SET(lled, (j-1)); /* j - 1 because leds are from 7 to 0. "j" goes from 8 to 1 */ + continue; /* Led OFF */ + } + + if (bspan->span.mainttimer || bspan->span.maintstat) { + /* Led Blinking in maint state */ + if (b4->blinktimer >= 0x7f) + BIT_SET(lled, (j-1)); + } + Tested succesfully on OpenVox B800P HFC-4S + int i, leds = 0; /* Changed green_led & red_led => leds */ + struct b4xxp_span *bspan; + + b4->blinktimer++; + for (i=0; i < b4->numspans; i++) { + bspan = &b4->spans[i]; + + if (!(bspan->span.flags & DAHDI_FLAG_RUNNING)) + continue; /* Leds are off */ + + if (bspan->span.alarms) { + /* Red blinking -> Alarm */ + if (b4->blinktimer >= 0x7f) + BIT_SET(leds, i); + } else if (bspan->span.mainttimer || bspan->span.maintstat) { + /* Green blinking -> Maint status */ + if (b4->blinktimer >= 0x7f){ + BIT_SET(leds, i); + BIT_SET(leds, (i+4)); /*Led green needs two bits enabled (one for "ON" state and one for "Green" colour so Green Led for span 0 enables bit 0 and bit 4 Red Led enables only bit 0 */ + } + } else { + /* No Alarm - Green */ + BIT_SET(leds, i); + BIT_SET(leds, (i+4)); + } + } + b4xxp_setreg8(b4, R_GPIO_EN1, leds & 0x0f); + b4xxp_setreg8(b4, R_GPIO_OUT1, leds >> 4); + + if (b4->blinktimer == 0xff) + b4->blinktimer = -1; Tested OK on OpenVox B200P. Untested on B400P. It might work. I'll test it ASAP By: Tzafrir Cohen (tzafrir) 2009-03-17 10:11:52 OK. applied your changes slightly differently By: odicha (odicha) 2009-03-17 11:01:22 Only one thing +static void b4xxp_update_leds_hfc_8s(struct b4xxp *b4) .................................. + b4->blinktimer++; + for (j = 7; j >= 0; j--) { + bspan = &b4->spans[7 - j]; + if ((bspan->span.flags & DAHDI_FLAG_RUNNING) || + bspan->span.alarms) { + BIT_SET(lled, j); + continue; /* Led OFF */ Change + if ((!(bspan->span.flags & DAHDI_FLAG_RUNNING))|| + bspan->span.alarms) { (If is not running or there are alarms) In first case always is true (It's running) and lights don't turn on because always continues. Or perhaps We could apart them and let it blink in red alarm case. Perhaphs different timing from main state. Tested ok with this change in OpenVox B800P & B200P TE & NT modes. Only this change and I think it can go into SVN. Congratulations Tzafrir! By: Tzafrir Cohen (tzafrir) 2009-03-17 11:19:39 Fixed my patch: wcb4xxp_extracards_2.diff This issue now only awaits final confirmation that it does not break B410P cards. By: odicha (odicha) 2009-03-17 11:30:39 Tested against fixed patch - OK! (OpenVox B800P & B200P) By: odicha (odicha) 2009-03-19 06:37:58 Hi Tzafrir! Uploaded diff for dahdi-tools. (for dahdi_hardware info) By: Kinsey Moore (opticron) 2009-04-02 10:55:35 I tested this with wcb4xxp_extracards_2.diff and wcb4xxp_extra_cards_dahdi-tools.diff on a B410P. LED behavior seems correct for all spans and the call I passed over the line sounded good. I haven't had time to setup for an echocan test and may not get to it for a couple of days. By: Jean-Denis Girard (jdg) 2009-04-04 23:06:16 Testing since yesterday with Junghanns DuoBRI (only one channel used, connected in p2mp TE mode): . libpri-1.4.9, . dahdi-linux-svn-6323 + wcb4xxp_extracards_2.diff, . dahdi-tools-svn-6323 + wcb4xxp_extra_cards_dahdi-tools.diff, . Asterisk-1.6.1-rc3. It's working fine. HDLC errors I reported in December are gone. No LEDs, but that was expected. By: Kristijan Vrban (vrban) 2009-05-03 20:52:54 @lanzaandrea for the single BRI HFC-PCI cards you can try the dahdi-zaphfc from debian: http://svn.debian.org/viewsvn/pkg-voip/dahdi-linux/trunk/drivers/dahdi or try to rework the vzaphfc to dahdi By: Giovanni Lovato (heruan) 2009-05-25 12:47:59 I have a Junghanns BRI PCI card: 1397:08b4 Junghanns QuadBRI ISDN card It's not recognized by DAHDI and the patches don't apply on trunk. When the support for these cards will be committed to trunk? By: Giovanni Lovato (heruan) 2009-05-27 09:30:47 I applied wcb4xxp_extracards_2.diff and now the Junghanns DuoBRI is recognized by DAHDI. And by Asterisk too, but I can't dial nor receive calls! All seem to go straight: when trying to dial out, Asterisk dials on DAHDI/G0/<number> and waits, but <number> does not ring. When trying to receive a call, nothing happens. @jdg: you told "it's working fine", did you mean you can dial and receive calls? By: Jean-Denis Girard (jdg) 2009-05-27 10:56:55 @heruan Yes, i can dial and receive calls ! It's been working fine since my last report (April 4th); it's my home system, so not really loaded, but it made / received 458 calls through the DuoBRI card. I've upgraded Asterisk once or twice since that date, but didn't upgrade Dahdi. This is what I have: tiare*CLI> core show version Asterisk 1.6.1.0 built by jdg @ tiare.sysnux.pf on a x86_64 running Linux on 2009-04-29 16:24:51 UTC tiare*CLI> core show uptime System uptime: 3 weeks, 6 days, 22 hours, 55 minutes, 29 seconds Last reload: 3 weeks, 6 days, 22 hours, 55 minutes, 29 seconds tiare*CLI> dahdi show status Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO B4XXP (PCI) Card 0 Span 1 OK 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) B4XXP (PCI) Card 0 Span 2 RED 0 0 0 CAS Unk YEL 0 db (CSU)/0-133 feet (DSX-1) tiare*CLI> dahdi show version DAHDI Version: SVN--r6312M Echo Canceller: MG2 By: M. Schinkel (schinkelm) 2009-05-28 05:56:42 HI, I would like to test the hfc-8s support in nt mode with my Junghanns OctoBRI. Can someone please commit the current patches to svn? The amount of attached files in this issue makes it hard to get the right patch order :-) By: M. Schinkel (schinkelm) 2009-05-28 06:56:13 Hm, as of https://issues.asterisk.org/view.php?id=15048 it seems that ptmp is not working right now. But nt mode with a single phone should work. Is that correct? By: Kristijan Vrban (vrban) 2009-05-28 09:35:02 @schinkelm PTP and PTMP in TE mode is allready working in libpri/chan_dahdi, also PTP in NT mode. It's only PTMP in NT mode that is in development. By: Giovanni Lovato (heruan) 2009-06-01 11:29:22 @jdg I have a configuration similar to yours, but I can't dial nor receive calls. No errors from asterisk, just silence. Can you post relevant parts of your /etc/dahdi/system.conf and /etc/asterisk/chan_dahdi.conf or /etc/asterisk/dahdi-channles.conf? Thank you! By: Jean-Denis Girard (jdg) 2009-06-01 13:23:11 @heruan /etc/dahdi/system.conf: ======================= loadzone = fr defaultzone=fr span=1,1,0,ccs,ami echocanceller=mg2,1,2 bchan=1,2 hardhdlc=3 chan_dahdi.conf =============== channels] language=fr switchtype = euroisdn signalling = bri_cpe_ptmp pridialplan = unknown prilocaldialplan = unknown overlapdial = yes echocancel=yes echotraining = 100 echocancelwhenbridged=yes facilityenable=yes transfer=yes faxdetect=both immediate=no group = 1 context=entrant channel => 1-2 By: Giovanni Lovato (heruan) 2009-06-15 07:20:17 Thank you jdg, but I still cannot receive make calls. Some infos: sip*CLI> dahdi show status Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO B4XXP (PCI) Card 0 Span 1 OK 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) B4XXP (PCI) Card 0 Span 2 RED 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) sip*CLI> dahdi show channels Chan Extension Context Language MOH Interpret Blocked State pseudo default default In Service 1 from-pstn default In Service 2 from-pstn default In Service Channes 1,2 are in group 11. When I call the PBX from the outside, Asterisk doesn't receive anything and when I try to make a call I get: -- Executing [03xxx51@telperion:2] Dial("SIP/13-08c24250", "DAHDI/G11/3xxx51,,T") in new stack [Jun 15 14:13:00] WARNING[2222]: app_dial.c:1518 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion) == Everyone is busy/congested at this time (1:0/1/0) -- Auto fallthrough, channel 'SIP/13-08c24250' status is 'CONGESTION' And then my ISDN CPE randomly get stuck and I have to reset it! By: Tim King (timking) 2009-06-15 07:40:54 B4XXP (PCI) Card 0 Span 2 RED 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) The word RED means you have a red alarm on this card. Is it connected? Try one card at a time. Or have you described two cards and you only have one? By: Giovanni Lovato (heruan) 2009-06-15 07:52:42 I have a Junghanns DuoBRI ISDN PCI card, with two ISDN ports. The first is connected to the external ISDN line, the second isn't connected at all (yet). By: xelinaf (xelinaf) 2009-06-15 09:44:11 @heruan: Does your card work with other ISDN drivers (e.g. mISDN or CAPI)? Maybe it is hardware problem and not connected to the DAHDI driver: Check the PCI latencies of your other(!) PCI cards. They must not block your PCI bus for too long, else the HFC chip gets stucked: 'lspci -vv' shows the latencies. It should not be above 32 for any card. In order to reduce the latencies, there should be an option in the BIOS "PCI latency timer". Nevertheless there are some buggy BIOS, which do not set the latency for every PCI device. In that case you can set the latency manually: setpci -vv -s <your device> latency_timer=<latency in hex> e.g. 'setpci -vv -s 00:11.7 latency_timer=20' By: Giovanni Lovato (heruan) 2009-06-15 10:11:51 The card works with Zaptel, qozap module and Asterisk 1.4. But I can't find the qozap module for DAHDI... # lspci -vv 00:0e.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01) Subsystem: Cologne Chip Designs GmbH HFC-4S [Junghanns DuoDBRI] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at 1cd0 [size=8] Region 1: Memory at fe004000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel modules: wcb4xxp By: M. Schinkel (schinkelm) 2009-06-15 10:19:55 @heruan: xelinaf: "Check the PCI latencies of your other(!) PCI cards." Look at the output of "lspci -vvt" and see which other cards are on the same pci bus with your bri card. Then check for these cards if any of them has a latency higher than 32 and set it to 32 (= 20 in hex) if so. By: Giovanni Lovato (heruan) 2009-06-15 15:50:00 Okay, I admit I can't read =/ BTW, I have only that PCI card: do integrated controllers and stuff matter? $ lspci -vv | egrep "(^0|Latency)" 00:00.0 Host bridge: Cyrix Corporation PCI Master Latency: 0 00:0b.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller Latency: 64 (2750ns min, 13000ns max) 00:0c.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller Latency: 64 (2750ns min, 13000ns max) 00:0d.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) Latency: 168, Cache Line Size: 128 bytes 00:0d.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) Latency: 168, Cache Line Size: 128 bytes 00:0e.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01) 00:12.0 ISA bridge: National Semiconductor Corporation SC1100 Bridge Latency: 4, Cache Line Size: 32 bytes 00:12.1 Bridge: National Semiconductor Corporation SC1100 SMI & ACPI 00:12.2 IDE interface: National Semiconductor Corporation SCx200, SC1100 IDE controller (rev 01) (prog-if 80 [Master]) Latency: 0 00:12.3 Multimedia audio controller: National Semiconductor Corporation SCx200, SC1100 Audio Controller Latency: 0 00:12.4 VGA compatible controller: National Semiconductor Corporation Device 0514 (rev 01) (prog-if 00 [VGA controller]) 00:12.5 Bridge: National Semiconductor Corporation SC1100 XBus 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev 08) (prog-if 10 [OHCI]) Latency: 64 (20000ns max), Cache Line Size: 32 bytes 05:00.0 USB Controller: NEC Corporation USB (rev 44) (prog-if 10 [OHCI]) Latency: 64 (250ns min, 10500ns max) 05:00.1 USB Controller: NEC Corporation USB 2.0 (rev 05) (prog-if 20 [EHCI]) Latency: 68 (4000ns min, 8500ns max), Cache Line Size: 32 bytes By: M. Schinkel (schinkelm) 2009-06-15 16:02:25 @heruan: I'm not a pci expert but imho integrated controllers matter if they are on the same bus and there is no bridge between them By: xelinaf (xelinaf) 2009-06-15 16:23:50 @heruan: For myself I had a problem with my host bridge having a latency of 128 and an HFC-S chip. All other cards have a latency of 32 or less. Since I changed the latency to 16, everything works fine. Just give it a try and set all latencies >32 to 32 or 16, i.e.: setpci -vv -s 00:0b latency_timer=10 setpci -vv -s 00:0c latency_timer=10 setpci -vv -s 00:0d latency_timer=10 setpci -vv -s 00:13 latency_timer=10 setpci -vv -s 05:00 latency_timer=10 BTW: I've got the same error message as you got with my HFC-4S card. :( I've got two devices with a latency of 248. But unfortunately I cannot modify the PCI latency for these 2 devices on my board. :( Thus I cannot check myself, if the pci latency is the cause of our problem. By: Giovanni Lovato (heruan) 2009-06-23 05:07:57 Thank you, I'll try as soon as possibile this latencies trick. But I don't understand why with zaptel and qozap it worked perfectly and now we need to hack those values... Maybe it's just a temporary workaround? Will the next dahdi release support this card better? By: nenadr (nenadr) 2009-07-02 07:42:57 I can confirm that this patch is wotking OK with both OpenVox B400P (PCI) and B400M (miniPCI) card (including LEDs), except in part that is not "treated" by this patch (take a look at the notes of bug# 0014031 (https://issues.asterisk.org/view.php?id=14031 )). By: Digium Subversion (svnbot) 2009-07-02 15:35:36 Repository: dahdi Revision: 6822 U tools/trunk/xpp/perl_modules/Dahdi/Hardware/PCI.pm ------------------------------------------------------------------------ r6822 | tzafrir | 2009-07-02 15:35:36 -0500 (Thu, 02 Jul 2009) | 19 lines Officially declare we support all HFC-xS cards. (closes issue DAHLIN-59) Reported by: tzafrir Patches: wcb4xxp_extra_cards_dahdi-tools.diff uploaded by Odicha (license 700) The main fix is in commits the following commits to dahdi-linux: r6812, r6813, r6814, r6815, r6816, r6817, r6818 and r6821 Those include the contents of: wcb4xxp_extracards_leds_fixes.diff uploaded by Odicha (license 700) Tested by: zhulizhong, jdg, tzafrir, okrief, Odicha, opticron, vrban Many thanks for all the testing, patches and feedback from this issue. ------------------------------------------------------------------------ http://svn.digium.com/view/dahdi?view=rev&revision=6822 | ||