| Summary: | ASTERISK-05906: Some Zaptel's failures while working with CONFIG_ZAPATA_NET defined. | ||
| Reporter: | Mikhail Khelik (mixel) | Labels: | |
| Date Opened: | 2005-12-26 07:06:21.000-0600 | Date Closed: | 2006-01-12 09:29:48.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) mixel_zaptel.c.patch | |
| Description: | 1) Trouble: It fails to compile on 2.4.x kernels with new HDLC API. Solution: correction of the mistake in zt_net_open function. 2) Trouble: Then I bound together some span's timeslots to use them as one HDLC channel it produced very high CPU payload in case of transmition of data on this channel. E.g. in case of assingment of all span's timeslots to one channel my CPU spent 99,3% of time to serve transmition on it. CPU payload is proportional to the HDLC data stream utilisation. Solution: It's nessasary to put process calling zt_xmit function to sleep till TX buffer is full. This patch solves both problems. ****** ADDITIONAL INFORMATION ****** This patch doesn't solve another problem. If I create two or three HDLC channels which use all span's timeslots, extra activity on CPU leads to HDLC RX framing errors on each channel, on the remote side I can also see HDLC framing violation. In these experiments I transmit data on maximal rate on remote and local side. But I use own hardware and driver that's why I am not sure the same problem exists in case of any Digium hardware. | ||
| Comments: | By: Tilghman Lesher (tilghman) 2005-12-26 09:44:58.000-0600 We need a disclaimer on file to even look at your patch. By: Mikhail Khelik (mixel) 2005-12-27 01:56:01.000-0600 Ok, I've passed disclaimer to the office, and they should fax until tomorrow. By: Matthew Fredrickson (mattf) 2005-12-27 07:53:44.000-0600 I think perhaps we need to consider whether or not we want to deprecate support for this in 2.4.x considering how old it is and also considering what a mess the HDLC API changes have been. It's absolutely madness trying to make this work across all the different kernel HDLC API versions. Also, mixel, have you tested your API change on a spread of kernels across the version list (later 2.4.x and 2.6.x kernels) to verify this does not break any other kernel versions (especially later 2.4.x)? What specific kernel version are you trying to compile this against? Matt By: Mikhail Khelik (mixel) 2005-12-27 09:54:24.000-0600 I run zaptel on 2.4.27 kernel, it's not very old in terms of HDLC API, according to http://www.kernel.org/pub/linux/utils/net/hdlc/ this kernel contains 1.14b version of HDLC API, it's the last version for 2.4.x kernels. As I understand zaptel's code in #ifdef NEW_HDLC_API blocks belongs to this API version. I compiled patched version for 2.4.27 and 2.6.8 which came from Debian sarge without problems. I run Zaptel only on 2.4.27 because driver for my hardware still for 2.4.x. The second bug is kernel independent, on any kernel we should call netif_stop_queue on net_device then TX buffers is full. By: Matthew Fredrickson (mattf) 2006-01-12 09:22:03.000-0600 Ok, I don't have a way to test this against a full range of kernels at once (the API changes), but I'm sure I"ll hear about it if it breaks it :-) The other patch (fixing the netif_stop and netif_start) should be ok. Thanks! By: Matthew Fredrickson (mattf) 2006-01-12 09:29:24.000-0600 committed to head | ||