Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Component/s: NewFeature
    • Labels:
      None
    • Mantis ID:
      10353
    • Regression:
      No

      Description

      Add into struct zt_span and struct zt_spaninfo the pci bus position of zaptel card. This feature allow to associate a configuration with a zaptel card.
      If you change the disposition of device or add another card, having the information where the cards is placed.

      You have one Wildcard TE110P placed into pci bus position 0:c.0
      If you add another Wildcard TE110P to pci bus position 0:9.0, the configuration of first Wildcard is assigned to this second card. With the info of position of device, you can find the problem and modify zaptel.conf.

      Into patch is added lszt command that show the pci bus info.

        Activity

        Hide
        Tzafrir Cohen added a comment -

        USB devices, such as the wcusb, don't have a PCI bus ID. They do have a USB bus ID.

        Furthermore, ztdynamic spans might have totally different ID. ztdummy is a single system-wide "device".

        Hence we're talking here about a "connector" and not a "PCI bus ID".
        The xpp driver already reports this on its own (in e.g: /proc/xpp/xbussesand in the new sysfs interface). zaptel_hardware (from xpp/utils) already does some guesswork (based on a list of PCI IDs , the output of lspci and sysfs).

        So it would indeed make sense to add a "connector" field to the span.

        But instead of creating yet another utility to show it, we need a generic way to show information about spans. The /proc/zaptel interface is not good enough because you just can't add fields there.

        Hence I suggest sysfs. See the branch zaptel/team/tzafrir/sysfs .

        Show
        Tzafrir Cohen added a comment - USB devices, such as the wcusb, don't have a PCI bus ID. They do have a USB bus ID. Furthermore, ztdynamic spans might have totally different ID. ztdummy is a single system-wide "device". Hence we're talking here about a "connector" and not a "PCI bus ID". The xpp driver already reports this on its own (in e.g: /proc/xpp/xbussesand in the new sysfs interface). zaptel_hardware (from xpp/utils) already does some guesswork (based on a list of PCI IDs , the output of lspci and sysfs). So it would indeed make sense to add a "connector" field to the span. But instead of creating yet another utility to show it, we need a generic way to show information about spans. The /proc/zaptel interface is not good enough because you just can't add fields there. Hence I suggest sysfs. See the branch zaptel/team/tzafrir/sysfs .
        Hide
        cybershield added a comment -

        Ok thanks for your note.
        I have look zaptel_hardware but it doesn't show the association between device and span. With zaptel_hardware i don't found the disposition of span.

        Output with zaptel_hardware:
        pci:0000:00:09.0 e159:0001 [wcte11xp]
        pci:0000:00:0a.0 e159:0001 [wctdm]

        Output with lszt:
        1 Name: Wildcard TDM400P REV E/F Board 1
        Pci bus: 0000:000a.0
        Local span: 1
        Total channels: 4
        Number channels conf: 4
        Alarms: 00000000 (No alarms)
        Sync: 0 (Internally clocked)

        2 Name: Digium Wildcard TE110P T1/E1 Card 0
        Pci bus: 0000:0009.0
        Local span: 1
        Total channels: 31
        Number channels conf: 15
        Alarms: 00000000 (No alarms)
        Sync: 0 (Internally clocked)

        The "Wildcard TDM400P" is a span1 and the "Wildcard TE110P" is a span2. With only zaptel_hardware this info i don't found. For create the zaptel.conf i need the disposition of span.

        Yes, yet another utility is not good .. this my patch is only stub for found a good solution for this problem.

        Ok i will look the branch zaptel/team/tzafrir/sysfs

        Show
        cybershield added a comment - Ok thanks for your note. I have look zaptel_hardware but it doesn't show the association between device and span. With zaptel_hardware i don't found the disposition of span. Output with zaptel_hardware: pci:0000:00:09.0 e159:0001 [wcte11xp] pci:0000:00:0a.0 e159:0001 [wctdm] Output with lszt: 1 Name: Wildcard TDM400P REV E/F Board 1 Pci bus: 0000:000a.0 Local span: 1 Total channels: 4 Number channels conf: 4 Alarms: 00000000 (No alarms) Sync: 0 (Internally clocked) 2 Name: Digium Wildcard TE110P T1/E1 Card 0 Pci bus: 0000:0009.0 Local span: 1 Total channels: 31 Number channels conf: 15 Alarms: 00000000 (No alarms) Sync: 0 (Internally clocked) The "Wildcard TDM400P" is a span1 and the "Wildcard TE110P" is a span2. With only zaptel_hardware this info i don't found. For create the zaptel.conf i need the disposition of span. Yes, yet another utility is not good .. this my patch is only stub for found a good solution for this problem. Ok i will look the branch zaptel/team/tzafrir/sysfs
        Hide
        Tzafrir Cohen added a comment -

        cybershild, please check ztscan and ZT_SPANSTAT on current zaptel branches/1.4 . Anything missing from there?

        Show
        Tzafrir Cohen added a comment - cybershild, please check ztscan and ZT_SPANSTAT on current zaptel branches/1.4 . Anything missing from there?
        Hide
        cybershield added a comment -

        I did not look at the svn version of zaptel 1.4. Ztscan provides this Expanded information. The only difference is that you provide the strings that must parsed for use in an application. A difference on a format of "zt_spaninfo.location" invalidate a parsing. Why the information (location, localspan, ..) of card is write into string ?

        Show
        cybershield added a comment - I did not look at the svn version of zaptel 1.4. Ztscan provides this Expanded information. The only difference is that you provide the strings that must parsed for use in an application. A difference on a format of "zt_spaninfo.location" invalidate a parsing. Why the information (location, localspan, ..) of card is write into string ?
        Hide
        Jason Parker added a comment -

        If I read the last note right, the reporter agreed that the code added was the same end result, just in a different way.

        Because of this, I'm going to go ahead and close this issue.

        Show
        Jason Parker added a comment - If I read the last note right, the reporter agreed that the code added was the same end result, just in a different way. Because of this, I'm going to go ahead and close this issue.

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development