openadsl-users — openadsl users list

Re: [openadsl-users] modprobe hangs on solos_pci insert

[Jim C. <jam...@gm...>]

This is a generic cctv pci card that I am hoping to use with a zoneminder
install.  To be honest, I'd never heard of ATM before last week.  :-)

I ended up here as a result of using lspci to detect what the actual card
was capable of:

01:06.0 Multimedia controller: Xilinx Corporation Spartan 3 Designs (Xilinx
IP)
Subsystem: Xilinx Corporation Spartan 3 Designs (Xilinx IP)
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-
Latency: 64 (250ns min, 63750ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at dc00 [size=16]
Region 1: Memory at fcf00000 (32-bit, non-prefetchable) [size=1M]
Kernel modules: solos_pci


This is way out of my area of expertise.  Any advice, including that I am
wasting my time in this endeavor would be appreciated.  Thank you for your
time.

-Jim



>Hi Jim,
>
>The solos_pci driver is for a specific Xilinx configuration, it is not
>generic.
>There are several registers that the driver expects to reside in the
>Xilinx, but they seem to be missing in your case.
>
>Is this your own Xilinx design?
>What is it that you are trying to build - an ATM card or something else?
>
>Regards,
>  - Guy.

Re: [openadsl-users] modprobe hangs on solos_pci insert

[Guy E. <gu...@tr...>]

Hi Jim,

The solos_pci driver is for a specific Xilinx configuration, it is not 
generic.
There are several registers that the driver expects to reside in the 
Xilinx, but they seem to be missing in your case.

Is this your own Xilinx design?
What is it that you are trying to build - an ATM card or something else?

Regards,
  - Guy.


On 21/04/2014 12:09 AM, Jim Cox wrote:
> Hello, I am trying to use the solos-pci driver on a "Multimedia 
> controller: Xilinx Corporation Spartan 3 Designs (Xilinx IP)".  I 
> re-compiled my 3.12.13 kernel with the options as outlined in the 
> solos pci README and the atm howto.
>
> When I restarted, the boot process would just hang on udev 
> initialization.  Using a rescue cd, I blacklisted the solos and atm 
> modules and restarted.  I then did a successful modprobe on the atm 
> module.  When I ran 'modprobe solos_pci', the command never returns, 
> it hangs in the terminal.  In another terminal window I can run dmesg 
> and see:
>
>
> [54828.407474] Solos PCI Driver Version 1.04
> [54828.407753] pci 0000:00:08.0: setting latency timer to 64
> [54828.407985] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 17
> [54828.408033] solos 0000:01:06.0: Solos FPGA Version 255.255 svn-65535
> [54828.408150] solos 0000:01:06.0: Registered ATM device 0
> [54828.408200] solos 0000:01:06.0: Registered ATM device 1
> [54828.408260] solos 0000:01:06.0: Registered ATM device 2
> [54828.408314] solos 0000:01:06.0: Registered ATM device 3
> [54828.408365] solos 0000:01:06.0: Registered ATM device 4
> [54828.408409] solos 0000:01:06.0: Registered ATM device 5
> [54828.408452] solos 0000:01:06.0: Registered ATM device 6
> [54828.408498] solos 0000:01:06.0: Registered ATM device 7
> [54828.408544] solos 0000:01:06.0: Registered ATM device 8
> [54828.408601] solos 0000:01:06.0: Registered ATM device 9
>
>
> I'm assuming that when udev tries to load the solos module, it's 
> hanging for whatever reason it hangs when I load it manually.  Any 
> advice on how to prevent the hang on modprobe?
>
> Thanks,
> Jim
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
>
>
> _______________________________________________
> openadsl-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openadsl-users


-- 
Guy Ellis
gu...@tr...
www.traverse.com.au
T: +61 3 9386 4435 M: +61 419 398 234

[openadsl-users] modprobe hangs on solos_pci insert

[Jim C. <jam...@gm...>]

Hello, I am trying to use the solos-pci driver on a "Multimedia controller:
Xilinx Corporation Spartan 3 Designs (Xilinx IP)".  I re-compiled my
3.12.13 kernel with the options as outlined in the solos pci README and the
atm howto.

When I restarted, the boot process would just hang on udev initialization.
 Using a rescue cd, I blacklisted the solos and atm modules and restarted.
 I then did a successful modprobe on the atm module.  When I ran 'modprobe
solos_pci', the command never returns, it hangs in the terminal.  In
another terminal window I can run dmesg and see:


[54828.407474] Solos PCI Driver Version 1.04
[54828.407753] pci 0000:00:08.0: setting latency timer to 64
[54828.407985] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 17
[54828.408033] solos 0000:01:06.0: Solos FPGA Version 255.255 svn-65535
[54828.408150] solos 0000:01:06.0: Registered ATM device 0
[54828.408200] solos 0000:01:06.0: Registered ATM device 1
[54828.408260] solos 0000:01:06.0: Registered ATM device 2
[54828.408314] solos 0000:01:06.0: Registered ATM device 3
[54828.408365] solos 0000:01:06.0: Registered ATM device 4
[54828.408409] solos 0000:01:06.0: Registered ATM device 5
[54828.408452] solos 0000:01:06.0: Registered ATM device 6
[54828.408498] solos 0000:01:06.0: Registered ATM device 7
[54828.408544] solos 0000:01:06.0: Registered ATM device 8
[54828.408601] solos 0000:01:06.0: Registered ATM device 9


I'm assuming that when udev tries to load the solos module, it's hanging
for whatever reason it hangs when I load it manually.  Any advice on how to
prevent the hang on modprobe?

Thanks,
Jim

Re: [openadsl-users] Fwd: Solos Firmware 1.16

[Niccolò B. <nic...@li...>]

Hi,
Any news on the solos pci backport or on the OpenWRT AA fix?

Niccolò

Re: [openadsl-users] Fwd: Solos Firmware 1.16

[Niccolò B. <dar...@li...>]

Il 10.06.2013 02:16 Guy Ellis ha scritto:
> Just to be 100% sure, check the DSP version on the 1.11 you are 
> using...
>
> soloscli -g 0 FirmwareVersion
>
> It sould be E21.45.66, same for 1.16


It is "E.25.41.66   A" on both 1.16 and 1.11. I did another 36 hours 
run with 1.16 with zero sinc losses, so I confirm I have less 
disconnections with 1.16. I tested both 1.11 and 1.16 *twice*.

There is a possible explanation: maybe solos does not report sync 
losses correctly?

In fact, even if today I didn't log a single down with 1.16, when I 
check dmesg here is the output:

root@OpenWrt:~# dmesg | grep solos | grep "Port 0"
[   29.035314] solos 0000:00:0c.0: Port 0: Training
[   35.135572] solos 0000:00:0c.0: Port 0: Showtime @12285/1020 kb/s, 
SNR 8.35 dB, Attn 35.0 dB
[27680.348609] solos 0000:00:0c.0: Port 0: Showtime @0/1020 kb/s, SNR 
8.35 dB, Attn 35.0 dB
[27686.402171] solos 0000:00:0c.0: Port 0: Showtime @12285/1020 kb/s, 
SNR 8.35 dB, Attn 35.0 dB
[29660.061732] solos 0000:00:0c.0: Port 0: Showtime @12285/1020 kb/s, 
SNR 9.80 dB, Attn 35.0 dB
[29832.689726] solos 0000:00:0c.0: Port 0: Showtime @12285/1020 kb/s, 
SNR 8.35 dB, Attn 35.0 dB

What does it mean? I do check line status with a "fping -B 1.5 -r 5" 
every second and I can assure you there were no downs.
Maybe some of the 1.11 downs are "fake" sync losses?

I will call my ISP and ask them to unlock the full potential of the 
line (24Mb/1.5Mb), it will be much easier to check if something is wrong 
with a 6dB SNR. I will also receive the XAVI 7968 (which has a Solos 
chipset) in a few days to make a comparison.
Hopefully Nathan will fix the issue with OpenWRT AA in the meantime so 
I will be able to make a second test @12dB.

Niccolò

Re: [openadsl-users] Fwd: Solos Firmware 1.16

[Guy E. <gu...@tr...>]

Just to be 100% sure, check the DSP version on the 1.11 you are using...

soloscli -g 0 FirmwareVersion

It sould be E21.45.66, same for 1.16

- G.

On 10/06/2013 6:04 AM, Niccolò Belli wrote:
> Il 07.06.2013 16:52 Niccolò Belli ha scritto:
>> Il 07.06.2013 10:52 Guy Ellis ha scritto:
>>> There is a minor DSP fix in 1.11 and later, perhaps you were using
>>> 1.10?
>> No, I'm sure it was 1.11.
>>
>>> Or maybe your sync loss events are dependant on something else?
>>> The weather perhaps - rain water in a cable pit?
>> The weather was good, anyway I will flash 1.11 once again to double
>> check.
>> So far 76 hours had passed with a single down (with 1.16).
> Hi Guy,
> I flashed 1.11 once again: three sync loss downs in 36 hours. No rain.
>
> Sat Jun  8 02:04:20 UTC 2013 down (sync loss)
> Sat Jun  8 10:01:26 UTC 2013 down (LCP)
> Sat Jun  8 11:22:38 UTC 2013 down (sync loss)
> Sun Jun  9 07:34:08 UTC 2013 down (sync loss)
>
> I will test 1.16 once again, if it's stable then there is definitely
> something which improved line stability.
>
> Niccolò
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> openadsl-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openadsl-users


-- 
Guy Ellis
gu...@tr...
www.traverse.com.au
T: +61 3 9386 4430 M: +61 419 398 234

Re: [openadsl-users] Fwd: Solos Firmware 1.16

[Niccolò B. <dar...@li...>]

Il 07.06.2013 16:52 Niccolò Belli ha scritto:
> Il 07.06.2013 10:52 Guy Ellis ha scritto:
>> There is a minor DSP fix in 1.11 and later, perhaps you were using
>> 1.10?
>
> No, I'm sure it was 1.11.
>
>> Or maybe your sync loss events are dependant on something else?
>> The weather perhaps - rain water in a cable pit?
>
> The weather was good, anyway I will flash 1.11 once again to double
> check.
> So far 76 hours had passed with a single down (with 1.16).

Hi Guy,
I flashed 1.11 once again: three sync loss downs in 36 hours. No rain.

Sat Jun  8 02:04:20 UTC 2013 down (sync loss)
Sat Jun  8 10:01:26 UTC 2013 down (LCP)
Sat Jun  8 11:22:38 UTC 2013 down (sync loss)
Sun Jun  9 07:34:08 UTC 2013 down (sync loss)

I will test 1.16 once again, if it's stable then there is definitely 
something which improved line stability.

Niccolò

Re: [openadsl-users] Fwd: Solos Firmware 1.16

[Niccolò B. <dar...@li...>]

Il 07.06.2013 10:52 Guy Ellis ha scritto:
> There is a minor DSP fix in 1.11 and later, perhaps you were using 
> 1.10?

No, I'm sure it was 1.11.

> Or maybe your sync loss events are dependant on something else?
> The weather perhaps - rain water in a cable pit?

The weather was good, anyway I will flash 1.11 once again to double 
check.
So far 76 hours had passed with a single down (with 1.16).

Niccolò

Re: [openadsl-users] Fwd: Solos Firmware 1.16

[Guy E. <gu...@tr...>]

Hi Nicollo,

Glad to hear that 1.16 works well for you and fixes the LCP issues.

There is a minor DSP fix in 1.11 and later, perhaps you were using 1.10?
Or maybe your sync loss events are dependant on something else?
The weather perhaps - rain water in a cable pit?

Nathan is still working on a driver fix for OpenWRT AA.

Cheers,
  - Guy

On 6/06/2013 11:15 PM, Niccolò Belli wrote:
> Il 04/06/2013 12:48, Guy Ellis ha scritto:
>> Hi Niccolo,
>>
>> Yes I'm afraid you are right.
>> I'll get Nathan to look into this further tomorrow.
>>
>> Regards,
>>    - Guy.
> Hi Guy,
> It seems 1.16 does miracles on Geos :)
> It hangs while trying to set a custom SNR of course, but there are no
> more random reboots!
> Also I already did 50 hours of monitoring and I experienced no more
> LCP/timeout downs and just *a single* sync-loss down with 8dB SNR (with
> 1.11 I had a sync loss every 6 hours and it was with a *12dB* SNR!).
> What are the improvements of 1.16 over the old 1.11? How do you explain
> such a lower sync loss rate? Of course you fixed the LCP issue, but I
> didn't expect sync loss improvements!
>
> P.S.
> Did Nathan manage to fix the reboot issue while setting a custom SNR?
>
> Niccolò
>


-- 
Guy Ellis
gu...@tr...
www.traverse.com.au
T: +61 3 9386 4430 M: +61 419 398 234

Re: [openadsl-users] Fwd: Solos Firmware 1.16

[Niccolò B. <dar...@li...>]

Il 04/06/2013 12:48, Guy Ellis ha scritto:
> Hi Niccolo,
>
> Yes I'm afraid you are right.
> I'll get Nathan to look into this further tomorrow.
>
> Regards,
>   - Guy.

Hi Guy,
It seems 1.16 does miracles on Geos :)
It hangs while trying to set a custom SNR of course, but there are no 
more random reboots!
Also I already did 50 hours of monitoring and I experienced no more 
LCP/timeout downs and just *a single* sync-loss down with 8dB SNR (with 
1.11 I had a sync loss every 6 hours and it was with a *12dB* SNR!).
What are the improvements of 1.16 over the old 1.11? How do you explain 
such a lower sync loss rate? Of course you fixed the LCP issue, but I 
didn't expect sync loss improvements!

P.S.
Did Nathan manage to fix the reboot issue while setting a custom SNR?

Niccolò

-- 
http://www.linuxsystems.it

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Niccolò B. <dar...@li...>]

Il 03/06/2013 12:25, Guy Ellis ha scritto:
> As for the LCP termination / timeouts, we have a fix for that with Geos
> hardware & OpenWRT Backfire.
> We'll try and port this across to Solos hardware in the next few days.

Awesome, thank you very much Guy :)


> As for the sync loss events, please try a different modem and let me
> know the results.

I already bought a XAVI 7968 with Conexant Solos chipset (CX94610) from 
Spain. It will take a few days to arrive, I will let you know.

Niccolò

-- 
http://www.linuxsystems.it

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Guy E. <gu...@tr...>]

Hi Niccolo,

As for the LCP termination / timeouts, we have a fix for that with Geos 
hardware & OpenWRT Backfire.
We'll try and port this across to Solos hardware in the next few days.

As for the sync loss events, please try a different modem and let me 
know the results.

Regards,
  - Guy.

On 3/06/2013 7:48 PM, Niccolò Belli wrote:
> I accumulated lots of debug infos as you asked. I monitored the line 
> for 36 hours and I recorded 9 downs (a down every 4 hours), 6 of them 
> because of sync loss. Concerning the remaining 3 downs, 2 of them 
> because of "LCP terminated by peer". The last one because of "No 
> response to 5 echo-requests".
>
> I attached the logs.
>
> Also, I put on pastebin 24 hours of
>
> RSCorrectedErrorsDn
> RSCorrectedErrorsUp
> RSUnCorrectedErrorsDn
> RSUnCorrectedErrorsUp
>
> every 5 minutes on both Geos and Solos PCI (with my second line 
> attached) as you asked. There were no downs in the line attached to 
> Solos PCI (which uses RFC 2684 routed instead of PPPoATM).
>
> http://pastebin.com/V3XEcZHN
> http://pastebin.com/0dMDZsr9
>
> Soon I will let you know if the line attached to Geos is stable with 
> another router.
>
> Niccolò
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
>
>
> _______________________________________________
> openadsl-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openadsl-users


-- 
Guy Ellis
gu...@tr...
www.traverse.com.au
T: +61 3 9386 4430 M: +61 419 398 234

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Niccolò B. <dar...@li...>]

I accumulated lots of debug infos as you asked. I monitored the line 
for 36 hours and I recorded 9 downs (a down every 4 hours), 6 of them 
because of sync loss. Concerning the remaining 3 downs, 2 of them 
because of "LCP terminated by peer". The last one because of "No 
response to 5 echo-requests".

I attached the logs.

Also, I put on pastebin 24 hours of

RSCorrectedErrorsDn
RSCorrectedErrorsUp
RSUnCorrectedErrorsDn
RSUnCorrectedErrorsUp

every 5 minutes on both Geos and Solos PCI (with my second line 
attached) as you asked. There were no downs in the line attached to 
Solos PCI (which uses RFC 2684 routed instead of PPPoATM).

http://pastebin.com/V3XEcZHN
http://pastebin.com/0dMDZsr9

Soon I will let you know if the line attached to Geos is stable with 
another router.

Niccolò

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Niccolò B. <dar...@li...>]

Il 01.06.2013 09:46 Guy Ellis ha scritto:
> Ok, so I assume PPP went down?
>
> If so, we need to see the PPP logs.
> Was it caused by an LCP timeout?
> Was there a lot of traffic at the time?

There is always traffic, I'm generating traffic 24/7 to test line 
stability.
I'm monitoring pppd too now, in the meantime I got another down with 
sync loss:

Sat Jun  1 14:24:42 UTC 2013 down
Sat Jun  1 14:25:21 UTC 2013 up

[12208.606911] solos 0000:00:0c.0: Port 0: HandShake
[12218.665970] solos 0000:00:0c.0: Bad status packet of 19 bytes on 
port 0:
[12218.672797] 00: 31 00 30 00 30 00 48 61
[12218.672826] 08: 6E 64 53 68 61 6B 65 00
[12218.672845] 10: 30 0A 30
[12218.672854]
[12228.735035] solos 0000:00:0c.0: Port 0: Showtime @9981/1020 kb/s, 
SNR 12.75 dB, Attn 34.5 dB

Sat Jun  1 14:14:46 UTC 2013
3307557
0
1408
1

Sat Jun  1 14:19:46 UTC 2013
3674529
0
1500
1

Sat Jun  1 14:24:46 UTC 2013
0
0
0
0

No response to 5 echo-requests
Serial link appears to be disconnected.
Connect time 180.0 minutes.
Sent 1002875091 bytes, received 399822836 bytes.
Script /lib/netifd/ppp-down started (pid 26889)
sent [LCP TermReq id=0x1b "Peer not responding"]
Script /lib/netifd/ppp-down finished (pid 26889), status = 0x1
sent [LCP TermReq id=0x1c "Peer not responding"]
Connection terminated.
Modem hangup
using channel 8
Using interface pppoa-wan0
Connect: pppoa-wan0 <--> 0.8.35
sent [LCP ConfReq id=0x1d <magic 0x405a1644>]
rcvd [LCP ConfAck id=0x1d <magic 0x405a1644>]
rcvd [LCP ConfReq id=0x2 <mru 1492> <auth chap MD5> <magic 0xaa015ea4>]
sent [LCP ConfAck id=0x2 <mru 1492> <auth chap MD5> <magic 0xaa015ea4>]
sent [LCP EchoReq id=0x0 magic=0x405a1644]
rcvd [CHAP Challenge id=0x1 <33f35197e275003e1f2f59d781c6780d>, name = 
"c72g1.ane-atm1"]
sent [CHAP Response id=0x1 <f45afd7dc8bda1d14aa81513c9e24b34>, name = 
"username"]
rcvd [LCP EchoRep id=0x0 magic=0xaa015ea4]
rcvd [LCP ConfReq id=0x1 <mru 1492> <auth chap MD5> <magic 0x67cdb779> 
<mrru 1524> <endpoint 13 0c 01 6d 6d 70 70 70 5f 6c 6e 73>]
sent [LCP ConfReq id=0x1e <magic 0x955891f>]
sent [LCP ConfRej id=0x1 <mrru 1524>]
rcvd [LCP ConfAck id=0x1e <magic 0x955891f>]
rcvd [LCP ConfReq id=0x2 <mru 1492> <auth chap MD5> <magic 0x67cdb779> 
<endpoint 13 0c 01 6d 6d 70 70 70 5f 6c 6e 73>]
sent [LCP ConfAck id=0x2 <mru 1492> <auth chap MD5> <magic 0x67cdb779> 
<endpoint 13 0c 01 6d 6d 70 70 70 5f 6c 6e 73>]
sent [LCP EchoReq id=0x0 magic=0x955891f]
rcvd [CHAP Challenge id=0x2 <77e84daf8ab3c7ffded9912b41c7582d>, name = 
"mmppp_lns"]
sent [CHAP Response id=0x2 <11d939b6f90a02dccd12ac227adc663e>, name = 
"username"]
rcvd [CHAP Success id=0x2 "Successful login"]
CHAP authentication succeeded: Successful login
CHAP authentication succeeded
sent [IPCP ConfReq id=0x16 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 
0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <addr <REMOTE_IP>>]
sent [IPCP ConfAck id=0x1 <addr <REMOTE_IP>>]
rcvd [IPCP ConfRej id=0x16 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x17 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 
0.0.0.0>]
rcvd [IPCP ConfNak id=0x17 <addr <IP>> <ms-dns1 213.205.32.70> <ms-dns2 
213.205.36.70>]
sent [IPCP ConfReq id=0x18 <addr <IP>> <ms-dns1 213.205.32.70> <ms-dns2 
213.205.36.70>]
rcvd [IPCP ConfAck id=0x18 <addr <IP>> <ms-dns1 213.205.32.70> <ms-dns2 
213.205.36.70>]
local  IP address <IP>
remote IP address <REMOTE_IP>
primary   DNS address 213.205.32.70
secondary DNS address 213.205.36.70
Script /lib/netifd/ppp-up started (pid 27084)
Script /lib/netifd/ppp-up finished (pid 27084), status = 0x1




I enabled debug in pppd options.
Tomorrow I will use another router to check if the line is stable with 
it.

Niccolò

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Guy E. <gu...@tr...>]

Ok, so I assume PPP went down?

If so, we need to see the PPP logs.
Was it caused by an LCP timeout?
Was there a lot of traffic at the time?

Regards,
  - Guy.

On 31/05/2013 10:59 PM, Niccolò Belli wrote:
> I just got the first down on Geos, but *without* sync loss.
>
> Fri May 31 12:47:54 UTC 2013 down
> Fri May 31 12:48:37 UTC 2013 up (no sync loss)
>
> Fri May 31 12:43:02 UTC 2013
> 2249978
> 0
> 161
> 1
>
> Fri May 31 12:48:02 UTC 2013
> 2249978
> 0
> 161
> 1
>
> Fri May 31 12:53:02 UTC 2013
> 2250006
> 0
> 161
> 1
>
>
> As you can see there were no errors in the 5 minutes before the down.
>
> Niccolò
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> openadsl-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openadsl-users


-- 
Guy Ellis
gu...@tr...
www.traverse.com.au
T: +61 3 9386 4430 M: +61 419 398 234

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Niccolò B. <dar...@li...>]

I just got the first down on Geos, but *without* sync loss.

Fri May 31 12:47:54 UTC 2013 down
Fri May 31 12:48:37 UTC 2013 up (no sync loss)

Fri May 31 12:43:02 UTC 2013
2249978
0
161
1

Fri May 31 12:48:02 UTC 2013
2249978
0
161
1

Fri May 31 12:53:02 UTC 2013
2250006
0
161
1


As you can see there were no errors in the 5 minutes before the down.

Niccolò

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Niccolò B. <dar...@li...>]

Il 31.05.2013 12:30 Guy Ellis ha scritto:
> there was a typo in my previous email, and we can't see the
> UnCorrected ounters, it should have read...
>
> RSCorrectedErrorsDn
> RSCorrectedErrorsUp
> RSUnCorrectedErrorsDn
> RSUnCorrectedErrorsUp

Fixed.


> So we are seeing bursts of errors on this line.
> If at any point the errors / minute exceeds a threshold the port will
> retrain.
>
> Do you get errors on both lines?
> Maybe you can change your script to show log both lines?

I cannot use Geos for the other line, I have a 2000+ lines of code 
firewall in my server so I have to use Solos PCI. I'm using Geos on the 
less important link just as test but I will have to switch back to Solos 
once we fix the unresponsive ppp bug.
Anyway I made a second script on my server to show the line status.

This is the line attached to the Geos (PPPoATM, 12dB SNR, not stable):

root@OpenWrt:~# tail -f line_debug.txt
Fri May 31 11:03:00 UTC 2013
2248210
0
150
1

Fri May 31 11:08:00 UTC 2013
2248217
0
150
1

Fri May 31 11:13:00 UTC 2013
2248217
0
150
1

Fri May 31 11:18:00 UTC 2013
2248278
0
151
1

Fri May 31 11:23:01 UTC 2013
2248278
0
151
1

Fri May 31 11:28:01 UTC 2013
2248278
0
151
1

Fri May 31 11:33:01 UTC 2013
2248279
0
151
1

Fri May 31 11:38:01 UTC 2013
2248314
0
152
1

Fri May 31 11:43:01 UTC 2013
2248342
0
152
1

Fri May 31 11:48:01 UTC 2013
2248342
0
152
1

Fri May 31 11:53:01 UTC 2013
2248347
0
152
1

Fri May 31 11:58:01 UTC 2013
2248390
0
152
1





This is the line attached to the server with Solos PCI (RFC 2684 
routed, 12dB SNR, perfectly stable with less than 1 down per month):

root@firewall:~# tail -f line_debug.txt
ven 31 mag 2013, 13.04.56, CEST
29081091
709
8338
36

ven 31 mag 2013, 13.09.56, CEST
29081093
709
8338
36

ven 31 mag 2013, 13.14.56, CEST
29081140
709
8340
36

ven 31 mag 2013, 13.19.56, CEST
29081162
709
8340
36

ven 31 mag 2013, 13.24.56, CEST
29081163
709
8340
36

ven 31 mag 2013, 13.29.56, CEST
29081164
709
8340
36

ven 31 mag 2013, 13.34.56, CEST
29081183
709
8340
36

ven 31 mag 2013, 13.39.56, CEST
29081226
709
8340
36

ven 31 mag 2013, 13.44.56, CEST
29081228
709
8340
36

ven 31 mag 2013, 13.49.56, CEST
29081228
709
8340
36

ven 31 mag 2013, 13.54.56, CEST
29081229
709
8340
36

ven 31 mag 2013, 13.59.56, CEST
29081289
709
8342
36

ven 31 mag 2013, 14.04.56, CEST
29081302
709
8342
36



> FYI, I'm not exepecting to fix your problem here, just make 100% sure
> it is a line problem.

I agree, if the problem isn't the modem there is nothing you can do. 
Anyway I wouldn't bet the line is faulty, I will try with another modem 
to see if it's stable.

Niccolò

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Guy E. <gu...@tr...>]

Hi Niccolo,

So we are seeing bursts of errors on this line.
If at any point the errors / minute exceeds a threshold the port will retrain.

Do you get errors on both lines?
Maybe you can change your script to show log both lines?

Also there was a typo in my previous email, and we can't see the 
UnCorrected ounters, it should have read...

RSCorrectedErrorsDn
RSCorrectedErrorsUp
RSUnCorrectedErrorsDn
RSUnCorrectedErrorsUp

FYI, I'm not exepecting to fix your problem here, just make 100% sure it is a line problem.
Of course your ISP will deny the issue, that is standard behaviour.
If you can repeat the problem with two or modems/ports then you have a better chance of getting them to do something about it.
Please note that physical line faults, even if they are intermittent, cannot be fixed by increasing the SNR.

Regards,
  - Guy.






On 31/05/2013 6:54 PM, Niccolò Belli wrote:
> Il 31.05.2013 02:24 Guy Ellis ha scritto:
>> - Monitor line errors* every 5 minutes for 24 hours - is there some
>> sort
>> of a pattern, or particular time of day, or event such as rain / wind
>> that is problematic?
> No, there is no special pattern/time/weather condition.
>
>> *To do this read the following parameters once every 5 minutes and
>> echo
>> to a log file...
>> RSCorrectedErrorsDn
>> RSCorrectedErrorsUp
>> RSUncorrectedErrorsDn
>> RSUncorrectedErrorsUp
> Here are some preliminar results, I will post full log along with the
> downs in 24 hours.
>
> Fri May 31 08:05:12 UTC 2013
> 2245572
> 0
> ERROR
> ERROR
>
> Fri May 31 08:10:12 UTC 2013
> 2245572
> 0
> ERROR
> ERROR
>
> Fri May 31 08:15:12 UTC 2013
> 2245629
> 0
> ERROR
> ERROR
>
> Fri May 31 08:20:12 UTC 2013
> 2245719
> 0
> ERROR
> ERROR
>
> Fri May 31 08:25:12 UTC 2013
> 2245720
> 0
> ERROR
> ERROR
>
> Fri May 31 08:30:12 UTC 2013
> 2245760
> 0
> ERROR
> ERROR
>
> Fri May 31 08:35:13 UTC 2013
> 2245762
> 0
> ERROR
> ERROR
>
> Fri May 31 08:40:13 UTC 2013
> 2245762
> 0
> ERROR
> ERROR
>
> Fri May 31 08:45:13 UTC 2013
> 2245832
> 0
> ERROR
> ERROR
>
>
>
>> - Are you absolutely sure there are no unfiltered devices on the line
>> in
>> question - I've seen it all, telephones, fax machines even an alarm
>> system (in the roof!) cause this problem.
> Yes, I made a new wiring two years ago. Also the line is data only,
> there is no voice (that means I don't even use a filter).
>
>> - It's possible that line is faulty - if the line has an intermittent
>> open/short connection it doesn't matter how high you set the SNR, you
>> will always lose sync during brief fault conditions.
> I asked my ISP to check many times and they always told me everything
> is fine, I even replaced the twisted pair coming from the outside of the
> building two years ago.
>
>
>> - If you swap the line in question onto port 1 do you still have the
>> same problem?
> I will check after 24 hours of parameters monitoring, but I fear it
> will not help.
>
> Niccolò
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> openadsl-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openadsl-users


-- 
Guy Ellis
gu...@tr...
www.traverse.com.au
T: +61 3 9386 4430 M: +61 419 398 234

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Niccolò B. <dar...@li...>]

Il 31.05.2013 02:24 Guy Ellis ha scritto:
> - Monitor line errors* every 5 minutes for 24 hours - is there some 
> sort
> of a pattern, or particular time of day, or event such as rain / wind
> that is problematic?

No, there is no special pattern/time/weather condition.

> *To do this read the following parameters once every 5 minutes and 
> echo
> to a log file...
> RSCorrectedErrorsDn
> RSCorrectedErrorsUp
> RSUncorrectedErrorsDn
> RSUncorrectedErrorsUp

Here are some preliminar results, I will post full log along with the 
downs in 24 hours.

Fri May 31 08:05:12 UTC 2013
2245572
0
ERROR
ERROR

Fri May 31 08:10:12 UTC 2013
2245572
0
ERROR
ERROR

Fri May 31 08:15:12 UTC 2013
2245629
0
ERROR
ERROR

Fri May 31 08:20:12 UTC 2013
2245719
0
ERROR
ERROR

Fri May 31 08:25:12 UTC 2013
2245720
0
ERROR
ERROR

Fri May 31 08:30:12 UTC 2013
2245760
0
ERROR
ERROR

Fri May 31 08:35:13 UTC 2013
2245762
0
ERROR
ERROR

Fri May 31 08:40:13 UTC 2013
2245762
0
ERROR
ERROR

Fri May 31 08:45:13 UTC 2013
2245832
0
ERROR
ERROR



> - Are you absolutely sure there are no unfiltered devices on the line 
> in
> question - I've seen it all, telephones, fax machines even an alarm
> system (in the roof!) cause this problem.

Yes, I made a new wiring two years ago. Also the line is data only, 
there is no voice (that means I don't even use a filter).

> - It's possible that line is faulty - if the line has an intermittent
> open/short connection it doesn't matter how high you set the SNR, you
> will always lose sync during brief fault conditions.

I asked my ISP to check many times and they always told me everything 
is fine, I even replaced the twisted pair coming from the outside of the 
building two years ago.


> - If you swap the line in question onto port 1 do you still have the
> same problem?

I will check after 24 hours of parameters monitoring, but I fear it 
will not help.

Niccolò

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Guy E. <gu...@tr...>]

Might be worth trying firmware v1.11 ?

On 31/05/2013 1:31 PM, Steve Dommett wrote:
>
> On Fri, 31 May 2013, 03:51:15 BST, Guy Ellis <gu...@tr... 
> <mailto:gu...@tr...>> wrote:
> > Are you seeing ppp disconnects or sync loss?
>
> Loss of sync.
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
>
>
> _______________________________________________
> openadsl-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openadsl-users


-- 
Guy Ellis
gu...@tr...
www.traverse.com.au
T: +61 3 9386 4430 M: +61 419 398 234

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Steve D. <st...@st...>]

On Fri, 31 May 2013, 03:51:15 BST, Guy Ellis <gu...@tr...> wrote:
> Are you seeing ppp disconnects or sync loss?

Loss of sync.

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Guy E. <gu...@tr...>]

Hi Steve,

Are you seeing ppp disconnects or sync loss?

- Guy.

On 31/05/2013 12:31 PM, Steve Dommett wrote:
> On 31/05/2013 01:24, Guy Ellis wrote:
>   > *To do this read the following parameters once every 5 minutes and echo
>   > to a log file...
>   > RSCorrectedErrorsDn
>   > RSCorrectedErrorsUp
>   > RSUncorrectedErrorsDn
>   > RSUncorrectedErrorsUp
>
> If you use Munin, you might also try this (sorry, the multi-port code is
> unfinished,  and possibly ill conceived):
> https://github.com/sutaburosu/adsl_solos_pci
>
> Here's a graph showing when my line was genuinely faulty:
> http://st4vs.net/adsl_throughput_solos_pci_0-year.png
>
> With 14db SNR,  I still regularly see disconnects when the downstream
> and/or upstream are saturated.  The Reed-Solomon counters confirm the
> line is performing adequately at those moments.
>
> Still on firmware 1.07 here,  but the OP's reported symptoms match when
> my disconnections happen.
>
> I don't get any of the "Bad status packet of 20 bytes on port 0", but I
> do sometimes see
>   > solos 0000:04:06.0: Received packet for unknown VPI.VCI 0.0 on port 0
>
> HTH,
>     Steve
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> openadsl-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openadsl-users
>


-- 
Guy Ellis
gu...@tr...
www.traverse.com.au
T: +61 3 9386 4430 M: +61 419 398 234

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Steve D. <st...@st...>]

On 31/05/2013 01:24, Guy Ellis wrote:
 > *To do this read the following parameters once every 5 minutes and echo
 > to a log file...
 > RSCorrectedErrorsDn
 > RSCorrectedErrorsUp
 > RSUncorrectedErrorsDn
 > RSUncorrectedErrorsUp

If you use Munin, you might also try this (sorry, the multi-port code is 
unfinished,  and possibly ill conceived):
https://github.com/sutaburosu/adsl_solos_pci

Here's a graph showing when my line was genuinely faulty: 
http://st4vs.net/adsl_throughput_solos_pci_0-year.png

With 14db SNR,  I still regularly see disconnects when the downstream 
and/or upstream are saturated.  The Reed-Solomon counters confirm the 
line is performing adequately at those moments.

Still on firmware 1.07 here,  but the OP's reported symptoms match when 
my disconnections happen.

I don't get any of the "Bad status packet of 20 bytes on port 0", but I 
do sometimes see
 > solos 0000:04:06.0: Received packet for unknown VPI.VCI 0.0 on port 0

HTH,
   Steve

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Guy E. <gu...@tr...>]

Hi Niccolo,

12dB SNR should give you a very stable connection.
Ideas...

- If you swap the line in question onto port 1 do you still have the 
same problem?
- Monitor line errors* every 5 minutes for 24 hours - is there some sort 
of a pattern, or particular time of day, or event such as rain / wind 
that is problematic?
- Are you absolutely sure there are no unfiltered devices on the line in 
question - I've seen it all, telephones, fax machines even an alarm 
system (in the roof!) cause this problem.
- It's possible that line is faulty - if the line has an intermittent 
open/short connection it doesn't matter how high you set the SNR, you 
will always lose sync during brief fault conditions.

*To do this read the following parameters once every 5 minutes and echo 
to a log file...
RSCorrectedErrorsDn
RSCorrectedErrorsUp
RSUncorrectedErrorsDn
RSUncorrectedErrorsUp

Kind regards,
  - Guy.


On 31/05/2013 8:07 AM, Niccolò Belli wrote:
> Il 30.05.2013 10:23 Niccolò Belli ha scritto:
>> The bad news is the connection is still more unstable than it should
>> be.
>> In 8 hours I already got the first disconnection even with a 12dB
>> margin!
>>
>> Thu May 30 03:35:40 UTC 2013 down
>> Thu May 30 03:36:18 UTC 2013 up
>> [28499.971546] solos 0000:00:0c.0: Bad status packet of 20 bytes on
>> port 0:
>> [28499.978374] 00: 00 21 45 00 00 47 40 BA
>> [28499.978402] 08: 00 00 74 11 CF 85 D9 7D
>> [28499.978423] 10: 98 98 C0 A8
>> [28499.978433]
>> [28510.047638] solos 0000:00:0c.0: Port 0: Showtime @10737/1020 kb/s,
>> SNR 12.05 dB, Attn 34.5 dB
>>
>> Any clue on this?
>
> Two more downs, that means 3 downs in 14 hours. This is not normal with
> a 12dB SNR. I can raise SNR to 14dB but I'm pretty sure it will not
> help. The problem is elsewhere.
>
> Thu May 30 17:01:14 UTC 2013 down
> Thu May 30 17:01:54 UTC 2013 up
> [76834.063520] solos 0000:00:0c.0: Bad status packet of 20 bytes on
> port 0:
> [76834.070355] 00: 00 21 45 00 00 3F 29 35
> [76834.070383] 08: 00 00 31 11 66 AD 75 46
> [76834.070404] 10: C0 35 C0 A8
> [76834.070413]
> [76844.129565] solos 0000:00:0c.0: Port 0: Training
> [76854.173728] solos 0000:00:0c.0: Port 0: Showtime @10233/1020 kb/s,
> SNR 12.55 dB, Attn 34.5 dB
> Thu May 30 17:28:35 UTC 2013 down
> Thu May 30 17:29:18 UTC 2013 up
> [76834.063520] solos 0000:00:0c.0: Bad status packet of 20 bytes on
> port 0:
> [76834.070355] 00: 00 21 45 00 00 3F 29 35
> [76834.070383] 08: 00 00 31 11 66 AD 75 46
> [76834.070404] 10: C0 35 C0 A8
> [76834.070413]
> [76844.129565] solos 0000:00:0c.0: Port 0: Training
> [76854.173728] solos 0000:00:0c.0: Port 0: Showtime @10233/1020 kb/s,
> SNR 12.55 dB, Attn 34.5 dB
>
> Niccolò
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> openadsl-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openadsl-users


-- 
Guy Ellis
gu...@tr...
www.traverse.com.au
T: +61 3 9386 4430 M: +61 419 398 234

Re: [openadsl-users] Was ADSL becomes unresponsive when using ppp

[Niccolò B. <nic...@li...>]

Il 30.05.2013 10:23 Niccolò Belli ha scritto:
> The bad news is the connection is still more unstable than it should
> be.
> In 8 hours I already got the first disconnection even with a 12dB
> margin!
>
> Thu May 30 03:35:40 UTC 2013 down
> Thu May 30 03:36:18 UTC 2013 up
> [28499.971546] solos 0000:00:0c.0: Bad status packet of 20 bytes on
> port 0:
> [28499.978374] 00: 00 21 45 00 00 47 40 BA
> [28499.978402] 08: 00 00 74 11 CF 85 D9 7D
> [28499.978423] 10: 98 98 C0 A8
> [28499.978433]
> [28510.047638] solos 0000:00:0c.0: Port 0: Showtime @10737/1020 kb/s,
> SNR 12.05 dB, Attn 34.5 dB
>
> Any clue on this?


Two more downs, that means 3 downs in 14 hours. This is not normal with 
a 12dB SNR. I can raise SNR to 14dB but I'm pretty sure it will not 
help. The problem is elsewhere.

Thu May 30 17:01:14 UTC 2013 down
Thu May 30 17:01:54 UTC 2013 up
[76834.063520] solos 0000:00:0c.0: Bad status packet of 20 bytes on 
port 0:
[76834.070355] 00: 00 21 45 00 00 3F 29 35
[76834.070383] 08: 00 00 31 11 66 AD 75 46
[76834.070404] 10: C0 35 C0 A8
[76834.070413]
[76844.129565] solos 0000:00:0c.0: Port 0: Training
[76854.173728] solos 0000:00:0c.0: Port 0: Showtime @10233/1020 kb/s, 
SNR 12.55 dB, Attn 34.5 dB
Thu May 30 17:28:35 UTC 2013 down
Thu May 30 17:29:18 UTC 2013 up
[76834.063520] solos 0000:00:0c.0: Bad status packet of 20 bytes on 
port 0:
[76834.070355] 00: 00 21 45 00 00 3F 29 35
[76834.070383] 08: 00 00 31 11 66 AD 75 46
[76834.070404] 10: C0 35 C0 A8
[76834.070413]
[76844.129565] solos 0000:00:0c.0: Port 0: Training
[76854.173728] solos 0000:00:0c.0: Port 0: Showtime @10233/1020 kb/s, 
SNR 12.55 dB, Attn 34.5 dB

Niccolò