Patlooptest Output – Errors

Home » Asterisk Users » Patlooptest Output – Errors
Asterisk Users 15 Comments

Hi there,

Running patlooptest following instructions on Digium KB, using dahdi 2.5.1
with a TE205P. I’m getting this kind of output (not full output). Note, I’m using a standard cat5 ethernet cable (30cm), with a Digium T10i crossover.

Error 4985 (loop 19898, offset 425, error 214): Unexpected result, Read:
0xff, Expected 0x00. Offset 422 { ff ff ff ff ff ff ff }
Error 4986 (loop 19898, offset 426, error 215): Unexpected result, Read:
0xff, Expected 0x00. Offset 423 { ff ff ff ff ff ff ff }
Error 4987 (loop 19898, offset 427, error 216): Unexpected result, Read:
0xff, Expected 0x00. Offset 424 { ff ff ff ff ff ff ff }
Error 4988 (loop 19898, offset 428, error 217): Unexpected result, Read:
0xff, Expected 0x00. Offset 425 { ff ff ff ff ff ff ff }
Error 4989 (loop 19898, offset 429, error 218): Unexpected result, Read:
0xff, Expected 0x00. Offset 426 { ff ff ff ff ff ff 2e }
Error 4990 (loop 19898, offset 430, error 219): Unexpected result, Read:
0xff, Expected 0x00. Offset 427 { ff ff ff ff ff 2e 2f }
Error 4991 (loop 19898, offset 431, error 220): Unexpected result, Read:
0xff, Expected 0x00. Offset 428 { ff ff ff ff 2e 2f 30 }
Error 4992 (loop 19898, offset 432, error 221): Unexpected result, Read:
0x2e, Expected 0x00. Offset 429 { ff ff ff 2e 2f 30 31 }
Event: 29
Event: 30
Error 4993 (loop 24990, offset 0, error 1): Unexpected result, Read: 0x7e, Expected 0x7a. Offset 0 { 7e 7f 80 81 }
Error 4994 (loop 24990, offset 428, error 2): Unexpected result, Read:
0xff, Expected 0x2a. Offset 425 { 27 28 29 ff ff ff ff }
Error 4995 (loop 24990, offset 429, error 3): Unexpected result, Read:
0xff, Expected 0x00. Offset 426 { 28 29 ff ff ff ff 2a }
Error 4996 (loop 24990, offset 430, error 4): Unexpected result, Read:
0xff, Expected 0x00. Offset 427 { 29 ff ff ff ff 2a 2b }

Cause for concern?

I’m testing a card which has been used before without issues. I’m just playing with patlooptest for the first time, and wasn’t expecting to see this on a supposedly good card.

appreciate any input, thx.

rgds.

15 thoughts on - Patlooptest Output – Errors

  • For patlooptest ensure that:
    – Your ethernet cable is straight through and not crossover
    – The span you’re testing is set to “provide” timing, not recover
    – In dahdi_tools you can “make utils” and just use dahdi_maint to put the card into loopback without messing with cables.

  • Thanks.

    The cable is straight, and I was using it together with dahdi:maint. Both spans are set to provide (0). I’ve now tested span 1 again without cable, and still same kind of result:

    Timeout achieved Ending Program Test ran 28309 loops of 2039 bytes/loop with 3692 errors

    Interestingly, span 2 goes into loop mode, but patlooptest can’t access it:

    /dev/dahdi/2: Device or resource busy

    And I do not have Asterisk running.

    Mind, I have been told recently by Digium support that a fully conclusive test (in the context of eventual RMA) requires the physical loopback. So I
    am a bit confused in what’s the most correct way of doing this kind of tests. patlooptest + physical loopback? patlooptest alone? physical loopback with some other method?

    Thanks.

  • You should be able to use “lsof /dev/dahdi/2” to find out what process has the file open.

    Physical loopback devices are nice because they encompass the cable into testing. Digital loopbacks are nice because you don’t have to get up from your desk and plug something in 🙂 We use them a lot in our automated testing.

    One other thing to note. Sometimes patlooptest can be starved by the process scheduler. When this happens, it won’t have enough time to produce or consume all the sequential bytes that it needs to. Then it will report errors. You can try increasing the scheduler priority with:
    chrt 99 patlooptest …

  • Thanks for the tips. I forgot to mention, i did try lsof, and it comes out with no result.

    There is one thing I see different between the spans:

    shell> head /proc/dahdi/1
    Span 1: TE2/0/1 “T2XXP (PCI) Card 0 Span 1” B8ZS/ESF LOOP

    1 TE2/0/1/1 Clear Master RED
    2 TE2/0/1/2 Clear RED
    3 TE2/0/1/3 Clear RED
    4 TE2/0/1/4 Clear RED
    5 TE2/0/1/5 Clear RED
    6 TE2/0/1/6 Clear RED
    7 TE2/0/1/7 Clear RED
    8 TE2/0/1/8 Clear RED
    shell> head /proc/dahdi/2
    Span 2: TE2/0/2 “T2XXP (PCI) Card 0 Span 2” (MASTER) B8ZS/ESF LOOP
    CRC4 error count: 1
    E-bit error count: 1

    25 TE2/0/2/1 Clear Master LOOP
    26 TE2/0/2/2 Clear LOOP
    27 TE2/0/2/3 Clear LOOP
    28 TE2/0/2/4 Clear LOOP
    29 TE2/0/2/5 Clear LOOP
    30 TE2/0/2/6 Clear LOOP
    shell> cat /etc/dahdi/system.conf loadzone=us defaultzone=us span=1,0,0,esf,b8zs clear=1-24
    span=2,0,0,esf,b8zs clear%-48

    Note the CRC4 and E-bit lines on span 2.

    Right now both ports are in loop mode, no cable attached.

    Maybe you guys @ Digium have seen this before as a symptom of card malfunction?

    Thanks.

  • [snip]

    [snip]

    Those events (29 and 30) indicate that patlooptest isn’t able to keep up with the hardware.

    Do you get the same thing when you run patloop test with elevated permissions?

    $ chrt -f 99 patlooptest

    Cheers, Shaun

  • Ok, I’m a believer now:

    shell> chrt -f 99 patlooptest /dev/dahdi/1 -t 300 -vvvvv Using Timeout of 300 Seconds Going for it… Timeout achieved Ending Program Test ran 28295 loops of 2039 bytes/loop with 0 errors

    Still, any hint about this?

    shell> lsof /dev/dahdi/2
    shell>
    shell> chrt -f 99 patlooptest /dev/dahdi/2 -t 300 -vvvvv
    /dev/dahdi/2: Device or resource busy

    Thanks.

  • Asterisk doesn’t necessarily have to open channels via
    /dev/dahdi/. In fact, they generally open
    /dev/dahdi/channel and then use the SPECIFY ioctl to bind that particular file descriptor to a specific dahdi channel.

    So try ‘lsof /dev/dahdi/channel’ and see what you see.

    Cheers, Shaun

  • Still no luck:

    shell> pgrep asterisk shell> ps -ef | grep asterisk shell> lsof /dev/dahdi/channel shell> lsof /dev/dahdi/1
    shell> lsof /dev/dahdi/2
    shell> chrt -f 99 patlooptest /dev/dahdi/2 -t 300 -vvvvv
    /dev/dahdi/2: Device or resource busy

    I can assure no PBX related process is running.

  • Do you see the channel listed as (in use) in /proc/dahdi/1? I.e.

    Before opening channel 2:

    [root@112-17-24-10 ~]# cat /proc/dahdi/1
    Span 1: WCTDM/0 “Wildcard A8B” (MASTER)

    1 WCTDM/0/0 FXOKS (EC: VPMOCT032 – INACTIVE)
    2 WCTDM/0/1 FXOKS (EC: VPMOCT032 – INACTIVE)
    3 WCTDM/0/2 FXOKS (EC: VPMOCT032 – INACTIVE)
    4 WCTDM/0/3 FXOKS (EC: VPMOCT032 – INACTIVE)
    5 WCTDM/0/4 FXOKS (EC: VPMOCT032 – INACTIVE)
    6 WCTDM/0/5 FXSKS RED (EC: VPMOCT032 – INACTIVE)
    7 WCTDM/0/6 Reserved
    8 WCTDM/0/7 Reserved

    After opening channel 2:

    [root@112-17-24-10 ~]# cat /proc/dahdi/1
    Span 1: WCTDM/0 “Wildcard A8B” (MASTER)

    1 WCTDM/0/0 FXOKS (EC: VPMOCT032 – INACTIVE)
    2 WCTDM/0/1 FXOKS (In use) (EC: VPMOCT032 – INACTIVE)
    3 WCTDM/0/2 FXOKS (EC: VPMOCT032 – INACTIVE)
    4 WCTDM/0/3 FXOKS (EC: VPMOCT032 – INACTIVE)
    5 WCTDM/0/4 FXOKS (EC: VPMOCT032 – INACTIVE)
    6 WCTDM/0/5 FXSKS RED (EC: VPMOCT032 – INACTIVE)
    7 WCTDM/0/6 Reserved
    8 WCTDM/0/7 Reserved

  • SSB0cmllZCBpdCBvbiAxMjMuIFRob3NlIHVzZXIgYW5kIFBXIGRpZCBub3Qgd29yayA6LSgKClNl bnQgZnJvbSBteSBWZXJpem9uIFdpcmVsZXNzIDRHIExURSBEUk9JRAoKU2hhdW4gUnVmZmVsbCA8
    c3J1ZmZlbGxAZGlnaXVtLmNvbT4gd3JvdGU6Cgo+T24gV2VkLCBKYW4gMTUsIDIwMTQgYXQgMDQ6
    MDA6MTlBTSArMDAwMCwgUm9kcmlnbyBCb3JnZXMgUGVyZWlyYSB3cm90ZToKPj4gT2ssIEknbSBh IGJlbGlldmVyIG5vdzoKPj4gCj4+IAo+PiBzaGVsbD4gY2hydCAtZiA5OSBwYXRsb29wdGVzdCAv ZGV2L2RhaGRpLzEgLXQgMzAwIC12dnZ2dgo+PiBVc2luZyBUaW1lb3V0IG9mIDMwMCBTZWNvbmRz Cj4+IEdvaW5nIGZvciBpdC4uLgo+PiBUaW1lb3V0IGFjaGlldmVkIEVuZGluZyBQcm9ncmFtCj4+
    IFRlc3QgcmFuIDI4Mjk1IGxvb3BzIG9mIDIwMzkgYnl0ZXMvbG9vcCB3aXRoIDAgZXJyb3JzCj4+
    IAo+PiAKPj4gU3RpbGwsIGFueSBoaW50IGFib3V0IHRoaXM/Cj4+IAo+PiBzaGVsbD4gbHNvZiAv ZGV2L2RhaGRpLzIKPj4gc2hlbGw+Cj4+IHNoZWxsPiBjaHJ0IC1mIDk5IHBhdGxvb3B0ZXN0IC9k ZXYvZGFoZGkvMiAtdCAzMDAgLXZ2dnZ2Cj4+IC9kZXYvZGFoZGkvMjogRGV2aWNlIG9yIHJlc291
    cmNlIGJ1c3kKPj4gCj4+IFRoYW5rcy4KPgo+QXN0ZXJpc2sgZG9lc24ndCBuZWNlc3NhcmlseSBo YXZlIHRvIG9wZW4gY2hhbm5lbHMgdmlhCj4vZGV2L2RhaGRpLzxjaGFubmVsIG51bWJlcj4uICBJ
    biBmYWN0LCB0aGV5IGdlbmVyYWxseSBvcGVuCj4vZGV2L2RhaGRpL2NoYW5uZWwgYW5kIHRoZW4g dXNlIHRoZSBTUEVDSUZZIGlvY3RsIHRvIGJpbmQgdGhhdAo+cGFydGljdWxhciBmaWxlIGRlc2Ny aXB0b3IgdG8gYSBzcGVjaWZpYyBkYWhkaSBjaGFubmVsLgo+Cj5TbyB0cnkgJ2xzb2YgL2Rldi9k YWhkaS9jaGFubmVsJyAgYW5kIHNlZSB3aGF0IHlvdSBzZWUuCj4KPkNoZWVycywKPlNoYXVuCj4K
    Pi0tIAo+U2hhdW4gUnVmZmVsbAo+RGlnaXVtLCBJbmMuIHwgTGludXggS2VybmVsIERldmVsb3Bl cgo+NDQ1IEphbiBEYXZpcyBEcml2ZSBOVyAtIEh1bnRzdmlsbGUsIEFMIDM1ODA2IC0gVVNBCj5D
    aGVjayB1cyBvdXQgYXQ6IHd3dy5kaWdpdW0uY29tICYgd3d3LmFzdGVyaXNrLm9yZwo+Cj4tLSAK
    Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+LS0gQmFuZHdpZHRoIGFuZCBDb2xvY2F0aW9uIFByb3ZpZGVkIGJ5IGh0
    dHA6Ly93d3cuYXBpLWRpZ2l0YWwuY29tIC0tCj5OZXcgdG8gQXN0ZXJpc2s/IEpvaW4gdXMgZm9y IGEgbGl2ZSBpbnRyb2R1Y3Rvcnkgd2ViaW5hciBldmVyeSBUaHVyczoKPiAgICAgICAgICAgICAg IGh0dHA6Ly93d3cuYXN0ZXJpc2sub3JnL2hlbGxvCj4KPmFzdGVyaXNrLXVzZXJzIG1haWxpbmcg bGlzdAo+VG8gVU5TVUJTQ1JJQkUgb3IgdXBkYXRlIG9wdGlvbnMgdmlzaXQ6Cj4gICBodHRwOi8v bGlzdHMuZGlnaXVtLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2FzdGVyaXNrLXVzZXJzCg=

  • No, I see this:

    shell> cat /proc/dahdi/2
    Span 2: TE2/0/2 “T2XXP (PCI) Card 0 Span 2” (MASTER) B8ZS/ESF LOOP
    CRC4 error count: 1
    E-bit error count: 1

    25 TE2/0/2/1 Clear Master LOOP
    26 TE2/0/2/2 Clear LOOP
    27 TE2/0/2/3 Clear LOOP
    28 TE2/0/2/4 Clear LOOP
    29 TE2/0/2/5 Clear LOOP
    30 TE2/0/2/6 Clear LOOP
    31 TE2/0/2/7 Clear LOOP
    32 TE2/0/2/8 Clear LOOP
    33 TE2/0/2/9 Clear LOOP
    34 TE2/0/2/10 Clear LOOP
    35 TE2/0/2/11 Clear LOOP
    36 TE2/0/2/12 Clear LOOP
    37 TE2/0/2/13 Clear LOOP
    38 TE2/0/2/14 Clear LOOP
    39 TE2/0/2/15 Clear LOOP
    40 TE2/0/2/16 Clear LOOP
    41 TE2/0/2/17 Clear LOOP
    42 TE2/0/2/18 Clear LOOP
    43 TE2/0/2/19 Clear LOOP
    44 TE2/0/2/20 Clear LOOP
    45 TE2/0/2/21 Clear LOOP
    46 TE2/0/2/22 Clear LOOP
    47 TE2/0/2/23 Clear LOOP
    48 TE2/0/2/24 Clear LOOP

    shell> cat /proc/dahdi/1
    Span 1: TE2/0/1 “T2XXP (PCI) Card 0 Span 1” B8ZS/ESF LOOP

    1 TE2/0/1/1 Clear Master RED
    2 TE2/0/1/2 Clear RED
    3 TE2/0/1/3 Clear RED
    4 TE2/0/1/4 Clear RED
    5 TE2/0/1/5 Clear RED
    6 TE2/0/1/6 Clear RED
    7 TE2/0/1/7 Clear RED
    8 TE2/0/1/8 Clear RED
    9 TE2/0/1/9 Clear RED
    10 TE2/0/1/10 Clear RED
    11 TE2/0/1/11 Clear RED
    12 TE2/0/1/12 Clear RED
    13 TE2/0/1/13 Clear RED
    14 TE2/0/1/14 Clear RED
    15 TE2/0/1/15 Clear RED
    16 TE2/0/1/16 Clear RED
    17 TE2/0/1/17 Clear RED
    18 TE2/0/1/18 Clear RED
    19 TE2/0/1/19 Clear RED
    20 TE2/0/1/20 Clear RED
    21 TE2/0/1/21 Clear RED
    22 TE2/0/1/22 Clear RED
    23 TE2/0/1/23 Clear RED
    24 TE2/0/1/24 Clear RED

  • [snip]

    That explains it. Your channels are bound together in one clear channel on span 1. When configured this way, you can only open the
    “master” channels. All the data from the other channels (timeslots)
    are then added to this master channel.

  • Shaun, sorry to insist on this, but this kind of diagnostic is new for me and extremely valuable for my support operations.

    You say “when configured this way”.. do you mean regarding dahdi? Here’s my system conf, based on your KB article for loop testing:

    shell> cat system.conf loadzone=us defaultzone=us span=1,0,0,esf,b8zs clear=1-24
    span=2,0,0,esf,b8zs clear%-48

    How could I configure now so I can get conclusive readings for span2?

    Thanks.

  • No problem. So given the above configuration, there are only two channels that can be opened from user space, channels 1 and 25.

    So if you would like to keep things configured this way and check span 2, you would then just run patlooptest on channel 25.

    If you want to run patlooptest on individual channels in the span, configure like a PRI is normally:

    loadzone=us defaultzone=us span=1,0,0,esf,b8zs bchan=1-23
    dchan$
    span=2,0,0,esf,b8zs bchan%-47
    dchanH

    Then you will be able to run patlooptest on all channels expcept 24
    and 48 (which now have HDLC framing enabled on them).

  • Got it! It’s working fine with 25. Actually, I just revisited your KB
    article and it does clearly instruct to test 1, 25, and so forth… But I
    was still thinking spans, not channels. So my apologies for this RTFM
    moment.

    Thanks!