|
Mario Charest
|
Issues with devnp-rtl8169.so SP1
|
|
Mario Charest
01/31/2018 2:43 PM
post118505
|
Issues with devnp-rtl8169.so SP1
Hi,
From latest BSP found on foundry:
NAME=devnp-rtl8169.so
DESCRIPTION=Realtek 8169 ethernet driver
DATE=2016/10/18-16:37:13-CDT
STATE=stable
HOST=psp650-linux-1.bts.rim.net
USER=builder
VERSION=1592
TAGID=PSP_networking_br650_be650SP1
This is my first attempt at using this driver on some new hardware.
The issue is that the second thread of io-pkt-v4 will become RUNNING forever. It does not if there is no cable connected
(or an IP adress is assigned). The issue seems somewhat random. After a reboot the problem shows up after a few
seconds. But 1 reboot every 10 it looks ok.
When io-pkt-v4 is in this state, any command such as nicinfo or ifconfig become reply blocked forever.
Hugh, in case you are reading this. I could go through official support channel if you prefer, but given your
participation here I was hoping to get rid of overhead ;-)
|
|
|
|
|
|
Hugh Brown
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Hugh Brown
02/01/2018 8:50 AM
post118507
|
Re: Issues with devnp-rtl8169.so SP1
Please try the attached driver.
Thanks, Hugh.
On 2018-01-31, 2:22 PM, "Mario Charest" <community-noreply@qnx.com> wrote:
Hi,
From latest BSP found on foundry:
NAME=devnp-rtl8169.so
DESCRIPTION=Realtek 8169 ethernet driver
DATE=2016/10/18-16:37:13-CDT
STATE=stable
HOST=psp650-linux-1.bts.rim.net
USER=builder
VERSION=1592
TAGID=PSP_networking_br650_be650SP1
This is my first attempt at using this driver on some new hardware.
The issue is that the second thread of io-pkt-v4 will become RUNNING forever. It does not if there is no cable
connected (or an IP adress is assigned). The issue seems somewhat random. After a reboot the problem shows up after
a few seconds. But 1 reboot every 10 it looks ok.
When io-pkt-v4 is in this state, any command such as nicinfo or ifconfig become reply blocked forever.
Hugh, in case you are reading this. I could go through official support channel if you prefer, but given your
participation here I was hoping to get rid of overhead ;-)
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post118505
To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Mario Charest
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Mario Charest
02/01/2018 11:49 AM
post118508
|
Re: Issues with devnp-rtl8169.so SP1
The RUNNING issue is gone. However seems no transmission is occuring. In the output of nicinfo notice how Packet
Transmitted stays at 1, even after many attemp at using ping.
rt0:
RealTek 8169 Gigabit Ethernet Controller
Physical Node ID ........................... 0090E8 633A66
Current Physical Node ID ................... 0090E8 633A66
Current Operation Rate ..................... 1000.00 Mb/s full-duplex
Active Interface Type ...................... MII
Active PHY address ....................... 0
Maximum Transmittable data Unit ............ 1500
Maximum Receivable data Unit ............... 1500
Hardware Interrupt ......................... 0x10b
I/O Aperture ............................... 0x3000 - 0x30ff
Memory Aperture ............................ 0x0
Promiscuous Mode ........................... Off
Multicast Support .......................... Enabled
Packets Transmitted OK ..................... 1
Bytes Transmitted OK ....................... 588
Memory Allocation Failures on Transmit ..... 0
Packets Received OK ........................ 85739
Bytes Received OK .......................... 12243098
Broadcast Packets Received OK .............. 85683
Multicast Packets Received OK .............. 56
Memory Allocation Failures on Receive ...... 0
Single Collisions on Transmit .............. 0
Transmits aborted (excessive collisions) ... 0
Transmit Underruns ......................... 1
No Carrier on Transmit ..................... 0
Receive Alignment errors ................... 0
Received packets with CRC errors ........... 0
Packets Dropped on receive ................. 0
> Please try the attached driver.
>
> Thanks, Hugh.
>
> On 2018-01-31, 2:22 PM, "Mario Charest" <community-noreply@qnx.com> wrote:
>
> Hi,
>
> From latest BSP found on foundry:
>
> NAME=devnp-rtl8169.so
> DESCRIPTION=Realtek 8169 ethernet driver
> DATE=2016/10/18-16:37:13-CDT
> STATE=stable
> HOST=psp650-linux-1.bts.rim.net
> USER=builder
> VERSION=1592
> TAGID=PSP_networking_br650_be650SP1
>
> This is my first attempt at using this driver on some new hardware.
>
> The issue is that the second thread of io-pkt-v4 will become RUNNING
> forever. It does not if there is no cable connected (or an IP adress is
> assigned). The issue seems somewhat random. After a reboot the problem shows
> up after a few seconds. But 1 reboot every 10 it looks ok.
>
> When io-pkt-v4 is in this state, any command such as nicinfo or ifconfig
> become reply blocked forever.
>
> Hugh, in case you are reading this. I could go through official support
> channel if you prefer, but given your participation here I was hoping to get
> rid of overhead ;-)
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post118505
> To cancel your subscription to this discussion, please e-mail drivers-
> networking-unsubscribe@community.qnx.com
>
>
|
|
|
|
|
|
Mario Charest
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Mario Charest
02/01/2018 12:12 PM
post118510
|
Re: Issues with devnp-rtl8169.so SP1
Output of sloginfo with verbose=3
Feb 01 16:48:40 6 17 0 free_mem_start = 0x7a000000, free_mem_end = 0xfec00000
Feb 01 16:48:40 6 17 0 intrinfo size = 320 entry size = 64 count = 5
Feb 01 16:48:40 6 17 0 base = 0x80010000 num = 6 cascade = 0x7fffffff intr 48
Feb 01 16:48:40 6 17 0 base = 0x8001ffff num = 1 cascade = 0x7fffffff intr 47
Feb 01 16:48:40 6 17 0 base = 0x80000000 num = 3 cascade = 0x7fffffff intr 2
Feb 01 16:48:40 6 17 0 base = 0x00000000 num = 87 cascade = 0x7fffffff intr 54
Feb 01 16:48:40 6 17 0 base = 0x00000100 num = 114 cascade = 0x7fffffff intr 141
Feb 01 16:48:40 5 17 0 Get routing failed 81
Feb 01 16:48:40 6 17 0 find_host_bridge - bridge_count 10 - num_pci_bridges 10
Feb 01 16:48:40 2 17 0 scan_windows: Alloc failed 0x80000008 - Size 0x10000000
Feb 01 16:48:40 5 14 0 tcpip starting
Feb 01 16:48:40 3 14 0 Using pseudo random generator. See "random" option
Feb 01 16:48:40 5 14 0 devnp-e1000.so did=0x10d3,pci=0,receive=2048,priority=200
Feb 01 16:48:40 5 14 0 wm0
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 5 14 0 lsm-qnet.so bind=wm0,no_slog=1,periodic_ticks=100,tx_retries=50,max_tx_bufs=1000,sl
ow_mode=500
Feb 01 16:48:40 7 15 0 qnet(L4): qnet_birth(): qnet_init() - calling
Feb 01 16:48:41 2 19 0 devb-eide 1.00A (Mar 11 2014 13:54:51)
... eide stuff removed
Feb 01 16:48:42 3 14 0 Using pseudo random generator. See "random" option
Feb 01 16:48:42 5 14 0 devnp-rtl8169.so did=0x8168,pci=0,priority=200,verbose=3
Feb 01 16:48:42 5 14 0 rt0
Feb 01 16:48:42 5 10 0 tcrval 0x2f900d00 - version 0x100000 - mcfg 0xffffffff
Feb 01 16:48:43 5 14 0 RealTek 8169 Gigabit
Feb 01 16:48:43 5 14 0 LanIdx .............. 0
Feb 01 16:48:43 5 14 0 DevIdx .............. 0
Feb 01 16:48:43 5 14 0 Vendor .............. 0x10ec
Feb 01 16:48:43 5 14 0 Device .............. 0x8168
Feb 01 16:48:43 5 14 0 Revision ............ 0x6
Feb 01 16:48:43 5 14 0 I/O port base ....... 0x3000
Feb 01 16:48:43 5 14 0 Memory base ......... 0x0
Feb 01 16:48:43 5 14 0 Interrupt ........... 0x10b
Feb 01 16:48:43 5 14 0 MAC address ......... 0090e8 633a66
Feb 01 16:48:44 5 10 0 rtl_StartUp: RTL_RMS 1519
Feb 01 16:48:45 5 10 0 devnp-rtl8169: rtl_stop() called, disable = 1
Feb 01 16:48:45 5 10 0 rtl_StartUp: RTL_RMS 1519
Feb 01 16:48:47 cron: started
Feb 01 16:48:47 1 8 0 phfont: init...
Feb 01 16:48:47 1 8 0 phfont: initialized.
Feb 01 16:48:47 1 8 0 phfont: '/dev/phfont[<32|64>]' server installed.
Feb 01 16:48:49 6 10 0 Link Interrupt
Feb 01 16:48:49 6 10 0 Phy Status 93
Feb 01 16:48:49 5 10 0 devnp-rtl8169: Link up (1000 BaseT Full Duplex)
|
|
|
|
|
|
Hugh Brown
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Hugh Brown
02/01/2018 2:06 PM
post118513
|
Re: Issues with devnp-rtl8169.so SP1
Mario,
The 6.5.0 rtl8169 driver hasn't been updated for ages, so I'm going to have to back-port the 6.6.0 driver to 6.5.0, when
I have a chance, so I won't have a driver for you soon.
Hugh.
On 2018-02-01, 11:51 AM, "Mario Charest" <community-noreply@qnx.com> wrote:
Output of sloginfo with verbose=3
Feb 01 16:48:40 6 17 0 free_mem_start = 0x7a000000, free_mem_end = 0xfec00000
Feb 01 16:48:40 6 17 0 intrinfo size = 320 entry size = 64 count = 5
Feb 01 16:48:40 6 17 0 base = 0x80010000 num = 6 cascade = 0x7fffffff intr 48
Feb 01 16:48:40 6 17 0 base = 0x8001ffff num = 1 cascade = 0x7fffffff intr 47
Feb 01 16:48:40 6 17 0 base = 0x80000000 num = 3 cascade = 0x7fffffff intr 2
Feb 01 16:48:40 6 17 0 base = 0x00000000 num = 87 cascade = 0x7fffffff intr 54
Feb 01 16:48:40 6 17 0 base = 0x00000100 num = 114 cascade = 0x7fffffff intr 141
Feb 01 16:48:40 5 17 0 Get routing failed 81
Feb 01 16:48:40 6 17 0 find_host_bridge - bridge_count 10 - num_pci_bridges 10
Feb 01 16:48:40 2 17 0 scan_windows: Alloc failed 0x80000008 - Size 0x10000000
Feb 01 16:48:40 5 14 0 tcpip starting
Feb 01 16:48:40 3 14 0 Using pseudo random generator. See "random" option
Feb 01 16:48:40 5 14 0 devnp-e1000.so did=0x10d3,pci=0,receive=2048,priority=200
Feb 01 16:48:40 5 14 0 wm0
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 2 12 0 ps2 - Device Timeout (0x55)
Feb 01 16:48:40 5 14 0 lsm-qnet.so bind=wm0,no_slog=1,periodic_ticks=100,tx_retries=50,max_tx_bufs=1000,sl
ow_mode=500
Feb 01 16:48:40 7 15 0 qnet(L4): qnet_birth(): qnet_init() - calling
Feb 01 16:48:41 2 19 0 devb-eide 1.00A (Mar 11 2014 13:54:51)
... eide stuff removed
Feb 01 16:48:42 3 14 0 Using pseudo random generator. See "random" option
Feb 01 16:48:42 5 14 0 devnp-rtl8169.so did=0x8168,pci=0,priority=200,verbose=3
Feb 01 16:48:42 5 14 0 rt0
Feb 01 16:48:42 5 10 0 tcrval 0x2f900d00 - version 0x100000 - mcfg 0xffffffff
Feb 01 16:48:43 5 14 0 RealTek 8169 Gigabit
Feb 01 16:48:43 5 14 0 LanIdx .............. 0
Feb 01 16:48:43 5 14 0 DevIdx .............. 0
Feb 01 16:48:43 5 14 0 Vendor .............. 0x10ec
Feb 01 16:48:43 5 14 0 Device .............. 0x8168
Feb 01 16:48:43 5 14 0 Revision ............ 0x6
Feb 01 16:48:43 5 14 0 I/O port base ....... 0x3000
Feb 01 16:48:43 5 14 0 Memory base ......... 0x0
Feb 01 16:48:43 5 14 0 Interrupt ........... 0x10b
Feb 01 16:48:43 5 14 0 MAC address ......... 0090e8 633a66
Feb 01 16:48:44 5 10 0 rtl_StartUp: RTL_RMS 1519
Feb 01 16:48:45 5 10 0 devnp-rtl8169: rtl_stop() called, disable = 1
Feb 01 16:48:45 5 10 0 rtl_StartUp: RTL_RMS 1519
Feb 01 16:48:47 cron: started
Feb 01 16:48:47 1 8 0 phfont: init...
Feb 01 16:48:47 1 8 0 phfont: initialized.
Feb 01 16:48:47 1 8 0 phfont: '/dev/phfont[<32|64>]' server installed.
Feb 01 16:48:49 6 10 0 Link Interrupt
Feb 01 16:48:49 6 10 0 Phy Status 93
Feb 01 16:48:49 5 10 0 devnp-rtl8169: Link up (1000 BaseT Full Duplex)
_______________________________________________
Networking Drivers
...
View Full Message
|
|
|
|
|
|
Mario Charest
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Mario Charest
02/01/2018 3:12 PM
post118514
|
Re: Issues with devnp-rtl8169.so SP1
Ok thanks. I'll dig up 6.6 and see if that works better.
|
|
|
|
|
|
Hugh Brown
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Hugh Brown
02/09/2018 1:43 PM
post118549
|
Re: Issues with devnp-rtl8169.so SP1
Please will you try the attached 6.5.0 driver?
Thanks, Hugh.
On 2018-02-01, 2:52 PM, "Mario Charest" <community-noreply@qnx.com> wrote:
Ok thanks. I'll dig up 6.6 and see if that works better.
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post118514
To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Michael Kurt
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Michael Kurt
02/12/2018 3:02 AM
post118558
|
Re: Issues with devnp-rtl8169.so SP1
If I may join this discussion, since I also wanted to start such a thread:
We are facing the same issue under QNX 6.5.0 SP1 but for 'devn-rtl' in context with io-pkt-v4-hc (and maybe for io-pkt-
v4 - tested only once).
As hardware, we are using an Advantech UNO-4683 which is equipped with two Gigabit interfaces (Intel 82574L - devnp-
e1000) and four 100MBit interfaces (RTL8139 - devn-rtl).
The problem even exists if there are no Ethernet cables plugged in, at all, and only the drivers are started (with one
Gigabit interface UP, one 100MBit interface UP, the rest is DOWN via ifconfig).
One thread of io-pkt-v4-hc (directly after starting, I would tell) remains in the RUNNING state and consumes much CPU
time (after some hours (>8h), 'top' reports 25% of CPU usage and running 'pidin ttimes' in a loop reports one more
second of 'sutime' usage per second)
When trying to 'ifconfig destroy' the interfaces before reboot, 'ifconfig' hangs (I think) on the interface that's io-
pkt thread is RUNNING and so much time consuming.
The same hanging occurs when only 'slay'ing io-pkt-v4-hc without destroying the interfaces.
If there's a way for me to somehow contribute, I would highly appreciate, since this problem will bring us into big
troubles when remote-maintaining our systems, since no safe reboot, if necessary, will be possible.
With best regards, Michael Kurt.
|
|
|
|
|
|
Hugh Brown
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Hugh Brown
02/12/2018 8:33 AM
post118562
|
Re: Issues with devnp-rtl8169.so SP1
Does this problem only occur when you start the devn-rtl driver? Does it occur if you only start the devn-rtl driver on
one interface? (io-pkt-v4-hc -drtl pci=0)
Please will you supply the output from the following commands when all driver are started and io-pkt is in the running
state:
pidin -pio-pkt-v4-hc mem
pci -vv
pidin
pidin arg
pidin irq
Thanks, Hugh.
On 2018-02-12, 2:41 AM, "Michael Kurt" <community-noreply@qnx.com> wrote:
If I may join this discussion, since I also wanted to start such a thread:
We are facing the same issue under QNX 6.5.0 SP1 but for 'devn-rtl' in context with io-pkt-v4-hc (and maybe for io-
pkt-v4 - tested only once).
As hardware, we are using an Advantech UNO-4683 which is equipped with two Gigabit interfaces (Intel 82574L - devnp-
e1000) and four 100MBit interfaces (RTL8139 - devn-rtl).
The problem even exists if there are no Ethernet cables plugged in, at all, and only the drivers are started (with
one Gigabit interface UP, one 100MBit interface UP, the rest is DOWN via ifconfig).
One thread of io-pkt-v4-hc (directly after starting, I would tell) remains in the RUNNING state and consumes much
CPU time (after some hours (>8h), 'top' reports 25% of CPU usage and running 'pidin ttimes' in a loop reports one more
second of 'sutime' usage per second)
When trying to 'ifconfig destroy' the interfaces before reboot, 'ifconfig' hangs (I think) on the interface that's
io-pkt thread is RUNNING and so much time consuming.
The same hanging occurs when only 'slay'ing io-pkt-v4-hc without destroying the interfaces.
If there's a way for me to somehow contribute, I would highly appreciate, since this problem will bring us into big
troubles when remote-maintaining our systems, since no safe reboot, if necessary, will be possible.
With best regards, Michael Kurt.
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post118558
To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Michael Kurt
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Michael Kurt
02/13/2018 9:18 AM
post118568
|
Re: Issues with devnp-rtl8169.so SP1
Please find attached the results I collected ('captured' always ca. 10 minutes after booting).
The problem occurs when at least two interfaces are started.
I started the drivers / interfaces via 'mount -t io-pkt -o pci=...,vid=...', since this is the way our start scripts
work,
but the results are the same as by starting via 'io-pkt-v4-hc -drtl pci=x'
There are six scenarios:
results_1 - 1 RTL interface started (devn-rtl, pci=0 - en0)
results_2 - 2 RTL interfaces started (devn-rtl, pci=0-1 - en0-1)
results_3 - 3 RTL interfaces started (devn-rtl, pci=0-2 - en0-2)
results_4 - 4 RTL interfaces started (devn-rtl, pci=0-3 - en0-3)
results_5 - 4 RTL interfaces and 1 Intel interfaces started (devn-rtl, pci=0 - en0-3, devnp-e1000, pci=0 - wm0)
results_6 - 4 RTL interfaces and 2 Intel interfaces started (devn-rtl, pci=0 - en0-3, devnp-e1000, pci=0/1 - wm0-1)
It looks to me like an issue with shared interrupts.
Unfortunately the BIOS of the used PCs does not allow to change PCI IRQ assignment.
With best regards,
Michael.
|
|
|
|
|
|
Hugh Brown
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Hugh Brown
02/13/2018 10:14 AM
post118571
|
Re: Issues with devnp-rtl8169.so SP1
OK, it seems to be that as soon as you start the second RTL device, it is sharing an interrupt with "comserv", whatever
that is.
Have you tried using startup_apic and pci-bios-v2 in your system at all? This might solve the problem of shared
interrupts.
On 2018-02-13, 8:57 AM, "Michael Kurt" <community-noreply@qnx.com> wrote:
Please find attached the results I collected ('captured' always ca. 10 minutes after booting).
The problem occurs when at least two interfaces are started.
I started the drivers / interfaces via 'mount -t io-pkt -o pci=...,vid=...', since this is the way our start scripts
work,
but the results are the same as by starting via 'io-pkt-v4-hc -drtl pci=x'
There are six scenarios:
results_1 - 1 RTL interface started (devn-rtl, pci=0 - en0)
results_2 - 2 RTL interfaces started (devn-rtl, pci=0-1 - en0-1)
results_3 - 3 RTL interfaces started (devn-rtl, pci=0-2 - en0-2)
results_4 - 4 RTL interfaces started (devn-rtl, pci=0-3 - en0-3)
results_5 - 4 RTL interfaces and 1 Intel interfaces started (devn-rtl, pci=0 - en0-3, devnp-e1000, pci=0 - wm0)
results_6 - 4 RTL interfaces and 2 Intel interfaces started (devn-rtl, pci=0 - en0-3, devnp-e1000, pci=0/1 - wm0-1)
It looks to me like an issue with shared interrupts.
Unfortunately the BIOS of the used PCs does not allow to change PCI IRQ assignment.
With best regards,
Michael.
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post118568
To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Michael Kurt
|
Re: Issues with devnp-rtl8169.so SP1
|
|
Michael Kurt
02/15/2018 11:28 AM
post118584
|
Re: Issues with devnp-rtl8169.so SP1
That 'comserv' is our server for serial interfaces, and the used interface PCI card shares IRQs with other PCI
components (of course).
After using startup_apic and pci-bios-v2 it looks better at the first glance. But I have to test some scenarios. We
used pci-bios only.
Thanks You for the hint!
With best regards,
Michael Kurt
|
|
|
|
|
|
