Feed for discussion Networking Drivers in project Networking.

post122705: Re: QNX6.6 I210 driver not working

2025-12-09T17:16:17Z

Hi Mario,

You'll need to contact QNX support about PSP packages, they aren't generally available.

Your pci output does indicate that the device is connected to a bus that should have MSI support; I don't think there's any PCI server patches that are relevant. You could try running the driver you have with verbosity enabled (`io-pkt-v6-hc -d e1000 verbose=4`) and see if `sloginfo` has anything to say about what the driver is doing. Beyond that, though, I don't know if there's much more that can be done short of finding a way to rebuild the driver and debugging it. As Nick mentioned, QNX 6.6 has been end-of-life for quite some time, so you'll be mostly on your own with it.

Sorry I can't be of more help,

-Will

post122704: Re: QNX6.6 I210 driver not working

2025-12-09T16:09:48Z

I've attached the pci -vvv file dump, in case it can be of help

thanks

-mario

post122703: Re: QNX6.6 I210 driver not working

2025-12-09T10:19:30Z

Thank Will,

I will get the dump of pci -vvv asap, for both the pci-bios and pci-bios-v2 images.

just a question, where I can find the PSP_networking_br660_be660-977_net-libnetdrvr-x86-exp.tar

file? I've not found it in the archived bsp

-Mario

post122702: Re: QNX6.6 I210 driver not working

2025-12-08T19:44:39Z

Hi,

IIRC, the last 6.6 version of the BSP I've got on hand (BSP_x86-generic_br-660_be-660_SVN816552_JBN786.zip) needed an updated libnetdrvr.a from "PSP_networking_br660_be660-977_net-libnetdrvr-x86-exp.tar" to build.

Would you mind posting `pci -vvv` from the affected board? We had some issues with PCI interrupt routing on QNX 6.6, possibly one of the patches we have for pci-bios-v2 could help.

-Will

post122701: Re: QNX6.6 I210 driver not working

2025-12-08T13:14:59Z

thanks Nick: i've tested same systemm on another board wilth a speedo driver and all works fine,

so trouble is in i210 driver. Interrupt problem should be a good point to analyze.

I've tested both spartup-bios and statup-apic with same result: driver not working.

But with startup-bios the IRQ assigned (IRQ6) seems to be correct: is the same found in pci

and detected by the driver....somo other routing to do?

Thangx again

Mario

post122700: Re: QNX6.6 I210 driver not working

2025-12-03T13:52:38Z

QNX 6.6.0 was End of Life in February 2024 https://www.blackberry.com/us/en/support/software-support-life-cycle I strongly recommend moving to QNX SDP 8 and if this is for Non-Commercial Use then join our QNX Everywhere program https://www.qnx.com/products/everywhere/

nic_delay() is in libnetdrvr. I think your problem with the link not coming up is probably the interrupt not working because it has failed to get MSI-X or MSI interrupts and fallen back to pin interrupts with the wrong interrupt routing.

post122699: QNX6.6 I210 driver not working

2025-12-03T08:11:38Z

I'm trying to get QNX 6.6 working on a ETX board with an INTEL I210 .

Started from sources of devnp-e1000.so driver from a BSP (x86-generic-SPD6.6)

Recompiled the driver and try to run it but io-pkt-v6-hc stops and abort

printing this messages:

ldd:FATAL: Unresolved symbol "nic_delay" called from devnp-e1000.so

Now, I've searched in the BSP for nic_delay and I've found a reference in the

\usr\include\netdrvr\nicsupport.h

But where is the library to resolve the function?

it seems that is not in the binary io-pkt-v6-hc i'm using ...

Is the function in some other library ?

or the io-pkt-vx-hc are NOT the latest binary ?

This is the start up of driver:

io-pkt-v6-hc -d e1000 -p tcpip -vvvv &

if_up -r 10 -p wm0

ifconfig wm0 11.0.0.159

ifconfig wm0 alias 192.168.10.29

sloginfo

-----------------

Time             Sev Major Minor Args

Nov 30 16:54:33    5    14     0 tcpip starting

Nov 30 16:54:33    3    14     0 Using pseudo random generator.  See "random" option

Nov 30 16:54:33    5    14     0 initializing IPsec... done

Nov 30 16:54:33    5    14     0 IPsec: Initialized Security Association Processing.

Nov 30 16:54:33    5    14     0 wm0

Nov 30 16:54:33    5    17     0 last_chance on B5:D0:F0 irq 6

Nov 30 16:54:33    5    17     0 get_msi_irq() for B5:D0:F0

Nov 30 16:54:33    5    17     0 scan_irq_routing() for B5:D0:F0

Nov 30 16:54:33    6    10     0 i82544_pci_attach: rar entries 16

ldd:FATAL: Unresolved symbol "nic_delay" called from devnp-e1000.so

ifconfig: socket: Address family not supported by protocol family

ifconfig: socket: Address family not supported by protocol family

route: socket: Address family not supported by protocol family

After that I've used the latest io-pkt-vX-hc,devnp-e1000.so binaries availables

downloaded from QNX site and it seems that driver's is running but there is no

link UP event and link is always DOWN, network is notworking.

I've tested hardware using Windows and Linux and the ethernet works fine, so problem

is in the QNX driver.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><

Time             Sev Major Minor Args

Nov 30 16:42:52    5    14     0 tcpip starting

Nov 30 16:42:52    3    14     0 Using pseudo random generator.  See "random" option

Nov 30 16:42:52    5    14     0 initializing IPsec... done

Nov 30 16:42:52    5    14     0 IPsec: Initialized Security Association Processing.

Nov 30 16:42:52    5    14     0 wm0

Nov 30 16:42:52    5    17     0 last_chance on B5:D0:F0 irq 0

Nov 30 16:42:52    5    17     0 get_msi_irq() for B5:D0:F0

Nov 30 16:42:52    5    17     0 scan_irq_routing() for B5:D0:F0

Nov 30 16:42:52    5    10     0 Link down

Nov 30 16:42:52    5    14     0 INTEL PRO/1000 Gigabit (Copper)

Nov 30 16:42:52    5    14     0 Vendor .............. 0x8086

Nov 30 16:42:52    5    14     0 Device .............. 0x1533

Nov 30 16:42:52    5    14     0 Revision ............ 0x0

Nov 30 16:42:52    5    14     0 Memory base ......... 0xb0600000

Nov 30 16:42:52    5    14     0 Interrupt ........... 0x6

Nov 30 16:42:52    5    14     0 MAC address ......... 003064 8859ef

Nov 30 16:42:52    5    10     0 devnp-e1000: i82544_stop() called, disable = 0

Nov 30 16:42:52    6    10     0 ITR set to 20000

Nov 30 16:42:52    5    10     0 Link down

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

inet 127.0.0.1 netmask 0xff000000

inet6 ::1 prefixlen 128

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

capabilities rx=1f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM>

capabilities tx=7f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM,TSO4,TSO6>

enabled=0

address: 00:30:64:88:59:ef

media: Ethernet none

inet 11.0.0.159 netmask 0xff000000 broadcast 11.255.255.255

inet alias 192.168.10.29 netmask 0xffffff00 broadcast 192.168.10.255

inet6 fe80::230:64ff:fe88:59ef%wm0 prefixlen 64 scopeid 0x11

IRQ seems to be ok:

-----------------------

     pid tid name

   77838   1 sbin/io-pkt-v6-hc

   77838   2 sbin/io-pkt-v6-hc

6              0x6    0 T-- @0xb822d19c:0x823c100

   77838   3 sbin/io-pkt-v6-hc

   77838   4 sbin/io-pkt-v6-hc

nicinfo

-----------------------

Active Internet connections

Proto Recv-Q Send-Q  Local Address          Foreign Address        State

udp        0      0  *.*                    *.*

wm0:

  INTEL PRO/1000 Gigabit (Copper) Ethernet Controller

  Link is DOWN

  Physical Node ID ........................... 003064 8859EF

  Current Physical Node ID ................... 003064 8859EF

  Current Operation Rate ..................... 0 kb/s half-duplex

  Active Interface Type ...................... MII

    Active PHY address ....................... 1

  Maximum Transmittable data Unit ............ 1500

  Maximum Receivable data Unit ............... 1500

  Hardware Interrupt ......................... 0x6

  Memory Aperture ............................ 0xb0600000 - 0xb067ffff

  Promiscuous Mode ........................... Off

  Multicast Support .......................... Enabled

  Packets Transmitted OK ..................... 0

  Bytes Transmitted OK ....................... 0

  Broadcast Packets Transmitted OK ........... 0

  Multicast Packets Transmitted OK ........... 0

  Memory Allocation Failures on Transmit ..... 0

  Packets Received OK ........................ 777

  Bytes Received OK .......................... 85590

  Broadcast Packets Received OK .............. 680

  Multicast Packets Received OK .............. 97

  Memory Allocation Failures on Receive ...... 0

  Single Collisions on Transmit .............. 0

  Multiple Collisions on Transmit ............ 0

  Deferred Transmits ......................... 0

  Late Collision on Transmit errors .......... 0

  Transmits aborted (excessive collisions) ... 0

  Jabber detected ............................ 0

  Receive Alignment errors ................... 0

  Received packets with CRC errors ........... 0

  Packets Dropped on receive ................. 1

  Oversized Packets received ................. 0

  Short packets .............................. 0

  Squelch Test errors ........................ 262

  Invalid Symbol Errors ...................... 0

There is no link UP event and link is always DOWN.

Any idea how I can fix this problem?

Mario

post122438: Re: Intel I219 Gigabit ethernet support in devnp-e1000.so ?

2023-11-19T22:53:40Z

Hello Hugh,

great support, many thanks!

Wolfgang

post122409: Re: Installing and running e1000 driver on QNX 6.5.0

2023-10-26T13:11:42Z

QNX 6.5.x was End of Life in December 2022 https://www.blackberry.com/us/en/support/software-support-life-cycle

There were a number of updates of io-pkt and the drivers through the 6.5.x lifetime, so it looks like the newer drivers that you are finding are incompatible with the older io-pkt. If you can find a matched pair you may be able to make it work, but you are on your own with that.

post122406: Installing and running e1000 driver on QNX 6.5.0

2023-10-25T20:34:46Z

I have a new x86 computer for an existing system. I did a fresh install of 6.5.0 and then applied the SP 1 update. Everything appears to work except the NICs. I see the NICs in the list of devices using pci -vvv. The NICs show as 8086:1533 and 8086:153a These are the i210 and i217 chips. I've tried several of the drivers from the internet and all except the original abort with a core dump when I do io-pkt-v4-hc -de1000. Is there anything else I need to do other than installing 6.5.0, applying the SP1 update, and copying in the new driver to /lib/dll? What is the latest driver? I did install a copy of 7.1 and it was able to see both NICs fine. Am I missing something here?

post122336: in io-pkt rx_interrupt_handler context

2023-06-30T06:43:37Z

generally we register a handler such as:

vdevpeer->rx_ient.func = vdevpeer_rx_interrupt;

and then in other thread we raise it by interrupt_queue(vdevpeer->iopkt, &vdevpeer->rx_ient);

i want to know in vdevpeer_rx_interrupt context it is ISR context or thread context or signal hanler context?

post122317: network protocol stack problem

2023-06-09T03:36:01Z

The network protocol stack problem,

We found a problem. After our network has been running for a long time, large data packets will be received abnormally. The length of the data packet is 8KB. At the same time, when we ping the device, the specified data packet size is 10240 bytes, which is also a ping failure, but we put the ping data packet If the size is set to be less than or equal to 1500, it can be pinged normally. The version we use is QNX 6.5.0 BSP for TI BeagleBone.

Receiving more than 1KB bytes, calling the recvfrom function, no return, but receiving less than 1KB bytes, the return is normal.

post122264: Dynamically Changing the MAC-ID of the ethernet interface

2023-05-15T08:14:28Z

I am trying to change the MAC id of my ethernet interface using the below command.

ifconfig eth0 link xx:xx:xx:00:00:08 active

I got the output like

eth0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1466

        capabilities rx=1f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM>

        capabilities tx=7f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM,TSO4,TSO6>

        enabled rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM>

        enabled tx=27<IP4CSUM,TCP4CSUM,UDP4CSUM,TSO4>

        address: xx:xx:xx:00:00:08

        link xx:xx:xx:00:00:07



But the ping is not happening with the latest MAC -ID and this MAC-ID is not persistent between reboots.

What would be the reason for not getting the ping to work?

How can I retain the new MAC-ID even after a reboot?

post122218: ifconfig output shows unwanted information of ssid & powersave

2023-04-19T10:32:07Z

Hello Team,

I am trying to write an io-pkt driver for a TI hardware. After writing the driver, when I mount to io-pkt, i see the port coming up in ifconfig output. But I see some data related to ssid, powersave, bssid etc as shown below.

1) Can you please guide how these flags are being poplated and what I need to do to remove these flags from ifconfig output?

2) Also, can you please share me a sample application example which shows proper settings for an interface?

ifconfig output

cpsw0: flags=8803<UP,BROADCAST,SIMPLEX,MULTICAST> mtu 1500

        ssid 0x0110

        powersave on (42ms sleep)

        bssid 00:92:92:80:2a:00 chan 65160

        tunnel ??? , --> ,

        address: 02:03:6b:b3:4d:14

Regards,

Manas

post122173: wireless driver

2023-03-18T10:02:43Z

I am trying to set an ssid using ifconfig as shown below.

#ifconfig wlan0 ssid netgear

IOCTL which gets called in the driver is : SIOCS80211NWID

Using copyin I am trying to copy the contents as shown below.

Something like below.

if (!copyin((((caddr_t) ifr)+ sizeof(struct ifreq)), &nwid, sizeof(struct ieee80211_nwid))){

When i dump the data, I only see wlan0 but the ssid name netgear.

Can somebody help me out on this, why the driver does not receive the entire information ?

I have dumped the data up-to 1000 bytes, and I only see "wlan0".

post122164: Re: Periodic io-net crash

2023-03-13T13:24:37Z

We are facing the same issue with QNX 6.3.2 and devn-speedo driver for Intel 82551T Ethernet Controller.

Sometimes it is causing system to freeze and sometimes, only Network becomes unresponsive while CPU is still running other processes.

Could you solve this?

post122156: Making Ethernet interface up/down from io-pkt

2023-03-06T14:24:57Z

In my application, in a specific scenario, I need to put the tsec0 interface down, and should make tsec1 up. This part

should be executed from QNX 'iopkt' TCP/IP stack subsystem. I tried calling the below command from there...

system ("ifconfig tsec0 down");

But when I ran this program, the device got restarted with the following message "SpvAbort SpvTaskTimeout task UDP"

.

Later I searched for options through 'ioctl 'command. But I didn't get any direct options. Instead I saw few options to

delete/add interface addresses. I tried with the below one to remove the IPI from tsec0 interface.

qnw_iface_list[0].if_net->if_ioctl (qnw_iface_list[0].if_net, SIOCDIFADDR, (caddr_t)&ifmr);

But this one also didn't help. Even though the command got executed, didn't find any change in device behavior. I was

still able to ping tsec0.

Here I need the guidance on how to make the ethernet interface down/up programmatically from 'iopkt' subsystem. I am pretty new to QNX world, so pls bear with my ignorance

post122108: io-pkt crashes with m_getcl_wtp

2023-01-08T16:44:39Z

The

1) mclbytes = 2048

2) nmbclusters(number of clusters) = 8192

when I try to allocate/get mbuf cluster greater than 8192 io-pkt hangs instead of returning NULL.

the code looks to take mbuf looks like

wtp = WTP

m = m_getcl_wtp (M_DONTWAIT, MT_DATA, M_PKTHDR, wtp);

The wtp is assigned to WTP present in siglock.h

#define WTP (stk_ctl.work_threads[NW_TID_TO_TIDX(LIBC_TLS_TID())])

Is there precondition or setting needs to be done to prevent this behaviour?

io-pkt is already up and running.

I am mounting my driver using "mount" command.

There is also a devnp-e1000.so running but it does not have any issues.

Looking forward for reply.

Thank you.

post121974: (QNX 7.1): Adding a second network driver to a running system using mount fails

2022-10-26T19:25:24Z

Using the form of the example to mount an Ethernet driver, given in the mount man page

The command: mount -v -v -T io-pkt /lib/dll/devnp-rtl8169.so

gives me the follow verbose output:

Parsed: mount from [/lib/dll/devnp-rtl8169.so] mount on [NULL] type [io-pkt1]

exec: mount_io-pkt -o rw -o implied -o nostat /lib/dll/devnp-rtl8169.so /

mount: exec mount_io-pkt for /: No such file or directory

Type [io-pkt] Flags 0x80080000

Device [/lib/dll/devnp-rtl8169.so] Directory [/]

Options [NULL]

mount: Can't mount / (type io-pkt)

mount: Possible reason: No such file or directory

The machine has several Intel nics on the motherboard, and a Realtek on a PCIe board.

When I read the verbose output, it suggests to me that mount is trying to mount the Realtek driver to '/', which is nonsense!

post121963: Re: devnp-e1000 driver with typed_mem on i.MX8 platform (SDP 7.1.0)

2022-10-14T13:30:55Z

Ah sorry, thought you were internal. You will need to contact your QNX support person and quote issue JI:2876490

post121962: Re: devnp-e1000 driver with typed_mem on i.MX8 platform (SDP 7.1.0)

2022-10-14T13:24:46Z

I can't access that either.

Would it be possible to send me details of the code change? I have e1000 source code (from SDP 7.0.3) so perhaps I can apply the change myself.

post121958: devnp-e1000 driver with typed_mem on i.MX8 platform (SDP 7.1.0)

2022-10-14T10:08:47Z

I am trying to load the e1000 driver on an i.MX8QN MEK board (using the latest official BSP on SDP 7.1.0) but the driver load fails with the following error in the system log:

Jan 01 03:13:16.684         io_pkt_v6_hc.385071..1                 slog      0  translate 0x970caf000, len 1000

Jan 01 03:13:16.684         io_pkt_v6_hc.385071..1                 slog      0  Unable to obtain buffer translation information, The Address Space Is Invalid/Could Not Be Translated [(PCI_ERR_ASPACE_INVALID)]

I am using the driver typed_mem option and the io-pkt-v6-hc pkt-typed_mem option, as shown in the driver use description, for example:

# io-pkt-v6-hc -i3 -de1000 typed_mem="/memory/below4G/ram/sysram/" -ptcpip pkt_typed_mem="/memory/below4G/ram/sysram/",prefix=/sock3

#

# SOCK=/sock3 ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33136

        inet 127.0.0.1 netmask 0xff000000

        inet6 ::1 prefixlen 128

        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

I have also tried the following typed memory strings:

below4G

/memory/below4G

/memory/below4G/ram

All give the same error.

How can I load this driver on an AARCH64 i.MX8 platform?

post121918: QNX 7.1 - devnp-e1000.so driver is not working with Intel i225 ethernet controller

2022-09-08T14:15:28Z

Hello,

I'm trying to use a newer version of Intel ethernet device: I225 but devnp-e1000.so (with qnx 7.0 and 7.1) can't recognize it.

Does anyone know if there is a specific version of devnp-e1000 to support these devices (I225) please?

(It's ok with the old version I210.)

Same question with the LAN7430 Microship.

Thx,

Regards

post121873: Re: Ethernet packet timestamping

2022-07-14T02:10:39Z

Thanks a lot. If I want to use the accurate time for my own time sync module which will get accurate time from each sent/received raw data packet, I have to use the limited interfaces from ptpd-avb?

post121868: Re: Ethernet packet timestamping

2022-07-13T13:53:55Z

For raw Ethernet then BPF is the correct interface, we don't support raw sockets in io-pkt.

The PTP API is in ptp.h

We ship and support two PTP implementations:

- "ptpd" supports PTPv2 in UDP in IPv4

- "ptpd-avb" supports PTPv2 in Ethernet (802.1AS).

N.B. Only certain network hardware supports hardware timestamping, and we have implemented PTP support only in some specific network drivers. Running either "ptpd" or "ptpd-avb" on hardware without support will result in it using the system clock for timestamping, which will not result in the accuracy that PTP is capable of. If run with logging to the console, both "ptpd" and "ptpd-avb" will report the hardware support status when they start.

If you are looking for PTP support on certain hardware and a certain QNX version, I would suggest getting in touch with your local QNX support representative and they should be able to help determine if it is supported or not.

post121865: Re: Ethernet packet timestamping

2022-07-13T07:41:52Z

> > The BPF header does include the timestamp in the bh_tstamp field.

> >

> > If you are using normal sockets rather than BPF then you can use the

> > SO_TIMESTAMP socket option to timestamp packets.

> >

> > If you are looking for accurate packet times used with PTP then these can be

>

> > retrieved with the PTP_GET_RX_TIMESTAMP and PTP_GET_TX_TIMESTAMP on

> supported

> > network interfaces.

>

>

>

> I am trying to send/receive a raw data frame. So I used the bpf module instead

>  of socket. Is there any example show that how to use raw socket(like SOCK_RAW

>  in linux) to send/receive a raw data frame.

I mean the socket domin is PF_PACKET for processing ethernet packet frame in data Link Layer.

post121864: Re: Ethernet packet timestamping

2022-07-13T07:09:28Z

> The BPF header does include the timestamp in the bh_tstamp field.

>

> If you are using normal sockets rather than BPF then you can use the

> SO_TIMESTAMP socket option to timestamp packets.

>

> If you are looking for accurate packet times used with PTP then these can be

> retrieved with the PTP_GET_RX_TIMESTAMP and PTP_GET_TX_TIMESTAMP on supported

> network interfaces.

Yes. I am looking for the accurate packet times used with PTP. Where can I find those interfaces.

post121863: Re: Ethernet packet timestamping

2022-07-13T06:35:26Z

> The BPF header does include the timestamp in the bh_tstamp field.

>

> If you are using normal sockets rather than BPF then you can use the

> SO_TIMESTAMP socket option to timestamp packets.

>

> If you are looking for accurate packet times used with PTP then these can be

> retrieved with the PTP_GET_RX_TIMESTAMP and PTP_GET_TX_TIMESTAMP on supported

> network interfaces.

I am trying to send/receive a raw data frame. So I used the bpf module instead of socket. Is there any example show that how to use raw socket(like SOCK_RAW in linux) to send/receive a raw data frame.

post121854: Re: Ethernet packet timestamping

2022-07-12T13:04:19Z

The BPF header does include the timestamp in the bh_tstamp field.

If you are using normal sockets rather than BPF then you can use the SO_TIMESTAMP socket option to timestamp packets.

If you are looking for accurate packet times used with PTP then these can be retrieved with the PTP_GET_RX_TIMESTAMP and PTP_GET_TX_TIMESTAMP on supported network interfaces.

post121851: Ethernet packet timestamping

2022-07-12T09:43:21Z

How can I get the timestamp that when ethernet packets arrived at NIC? Are there any relevant interfaces here? I used bpf to receive ethernet packet but the bpf header does not support passing timestamp to users. Is there any way can I get the timestamp when Ethernet packets sent or received?

post121753: Re: Networking Response and pci-bios Image

2022-03-09T17:55:14Z

Its always frustrating when answers to questions aren't responded to, or the original poster doesn't provide an update. So I apologize for taking so long to follow-up. Other more urgent projects have been taking up my time since I posted this question, but I've finally had some time to go back and try some of the suggestions.

Thanks for the suggestions Will. Using your idea of manually overriding the assigned interrupt one irq at a time eventually resolved the issue. So it seems the mapping of the irq through the PCI bridges doesn't work properly.

It's cumbersome, but in the end we can find the correct IRQ through trial and error, and configure the network driver to use that IRQ. Response times are in the expected and required range.

Once again, thanks for the help.

post121476: Support for TI18XX devnp-ti18xx_imx6x in QNX 7.1

2021-07-01T12:50:36Z

Hi all, recently I've updated a imx6-based system from QNX7.0 up to QNX7.1.

We are using a board with wifi/bt chip from TI and is supported by devnp-ti18xx_imx6x.so

driver. This is in QNX7.0 but not in QNX7.1 .

Also the ti utilities are missing :

wpa_passphrase_ti18xx,wpa_supplicant_ti18xx and tiwlan_cfg_ti18xx .

Are these tools still availables on QNX7.1 ?

Thanks,

Mario

post121475: Re: Networking Response and pci-bios Image

2021-06-29T19:32:45Z

Hi Aaron,

I concur with Nick's assessment -- it's probably an incorrect IRQ assignment or an unfriendly shared IRQ.  Given that you're reporting that it doesn't work with apic either, that's some evidence pointing to the idea that the operating system isn't getting the correct IRQ.  I've had this happen when there were PCI-to-PCI bridges in the communications chain.    You can use the output of pci -vv to determine if your card is behind such a bridge: there would be an entry "Class = Bridge (PCI/PCI)", and the "Secondary bus number" for the bridge entry would match the "Bus number" for your network controller.

Here are some things you could try:

- Manually override the interrupt assignment when launching the network driver with the 'irq=x' argument.   It's lame, but you could just try all possible values (1-15) to see if there's one where you consistently get back your 0.3s ping.

- Another way to find the correct IRQ: if the BIOS doesn't print out a page with the IRQ assignments, you could try and find out what the BIOS thought the IRQ should be by writing a little test program that manually invokes a PCI BIOS call to read the IRQ register on the card, and then run this program in your boot script before launching pci-bios.

- Alternately, I can pass along a patch I wrote for pci-bios-v2 from the 6.6 x86 BSP that adds the ability to map IRQs properly through PCI-to-PCI bridges.  If that is your problem, this patch might fix it for you.

If the problem is an unfriendly shared IRQ, you can use 'pidin irqs' to find out what other drivers are active on your IRQ line, and then try shutting them off one by one until you find the cuplrit.  You can sometimes influence IRQ sharing assignments by enabling or disabling various hardware in the BIOS, such as PS/2 mouse support or unused serial or ethernet ports.

Hope this is of some help,

-Will

post121474: Re: Networking Response and pci-bios Image

2021-06-29T17:44:58Z

> Given that it works well when using startup-apic and pci-bios-v2, I think your

>  problem is with the interrupts rather than the network driver itself.

>

> I suspect the wrong interrupt is being identified for the network card and you

>  are being saved by something else triggering the network driver code -

> probably one of the other devices that is sharing that interrupt.

>

> Alternatively with shared interrupts, one of the other device drivers that is

> sharing that interrupt isn't handling things properly - possibly masking and

> then taking a long time to determine that it the interrupt isn't for it before

>  unmasking so that the network driver can see it.

>

> Regards,

> Nick

Thanks for the info. I suppose if it is an interrupt issue I don't have much, if any, control over how they are setup or handled. That would require bios code changes?

post121473: Re: Networking Response and pci-bios Image

2021-06-29T17:12:26Z

Given that it works well when using startup-apic and pci-bios-v2, I think your problem is with the interrupts rather than the network driver itself.

I suspect the wrong interrupt is being identified for the network card and you are being saved by something else triggering the network driver code - probably one of the other devices that is sharing that interrupt.

Alternatively with shared interrupts, one of the other device drivers that is sharing that interrupt isn't handling things properly - possibly masking and then taking a long time to determine that it the interrupt isn't for it before unmasking so that the network driver can see it.

Regards,

Nick

post121472: Networking Response and pci-bios Image

2021-06-29T17:01:34Z

We've created a QNX 6.6 image to use with an axiomtek mano500 board Despite a BSP exiting for the mano500 board, we've had better success with the generic QN 6.6 BSP. I've taken over this project from the original developer and understand enough to make things works, but I still wouldn't consider myself an expert, so I appreciate your patience.

I'm having problems getting the network response to the same level as other machines on the network. On a local network the ping response times to the QNX 6.6 machine are in the range of 5 - 45 ms. Pinging a QNX 6.3, or any other device on the network the response time is less than 0.3 ms. The slow response seen in ping is also evident in other network applications on QNX 6.6, ping is just an easy way of demonstrating the issue.

The QNX 6.6 image with the slow response time is being created using startup-bios and pci-bios, using the devnp-e1000 driver. If I use startup-apic and pci-bios-v2 the ping response time matches what is seen with all the other devices on the network, less than 0.3 ms.

However, the computer must use a particular PCI card which doesn't work properly when using startup-apic and pci-bios-v2, so we are forced to use startup-bios and pci-bios.

I also notice that when using startup-bios and pci-bios all the interrupts for the (PCI) devices are shared, which is not the case for startup-apic and pci-bios-v2. I have a feeling that the slow respose time might be related to the shared interrupts, but I'm not knowledgable enough to know if that is true, or what to do about it.

I'm not sure what other relevant information I can add. So, is there anything I can do or try to get better performance from the networking on QNX 6.6? Or am I just out of luck?

Thanks

post121443: QNX 6.6.0 Network Driver for Intel Kaby Lake chipset (i219LM)

2021-06-01T23:04:42Z

Is the network driver for QNX 6.6.0+SP1 Intel chip i219LM available or is it planned to be updated?

post121417: Retrieving Network statistics similar to nicinfo in c++

2021-05-17T12:42:47Z

I was looking for a way to query all the info available with the nicinfo utility directly into c++.

Currently I am using the popen command to parse the text from nicinfo. I was hoping there was an alternative way to do this?

I see that a nic_stats_t structure is available "qnx.com/developers/docs/6.3.2/ddk_en/network/nic_stats_t.html".

This suggests that I would use devctl() with DCMD_IO_NET_GET_STATS to retrieve this information, however this leaves me with a few more questions:

1. What file descriptor do I pass to devctl? I do not see my Network devices in the "/dev/..." directory.

2. What includes do I need to achieve the mentioned functionality.

3. Are there any c++ examples I could look at to help me along?

I tried to find the nicinfo source using the svn checkout method however I do not seem to have access to that.

Thanks

post121377: tcpdump

2021-04-13T03:50:19Z

How to run tcpdump on QNX? I am unable to run it directly.

post121376: Re: promiscous mode QNX 6.4

2021-04-13T03:48:32Z

Found it ... able to set it when I listen on an interface using libpcap

post121369: Re: promiscous mode QNX 6.4

2021-04-06T12:35:11Z

Which network driver are you running? You can try adding "promiscuous" to the driver command line when you start the driver.

On 2021-04-06, 8:27 AM, "Chitra Prabhu" <community-noreply@qnx.com> wrote:

    promiscous mode QNX 6.4-> How to enable promiscous mode ? en0 promiscous mode is OFF. I tried ifconfig it does not work. What is a good way to do this ?

    _______________________________________________

    Networking Drivers

    http://community.qnx.com/sf/go/post121368

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post121368: promiscous mode QNX 6.4

2021-04-06T12:27:35Z

promiscous mode QNX 6.4-> How to enable promiscous mode ? en0 promiscous mode is OFF. I tried ifconfig it does not work. What is a good way to do this ?

post121336: WI FI driver template

2021-03-19T11:02:25Z

Hi, I'm search for wifi driver running on imx6/ QNX6.6. It seems quite impossible to have any support

from QNX, also in binary form. I've use the only driver availabe by qnx, for TwLink8 WL1835 (SDIO)

and its works ok, but we need to test some other modules based on broadcom chips.

If a source template for a WORKING wi.fi driver is available maybe I can try to port the linux one ,

that is available in source : I do not want to start from scratch, if it is possible ;

Thanks

Mario

post121146: QNX 7.0 - devnp-e1000.so driver displayed error, using inetl 82574L Gbit ethernet card.

2020-12-09T08:40:15Z

Hi,

devnp-e1000.so driver displayed error message, when inetl 82574L Gigabit ethernet controller was loaded by it.

the system is :

CPU : Intel core i7

Ethernet : Intel 82574L Gigabit Ethernet Controller

QNX version : QNX 7.0

Driver : devnp-e1000.so

Error message :

#io-pkt-v4-hc -i2 -ptcpip prefix=/alt2

# mount -T io-pkt2 -o did=0x10d3,pci=21 /lib/dll/devnp-e1000.so

mount: Can't mount / (type io-pkt2)

mount: Possible reason: No such device

#

I had searched lots information in Foundry27, but I can not get correct information.

I hope someone can tell me solution.

post120764: Re: Ethernet errors detection

2020-06-11T16:45:06Z

See net/ifdrvcom.h and hw/nicinfo.h

You will need to look at the valid_stats field in nic_ethernet_stats_t to determine which stats the driver supports. If that doesn't have everything you need then yes, you will need to contact the driver vendor to add support.

post120758: Re: Ethernet errors detection

2020-06-11T10:00:52Z

Thanks a lot for response!

> Take a look at the output of the "nicinfo" command, this reports the Ethernet

> stats. Note that this is entirely driver dependent - different drivers report

> different stats.

>

> The code for this is:

> struct drvcom_stats dstats;

> nic_stats_t *statp;

>

> statp = &dstats.dcom_stats;

>

> ifdcp->ifdc_cmd = DRVCOM_STATS;

> ifdcp->ifdc_len = sizeof(*statp);

> if ((ret = devctl(s, SIOCGDRVCOM, ifdcp,

> sizeof(struct drvcom_stats), NULL)) == EOK) {

> dump_stats(s, statp);

> }

>

Could you tell me what header files do I need for this code?

Also, as I understand, do we need to reach driver suppliers in order to extend information about Ethernet interface?

post120748: DF bit and UDP checksum validation per socket - IPv4

2020-06-09T13:56:36Z

Hello,

I have two questions:

1) Is there any way to set/unset IP Don't Fragment bit (DF bit) per socket (e.g. using setsockopt() ) in QNX 7.0.0?

In Linux it is possible via:

setsockopt() with the following settings (IPPROTO_IP, IP_MTU_DISCOVER) and values IP_PMTUDISC_DO / IP_PMTUDISC_DONT (sets / unsets DF bit)

2) Is there any way to enable/disable transmission of UDP checksum per socket in QNX 7.0.0?

In Linux it is possible via:

setsockopt() with the following settings (SOL_SOCKET, SO_NO_CHECK) and values 1/0 (disables/enables checksum)

So far I have not found any alternatives in QNX system for the above Linux solution.

Thank you very much for the help.

post120728: Re: Ethernet errors detection

2020-06-04T13:14:31Z

Take a look at the output of the "nicinfo" command, this reports the Ethernet stats. Note that this is entirely driver dependent - different drivers report different stats.

The code for this is:

struct drvcom_stats dstats;

nic_stats_t *statp;

statp = &dstats.dcom_stats;

ifdcp->ifdc_cmd = DRVCOM_STATS;

ifdcp->ifdc_len = sizeof(*statp);

if ((ret = devctl(s, SIOCGDRVCOM, ifdcp,

    sizeof(struct drvcom_stats), NULL)) == EOK) {

dump_stats(s, statp);

}

Link state is a separate API:

#include <errno.h>

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <sys/socket.h>

#include <sys/ioctl.h>

#include <netinet/in.h>

#include <net/if.h>

int main(int argc, char **argv)

{

    int s;

    struct ifdatareq ifdata;

    if (argc != 2) {

      fprintf(stderr, "Incorrect usage\n");

      return 1;

    }

    s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

    if (s == -1 && errno != EPROTONOSUPPORT) {

      fprintf(stderr, "can't open IPv4 socket %s", strerror(errno));

      return 1;

    }

    memset(&ifdata, 0, sizeof(ifdata));

    strlcpy(ifdata.ifdr_name, argv[1], IF_NAMESIZE);

    if (ioctl(s, SIOCGIFDATA, &ifdata) == -1) {

fprintf(stderr, "ioctl failed: %s\n", strerror(errno));

exit(1);

    }

    fprintf(stdout, "Linkstate %d\n", ifdata.ifdr_data.ifi_link_state);

    return 0;

}

post120727: Ethernet errors detection

2020-06-04T09:45:41Z

Hello,

I need a way to detect any ethernet errors (e.g. crc check failed, cable unplugged, etc). Is there any api to obtain these errors programmatically? I tried to investigate io-pkt, but this tool is only allows to write and launch own drivers, but I couldn't find api to check health status of those drivers.

Thank you.

post120458: Re: devn-e1000.so or devn-82579LM.so for QNX 6.3.2

2020-04-15T12:39:56Z

You will have to request a special build of this driver through your local QNX contact, as this is not something that we have readily available.

On 2020-04-15, 8:35 AM, "Murad Sultanzadeh" <community-noreply@qnx.com> wrote:

    I needed devn-e1000.so driver for QNX 6.3.2 (or devn-82579LM.so)

    Chip name Intel I-210IT and Intel 82579LM.







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post120457

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post120457: devn-e1000.so or devn-82579LM.so for QNX 6.3.2

2020-04-15T12:35:26Z

I needed devn-e1000.so driver for QNX 6.3.2 (or devn-82579LM.so)

Chip name Intel I-210IT and Intel 82579LM.

post120384: Change packet size in the pfil hook

2020-03-20T13:32:59Z

Hi, does anybody knows is it possible to change tcp/udp packet size inside the packet filter hook?

I'm trying to add my data to the end of tcp payload, I use m_append function and as I see the mbuf is really contains my data after appending, but the server receives the original sized package without my data.

Also I tried to allocate a separate mbuf with my additional data and then to concatenate it with original buffer use m_cat, but it also didn't work.

Is it even possible?

post120292: Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?

2020-03-03T15:28:31Z

Thanks for your prompt response.

post120291: Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?

2020-03-03T15:26:40Z

It was added to io-pkt after 6.6.0 was released. Please contact your QNX support and ask them for the patch containing the fix for Issue ID 2599867

post120290: Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?

2020-03-03T14:55:26Z

Hello Reilly,

I upgraded my system to 6.6.0, but I can't find the "-D" option for io-pkt. So, is the improvement you mentioned not published ? How can I get it?

post120278: Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?

2020-02-27T15:44:41Z

Thank you again for your response. This helps a lot.

post120274: Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?

2020-02-27T13:54:09Z

Yes, this is the design of io-pkt in 6.5.0. We have improved it in later versions.

post120273: Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?

2020-02-27T07:58:22Z

Hello Reilly,

Thank you very much for your prompt reply.

I have to correct my statement on the testing steps in my initial post, that is, before we did flood test on one interface, we pulled out cable of the other.

I investigated the tracelog carefully, and now I can confirm that, for wm1, both "io-pkt#00" and "io-pkt#01" can freely switch between "stack context" processing thread and "Interrupt worker" thread, since we only have two worker threads, there is only one "interrupt worker" thread at any time, but both threads are possible to be the one and only "interrupt worker" thread, just as the document says.

But for wm0, "io-pkt#00" is always the "interrupt worker" thread and "stack context" thread, and "io-pkt#01" does NOTHING, it is always in idle state even when application socket call is blocked waiting for a io-pkt thread to service.

So, does the design of io-pkt in 6.5.0SP1 might cause this situation to happen ?

Thanks and regards

post120271: Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?

2020-02-26T17:46:18Z

io-pkt does most of its processing in "Stack Context", this is all the protocol handling plus the resource manager. In addition it does "Interrupt Worker" processing, this is usually the driver receive processing where it manages the Rx descriptor ring and then sends the packet to the actual protocol handling code - once the EtherType is processed the packet is put on the appropriate protocol queue for the "Stack Context" to handle.

In your case, "Stack Context" processing is happening on "io-pkt #0x00", wm0 Rx "Interrupt Worker" processing is also happening on "io-pkt #0x00" and wm1 "Interrupt Worker" processing is happening on "io-pkt #0x01".

Unfortunately you are running 6.5.0, in later versions we have recently added an option to io-pkt to address your scenario:

-D                - Run the resource manager/protocol layer stack context in

                    a dedicated posix thread. By default this is off. This

                    option can offer a performance improvement if you are

                    sending and receiving TCP/IP traffic from applications on

                    a multi-core system.

This was added to 6.6.0 and later with Issue ID 2599867

I suggest you contact your QNX support representative to see if you can move to 6.6.0 or later, or to see if you can get this issue added to 6.5.0

post120270: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?

2020-02-26T16:09:59Z

Altera Cyclone V SoC, dual core, Cortex-A9 architecture, QNX 6.5.0SP1, the network driver snpsmac3504 supports two interfaces on the SoC, named wm0 and wm1. io-pkt is started with "io-pkt-v4 -ptcpip -d snpsmac3504 name=wm". We can see three threads, "io-pkt main" ,"io-pkt #0x00" and "io-pkt #0x01".

When we send flood packets to wm0,  with little traffic on wm1, "io-pkt #00" consumes nearly 100% CPU time of one CPU core, and "io-pkt #01" is ALWAYS IDLE, whenever there is flood traffic on wm0 or not.

When we send flood packets to wm1,  with little traffic on wm0, both "io-pkt #00" and "io-pkt #01" consumes nearly 100% CPU time of two CPU cores, which is as expected, because we use short valid packets at a ultra high speed.

There are applications in the system which send and receive packets from wm0/wm1 in non-blocking mode. For flood on wm0, we can find so many socket calls blocked for more than hundreds of milliseconds hand shaking with "io-pkt #00". But for flood on wm1, no blocking found for socket calls, sometimes "io-pkt #00" service the socket call, sometimes "io-pkt #01" services the socket call, which is perfect as expected for a multi-core system.

But how to explain the single-thread behaviour for wm0?

Thanks and regards

post120261: Re: Unable to load packet filter lsm

2020-02-13T15:03:07Z

My vm is x86 architecture:

# uname -m

x86pc

and my lsm library has the same permissions as lsm-pf-v4.so does:

# ls -l /lib/dll/lsm-libfilter.so

-rwxrwxr-x   1 root      root           7384 Feb 13 14:43 /lib/dll/lsm-libfilter.so

# ls -l /lib/dll/lsm-pf-v4.so

-rwxrwxr-x   1 root      root         239208 Feb 28  2017 /lib/dll/lsm-pf-v4.so

my code:

#include <sys/types.h>

#include <errno.h>

#include <sys/param.h>

#include <sys/conf.h>

#include <sys/socket.h>

#include <sys/mbuf.h>

#include <net/if.h>

#include <net/pfil.h>

#include <netinet/in.h>

#include <netinet/ip.h>

#include <stdio.h>

#include <unistd.h>

#include <fcntl.h>

#include <sys/slog.h>

#include <sys/slogcodes.h>

#include "sys/io-pkt.h"

#include "nw_datastruct.h"

static int input_hook(void *arg, struct mbuf **m,

                      struct ifnet *ifp, int dir, int fib)

{

    slogf(_SLOG_SETCODE(_SLOGC_TEST, 2),

                      _SLOG_ERROR, "input");

    return 0;

}

static int output_hook(void *arg, struct mbuf **m,

                       struct ifnet *ifp, int dir, int fib)

{

    slogf(_SLOG_SETCODE(_SLOGC_TEST, 2),

                      _SLOG_ERROR, "output");

    return 0;

}

static int deinit_module(void);

static int iface_hook(void *arg, struct mbuf **m,

                      struct ifnet *ifp, int dir, int fib)

{

slogf(_SLOG_SETCODE(_SLOGC_TEST, 2),

                  _SLOG_ERROR,"Iface hook called ... ");

    if (m == (struct mbuf **)PFIL_IFNET_ATTACH) {

     slogf(_SLOG_SETCODE(_SLOGC_TEST, 2),

                       _SLOG_ERROR,"Interface attached\n");

    } else if (m == (struct mbuf **)PFIL_IFNET_DETACH) {

     slogf(_SLOG_SETCODE(_SLOGC_TEST, 2),

                       _SLOG_ERROR,"Interface detached\n");

        deinit_module();

    }

    return 0;

}

static int ifacecfg_hook(void *arg, struct mbuf **m,

                         struct ifnet *ifp, int dir, int fib)

{

slogf(_SLOG_SETCODE(_SLOGC_TEST, 2),

                  _SLOG_ERROR,"Iface cfg hook called with 0x%p\n", m);

    return 0;

}

static int deinit_module(void)

{

    struct pfil_head *pfh_inet;

    pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET);

    if (pfh_inet == NULL) {

        return ESRCH;

    }

    pfil_remove_hook(input_hook, NULL, PFIL_IN | PFIL_WAITOK,

                     pfh_inet);

    pfil_remove_hook(output_hook, NULL, PFIL_OUT | PFIL_WAITOK,

                     pfh_inet);

    pfh_inet = pfil_head_get(PFIL_TYPE_IFNET, 0);

        if (pfh_inet == NULL) {

            return ESRCH;

        }

    pfil_remove_hook(ifacecfg_hook, NULL, PFIL_IFNET, pfh_inet);

    pfil_remove_hook(iface_hook, NULL, PFIL_IFNET | PFIL_WAITOK,

                         pfh_inet);

    slogf(_SLOG_SETCODE(_SLOGC_TEST, 2),

                  _SLOG_ERROR,

  "Unloaded pfil hook\n");

    return 0;

}

int pfil_entry(void *dll_hdl, struct _iopkt_self *iopkt,

               char *options)

{

printf("pfil_entry+++++++++ enter\n");

    struct pfil_head *pfh_inet;

    pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET);

    if (pfh_inet == NULL) {

        return ESRCH;

    }

    pfil_add_hook(input_hook, NULL, PFIL_IN | PFIL_WAITOK,

                  pfh_inet);

    pfil_add_hook(output_hook, NULL, PFIL_OUT | PFIL_WAITOK,

                  pfh_inet);

    pfh_inet = pfil_head_get(PFIL_TYPE_IFNET,0);

        if (pfh_inet == NULL) {

            return ESRCH;

        }

    pfil_add_hook(iface_hook, NULL, PFIL_IFNET, pfh_inet);

    pfil_add_hook(ifacecfg_hook, NULL, PFIL_IFADDR, pfh_inet);

    slogf(_SLOG_SETCODE(_SLOGC_TEST, 2),

                      _SLOG_ERROR, "Loaded pfil hook\n");

    return 0;

}

struct _iopkt_lsm_entry IOPKT_LSM_ENTRY_SYM(pfil) =

  IOPKT_LSM_ENTRY_SYM_INIT(pfil_entry);

and Makefile:

ARTIFACT = libfilter_1.so

#Build architecture/variant string, possible values: x86, armv7le, etc...

PLATFORM ?= x86

#Build profile, possible values: release, debug, profile, coverage

BUILD_PROFILE ?= release

CONFIG_NAME ?= $(PLATFORM)-$(BUILD_PROFILE)

OUTPUT_DIR = build/$(CONFIG_NAME)

TARGET = $(OUTPUT_DIR)/$(ARTIFACT)

#Compiler definitions

CC = qcc -Vgcc_nto$(PLATFORM)

CXX = qcc -lang-c++ -Vgcc_nto$(PLATFORM)

LD = qcc -Wl,-E -Vgcc_nto$(PLATFORM)

#User defined include/preprocessor flags and libraries

INCLUDES += -I /home/yona/qnx700/target/qnx7/usr/include/io-pkt/

#INCLUDES += -I/path/to/my/lib/include

#INCLUDES += -I../mylib/public

#LIBS += -L/path/to/my/lib/$(PLATFORM)/usr/lib -lmylib

#LIBS += -L../mylib/$(OUTPUT_DIR) -lmylib

#Compiler flags for build profiles

CCFLAGS_release += -O2 -D_KERNEL -DQNX_MFIB

CCFLAGS_debug += -g -O0 -fno-builtin

CCFLAGS_coverage += -g -O0 -ftest-coverage -fprofile-arcs -nopipe -Wc,-auxbase-strip,$@

LDFLAGS_coverage += -ftest-coverage -fprofile-arcs

CCFLAGS_profile += -g -O0 -finstrument-functions

LIBS_profile += -lprofilingS

#Generic compiler flags (which include build type flags)

CCFLAGS_all += -Wall -fmessage-length=0

CCFLAGS_all += $(CCFLAGS_$(BUILD_PROFILE))

#Shared library has to be compiled with -fPIC

CCFLAGS_all += -fPIC

LDFLAGS_all += $(LDFLAGS_$(BUILD_PROFILE))

LIBS_all += $(LIBS_$(BUILD_PROFILE))

DEPS = -Wp,-MMD,$(@:%.o=%.d),-MT,$@

#DEPS = -Wl,-E

#Macro to expand files recursively: parameters $1 -  directory, $2 - extension, i.e. cpp

rwildcard = $(wildcard $(addprefix $1/*.,$2)) $(foreach d,$(wildcard $1/*),$(call rwildcard,$d,$2))

#Source list

SRCS = $(call rwildcard, src, c)

#Object files list

OBJS = $(addprefix $(OUTPUT_DIR)/,$(addsuffix .o, $(basename $(SRCS))))

#Compiling rule

$(OUTPUT_DIR)/%.o: %.c

@mkdir -p $(dir $@)

$(CC) -c $(DEPS) -o $@ $(INCLUDES) $(CCFLAGS_all) $(CCFLAGS) $<

#Linking rule

$(TARGET):$(OBJS)

$(LD) -shared -o $(TARGET) $(LDFLAGS_all) $(LDFLAGS) $(OBJS) $(LIBS_all) $(LIBS)

#Rules section for default compilation and linking

all: $(TARGET)

clean:

rm -fr $(OUTPUT_DIR)

rebuild: clean all

#Inclusion of dependencies (object files to source and includes)

-include $(OBJS:%.o=%.d)

what could be the issue? Does QNX have more detailed documentation about packet filter development?

post120259: Re: Unable to load packet filter lsm

2020-02-13T14:34:21Z

Either the dlopen() isn't able to open your library (bad path to it, bad permissions, built for the wrong processor type etc) or the dlsym() isn't finding the "iopkt_lsm_entry" symbol that is generated by the line at the end of the file:

struct _iopkt_lsm_entry IOPKT_LSM_ENTRY_SYM(pfil) =

IOPKT_LSM_ENTRY_SYM_INIT(pfil_entry);

post120257: Re: Unable to load packet filter lsm

2020-02-13T08:43:05Z

I added extra logs, but it looks like lsm loading failed before my code execution. Maybe I do something wrong, but I didn't find any more information about packet filter development in official documentation.

I just want to intercept network traffic from/to my network device.

post120254: Re: Unable to load packet filter lsm

2020-02-12T17:56:01Z

io-pkt will call the entry function in the lsm so add some debugging prints to that to determine what is going wrong.

post120253: Re: Unable to load packet filter lsm

2020-02-12T16:45:38Z

I added those defines and warnings gone. But I still have the same error by lsm mount.

post120252: Re: Unable to load packet filter lsm

2020-02-12T13:59:31Z

Take a look at net/pfil.h and you will find all those warnings you are getting are because you are building without _KERNEL and QNX_MFIB defined. If you define those then that should clean up your warnings and the symbols should then correspond to those in io-pkt and your code should work.

post120251: Unable to load packet filter lsm

2020-02-12T13:48:10Z

I'm trying to compile and load the simple packet filter from documentation (http://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx.doc.core_networking/topic/filtering_PF.html)

I use SDP 7.0 and RTOS vm on vmware also 7.0 version.

the code compiles successfully:

qcc -Wl,-E -Vgcc_ntox86 -c -Wp,-MMD,build/x86-release/src/filter_1.d,-MT,build/x86-release/src/filter_1.o -o build/x86-release/src/filter_1.o -I /home/alexandr/qnx700/target/qnx7/usr/include/io-pkt/ -Wall -fmessage-length=0 -O2 -fPIC  src/filter_1.c

src/filter_1.c: In function 'deinit_module':

src/filter_1.c:67:16: warning: implicit declaration of function 'pfil_head_get' [-Wimplicit-function-declaration]

     pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET);

                ^

src/filter_1.c:67:14: warning: assignment makes pointer from integer without a cast [-Wint-conversion]

     pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET);

              ^

src/filter_1.c:71:5: warning: implicit declaration of function 'pfil_remove_hook' [-Wimplicit-function-declaration]

     pfil_remove_hook(input_hook, NULL, PFIL_IN | PFIL_WAITOK,

     ^

src/filter_1.c:75:14: warning: assignment makes pointer from integer without a cast [-Wint-conversion]

     pfh_inet = pfil_head_get(PFIL_TYPE_IFNET, 0);

              ^

src/filter_1.c: In function 'pfil_entry':

src/filter_1.c:95:14: warning: assignment makes pointer from integer without a cast [-Wint-conversion]

     pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET);

              ^

src/filter_1.c:99:5: warning: implicit declaration of function 'pfil_add_hook' [-Wimplicit-function-declaration]

     pfil_add_hook(input_hook, NULL, PFIL_IN | PFIL_WAITOK,

     ^

src/filter_1.c:104:14: warning: assignment makes pointer from integer without a cast [-Wint-conversion]

     pfh_inet = pfil_head_get(PFIL_TYPE_IFNET,0);

              ^

qcc -Wl,-E -Vgcc_ntox86 -shared -o build/x86-release/libfilter_1.so   build/x86-release/src/filter_1.o

but when I try to load my lsm:

# mount -vvv -Tio-pkt /root/lsm-filter.so

Parsed: mount from [/root/lsm-filter.so] mount on [NULL] type [io-pkt]

exec: mount_io-pkt -o rw -o implied -o nostat /root/lsm-filter.so /

Using internal mount (mount_io-pkt not found)

Type    [io-pkt] Flags 0x80080000

Device  [/root/lsm-filter.so] Directory [/]

Options [NULL]

mount: Can't mount / (type io-pkt)

mount: Possible reason: No such device or address

and in slog I can see only such line:

Feb 12 13:48:15.543                    iopkt.81934          main_buffer      0  Unable to load /root/lsm-filter.so: (null)

did anybody face such problem? could anybody help me with this?

post120128: Re: QNX6.6 imx6 WiFi driver for ublox

2019-12-26T14:56:34Z

Thanks Niraj,

Yes, I'm based in Italy, and I do not know who is our FAE, if one exist.

We are supported by a local Qnx partner, but it is more a commercial

support than a technical one: they have proposed to me  a full qnx

wireless framework just to have a wi-fi module driver.

For technical questions I use our standard Qnx support or I dig in the ng :-)

- Our platform uses an imx6 SOM, we have an SDIO slot or a mPCIe slot

- We are interested in both features, WiFi and BT (SPP profile only)

  but we can support BT via other dedicated chip that we have already used,

  so BT is not a problem .

- For now, WiFi only. STA/AP/P2P could be used in the future under customer

  request.

- Ok for NDA, if customer agree  with terms.

- We can interface the module via SDIO and UART for BT

Thanks, again

Mario

post120123: Re: QNX6.6 imx6 WiFi driver for ublox

2019-12-20T20:10:01Z

Hi Mario,

I think you are based in Italy, right ? Do you know who is your FAE ? I am trying to contact your FAE so that he can contact you. Looks like they are gone for holidays. In the meantime, I got some  info/questions from Engineering to get more clarification.

The u-blox EMMY-W1 has a Marvell 8887 chipset in it.

We do support this for our CSP customers.

Need information such as:

- what is the target platform?  The Marvell 8887 uses an SDIO connection and we currently support on i.mx6

- what features are of interest?  BT and WIFI?

- WIFI only?  STA mode, AP mode, P2P mode?

- we have an experimental 8887 driver on SDP 6.6.   There is a newer version of the driver/ firmware available on SDP 7.0.

- I believe we need to ensure an NDA is in place between Marvell and the company in question in order to provide the binaries.

- Which interface (SDIO or UART) is used for Bluetooth for Marvell 8887 on ublox EMMY_W1xx?

Please reply these questions at your convenience and your FAE will take over once he comes back.

Thanks,

- Niraj

post120111: Re: QNX6.6 imx6 WiFi driver for ublox

2019-12-16T08:43:23Z

Niraj  Thank You very much,

My company is Tecnint HTE, we develops custom hardware solutions and

in this case we are proposing an imx6 SOM with  QNX6.6 for this project.

Customer needs also wiFi and BT,  one module should be  the  Ublox EMMY-W1

(Chip Marvell 88W8887), that has a qnx driver (or so it is declared in the data sheet),

so we prefer to use this one, or equivalent, if it is supported.

Any help will be appreciate,

Thanks again

M. Sangalli

post120110: Re: QNX6.6 imx6 WiFi driver for ublox

2019-12-13T18:53:53Z

Hi Mario,

I am FAE at QNX. Which chipset is in ublox EMMY-W1xx ? Would you mind providing your company name ? Which QNX version you are using ?

Thanks,

Niraj

post120108: QNX6.6 imx6 WiFi driver for ublox

2019-12-12T16:41:03Z

Hi, is some wifi driver available for such patform ?

I've found one for ti-wiLink8, we are evaluating the ublox EMMY-W1xx module,

on data-sheet seens that a qnx driver is available , where I can get it?

Thanks

M. Sangalli

post119831: Re: ptpd very long synchronisation time

2019-08-23T19:43:53Z

Hi Nick,

Yes, it does seem like that but as I said in my original post I am starting the e1000 driver with the ptp flag. All my testing has been with the -C flag to see the statistics and I always see the following when ptpd and ptpd-avb start up

(ptpd notice) 16:04:47.562025 (init) hardware time support = 1,

To be clear, when I use ptpd the clocks converge to < 1us offset with +/-1us jitter so I am pretty sure hardware timestamping is enabled.

Regards,

John

post119830: Re: ptpd very long synchronisation time

2019-08-23T18:12:37Z

Hi John,

That almost sounds like it is using software timestamping rather than hardware timestamping. When you load the e1000 driver are you passing "ptp" as an option to it? If you run ptpd with console logging on (-C option) is it showing hardware or software in the startup message?

Regards,

Nick

post119827: Re: ptpd very long synchronisation time

2019-08-23T10:24:55Z

Hi Lomash,

Even with your numbers I cannot get ptpd-avb to synchronise properly with the ptp4l master. I find that the slave clock converges to about 500us from the master clock and then begins oscillate between 500us and 1500us.

Thanks for your help on this. I'll try again once I have the latest software.

Regards,

John

post119822: Re: ptpd very long synchronisation time

2019-08-22T16:27:55Z

I have neighborPropDelayThresh configured at 50000 and min_neighbor_prop_delay at -20000000

post119821: Re: ptpd very long synchronisation time

2019-08-22T15:53:41Z

Hi Lomash,

Could you tell me what values you used for these parameters, please?

John

post119820: Re: ptpd very long synchronisation time

2019-08-22T14:51:51Z

I have had good results while running ptpd-avb on a QNX machine as the slave and directly connected to an Ubuntu 18.04 machine running ptp4l with the gPTP config. But for this to work reliably, I had to update the neighborPropDelayThresh and min_neighbor_prop_delay parameters to appropriate values on the linux side.

I would also recommend using the 7.0.4 release.

post119819: Re: ptpd very long synchronisation time

2019-08-21T20:01:22Z

Hi Lomash,

> Our test records indicate a sync time of 9 minutes while running ptpd and

> about 5 when running ptpd-avb.

Thanks for the data.

> Regarding ptpd-avb not syncing, are you using ptpd-avb as the master? If so,

> we recently discovered a bug in the implementation which affects time sync. So

> , you could ask QNX support for an experimental release with the fix for JI:

> 2773204.

Yes, I was using ptpd-avb as the master. I will ask for this release

> However, ptpd-avb should still be able to sync with a ptp4l master without the

> fix.You could try that out.

I have tried and got mixed results. I did see it synchronise once but most of the time it does not. More specifically, the slave clock diverges from the master rather than converging.

Most of my tests were using P2P with direct cable connection between master and slave interfaces. I am using ptp4l version 1.6 on Ubuntu 16.04 with i210 master.

What is your test configuration?

John

post119818: Re: ptpd very long synchronisation time

2019-08-21T19:12:53Z

Hi John,

Our test records indicate a sync time of 9 minutes while running ptpd and about 5 when running ptpd-avb.

Regarding ptpd-avb not syncing, are you using ptpd-avb as the master? If so, we recently discovered a bug in the implementation which affects time sync. So, you could ask QNX support for an experimental release with the fix for JI:2773204.

However, ptpd-avb should still be able to sync with a ptp4l master without the fix.You could try that out.

Thanks,

Lomash

post119817: ptpd very long synchronisation time

2019-08-21T16:30:21Z

Hello,

I am running ptpd with an Intel i210 to synchronise a PTP slave. The e1000 driver is started with the ptp flag so the hardware timestamp support in the i210 is enabled.

I'm starting ptpd in foreground to see the statistics on the console as follows:

# ptpd -C -g -L -b wm0

The ptpd takes a very long time to synchronise the slave PTP time to the master - anything from several minutes to more than 10 minutes. The time required to converge the clocks appears to be dependent on the initial clock offset. For example, If the offset is tens or hundreds of milliseconds the convergence is linear until the offset less than one millisecond at which point it takes a non-linear path, still slowly.

By comparison, Linux ptp4l takes about 30 seconds to synchronise the clocks regardless of the initial clock offset.

The PTP master in my configuration is another QNX system with an i210 interface with hardware timestamps enabled. The same behaviour is seen if the master is a Linux machine running ptp4l.

I've tried E2E and P2P - behaviour is the same.

ptpd-avb appears to be broken - the slave does not syncrhonise at all.

I am using the generic x86_64 BSP on a Skylake target board. My ptpd is from package com.qnx.sdp.target.net.ptp/7.0.1031.S201810151344

I have also tried teh new SDP 7.0.4 release (com.qnx.sdp.target.net.ptp/7.0.4247.S201906281113) but the behaviour is the same.

Is the behaviour I am seeing normal for QNX ptpd?

If not, what is the expected QNX ptpd slave convergence time? 10 minutes is way too long to be useful.

Thanks,

John

post119811: Re: Intel I211 driver for QNX 6.5

2019-08-20T00:18:42Z

Got it. Thank you.

post119810: Re: Intel I211 driver for QNX 6.5

2019-08-19T12:51:34Z

I have attached a desktop build of the latest e1000 driver.

On 2019-08-19, 1:37 AM, "Kok Keong Neo" <community-noreply@qnx.com> wrote:

    Hi, where can I get the latest working the network driver for Intel I211 0x1539?



    I am using the current driver in QNX 6.5.0 SP1 devnp-e1000.so but it cannot find I211







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119809

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119809: Intel I211 driver for QNX 6.5

2019-08-19T05:38:06Z

Hi, where can I get the latest working the network driver for Intel I211 0x1539?

I am using the current driver in QNX 6.5.0 SP1 devnp-e1000.so but it cannot find I211

post119798: Re: ifconfig command does not show all the interface after adding new interface

2019-07-30T20:29:19Z

Is your sam driver actually successfully creating an interface?

post119795: Re: ifconfig command does not show all the interface after adding new interface

2019-07-30T18:17:10Z

for some reason I do not see newly added interface even if I provide the prefix

-----------------

# io-pkt-v6-hc -i1 -dsam -p tcpip prefix=/alt

# ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

        inet 127.0.0.1 netmask 0xff000000

        inet6 ::1 prefixlen 128

        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500

        address: 5e:24:04:00:7e:dd

        media: Ethernet 100baseTX full-duplex

        status: active

        inet 10.10.70.189 netmask 0xfffffe00 broadcast 10.10.71.255

        inet6 fe80::5c24:4ff:fe00:7edd%en0 prefixlen 64 scopeid 0x2

# SOCK=/alt ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

        inet 127.0.0.1 netmask 0xff000000

        inet6 ::1 prefixlen 128

        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

# ls -l /alt/dev/socket/

total 0

srw-rw-rw-  1 root      root              0 Jan 07 22:04 1

srw-rw-rw-  1 root      root              0 Jan 07 22:04 17

....

----------------------------------------------

post119789: Re: ifconfig command does not show all the interface after adding new interface

2019-07-27T00:36:11Z

There are some important parameters missing in the startup of the 2nd io-pkt that are causing it to clobber the 1st invocation of io-pkt.

1st stack (instance 0) startup is fine:

# io-pkt-v4-hc -dsmsc9500 mac=5e2404007edd

# ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

        inet 127.0.0.1 netmask 0xff000000

en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500

        address: 5e:24:04:00:7e:dd

        media: Ethernet 100baseTX full-duplex

        status: active

        inet 10.10.70.189 netmask 0xff000000 broadcast 10.255.255.255

#

2nd stack needs both an instance and a prefix so it does not clobber the 1st (instance 0) stack:

# io-pkt-v6-hc -i1 -dsam -p tcpip prefix=/alt

# SOCK=/alt ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

        inet 127.0.0.1 netmask 0xff000000

        inet6 ::1 prefixlen 128

        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

sam0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500

        address: 00:01:02:03:04:05

#

For all commands referencing the 1st stack (instance 0), issue them directly without a SOCK environment variable.

For all commands referencing the 2nd stack (instance 1 at prefix /alt), the SOCK=/alt environment variable is needed.

Prefixes other than '/alt' can be used -- reference the io-pkt documentation for use of the prefix parameter.

post119788: Re: ifconfig command does not show all the interface after adding new interface

2019-07-26T22:15:31Z

My goal is to start two network stacks io-pkt-v4-hc (habdling ipv4 only) and io-pkt-v6-hc (for ipv6)

and make sure that it is shown in ifconfig.

in the above command sequence, even if I run "mount -T io-pkt devnp-sam.so"

ifconfig does not show en0 interface at all.

See command/output below below

(1) Why ifconfig not showing en0? pidin shows both stacks running.

(2) I want make two separate interfaces one for ipv4 (exclusively for ipv4) and other ipv6. What are the correct steps.

----------------------------------------------------

# io-pkt-v4-hc -dsmsc9500 mac=5e2404007ede

# ifconfig en0 10.10.70.189

# ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

        inet 127.0.0.1 netmask 0xff000000

en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500

        address: 5e:24:04:00:7e:de

        media: Ethernet 100baseTX full-duplex

        status: active

        inet 10.10.70.189 netmask 0xff000000 broadcast 10.255.255.255

# io-pkt-v6-hc

# mount -T io-pkt devnp-sam.so

# ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

        inet 127.0.0.1 netmask 0xff000000

        inet6 ::1 prefixlen 128

        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

sam0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500

        address: 00:01:02:03:04:05

# pidin arg

     pid Arguments

    ......

   49170 io-pkt-v4-hc -dsmsc9500 mac=5e2404007edd

   69651 io-pkt-v6-hc

  102420 pidin arg

------------------------------------------------------------------------------------------

post119787: Re: ifconfig command does not show all the interface after adding new interface

2019-07-26T07:30:16Z

Hi Rajesh

By calling io-pkt-v6-hc you are starting a new network stack with no interfaces except lo0.

To add a new network interface to a running stack you must use the mount command:

mount -T io-pkt devnp-sam.so

post119786: ifconfig command does not show all the interface after adding new interface

2019-07-25T19:11:03Z

I am using panda board for adding new network driver.

for showing example I used Sample Driver (sam.c) provided by qnx.

But following result can be reproduce with other drivers too.

here is the excerpts of the command i ran  and  text added between /*  */ are my comments.

As you see below, en0 interface disappears as soon as another new driver is added.

Is there anything 'ifconfig' looking for? Why it is not showing all the interfaces?

--------------------------------------------------------------------------------------------------------------------------

# io-pkt-v4-hc -dsmsc9500 mac=5e2404007ede          /* Loading the ethernet driver */

# ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

        inet 127.0.0.1 netmask 0xff000000

en0: flags=80008802<BROADCAST,SIMPLEX,MULTICAST,SHIM> mtu 1500

        address: 5e:24:04:00:7e:de

        media: Ethernet 100baseTX full-duplex

        status: active

# ifconfig en0 10.10.70.189

# ifconfig                                                                       /* ifconfig correctly shows the two interfaces lo0 and en0)

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

        inet 127.0.0.1 netmask 0xff000000

en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500

        address: 5e:24:04:00:7e:dd

        media: Ethernet 100baseTX full-duplex

        status: active

        inet 10.10.70.189 netmask 0xff000000 broadcast 10.255.255.255

# io-pkt-v6-hc -i1 -dsam                                                  /* loading the second driver (sample driver) */

# ifconfig                                                                         /* it shows sam0 correctly but en0 disappeard !!!! */

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192

        inet 127.0.0.1 netmask 0xff000000

        inet6 ::1 prefixlen 128

        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

sam0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500

        address: 00:01:02:03:04:05

------------------------------------------------------------------------------------------------------------------------

post119782: Re: Intel I219 Gigabit ethernet support in devnp-e1000.so ?

2019-07-22T07:38:34Z

When I used this driver, it reported the following error.

"ldd:FATAL: Unresolved symbol "stk_context_callback_2" called from devnp-e1000.so"

but with the latest networking manager io-pkt-v4-hc you provided, it works fine.

Hugh，thank you for your help.

> I have attached a desktop build of the latest 6.5.0 e1000 driver.

>

> Hugh.

>

> On 2019-07-19, 5:54 AM, "chen Wang" <community-noreply@qnx.com> wrote:

>

>     Can the devnp-e1000.so driver in the accessory be used in the QNX 6.5.0

> SP1?

>     > Driver is attached.

>     >

>     >

>     >

>     > On 2016-11-17, 11:17 AM, "Davide Ancri" <community-noreply@qnx.com> wrote:

>     >

>     > >great news Hugh!

>     > >

>     > >a desktop build would be really nice for completing my tests, then we

>     > >will wait the official one for the product release.

>     > >

>     > >thanks a lot!

>     > >Davide

>     > >

>     > >> This device is supported in the latest 6.6.0 e1000 driver. If you

> want

>     > >>the

>     > >> official version, you will have to request it through your sales rep,

>

>     > >> otherwise I can give you a desktop build of the driver.

>     > >>

>     > >>

>     > >>

>     > >> On 2016-11-17, 10:33 AM, "Davide Ancri" <community-noreply@qnx.com>

>     > >>wrote:

>     > >>

>     > >> >hi all

>     > >> >

>     > >> >I'm trying to play with a new pc card mounting an embedded Intel

> I219

>     > >> >Gigabit ethernet device:

>     > >> >

>     > >> >Class          = Network (Ethernet)

>     > >> >Vendor ID      = 8086h, Intel Corporation

>     > >> >Device ID      = 156fh, Unknown Unknown

>     > >> >

>     > >> >but devnp-e1000.so (qnx 6.6) cannot recognize it.

>     > >> >

>     > >> >Anyone knows if I219 support is planned in future e1000 version?

>     > >> >Or maybe is there a beta version already supporting it?

>     > >> >

>     > >> >thanks a lot

>     > >> >Davide

>     > >> >

>     > >> >

>     > >> >

>     > >> >_______________________________________________

>     > >> >

>     > >> >Networking Drivers

>     > >> >http://community.qnx.com/sf/go/post117134

>     > >> >To cancel your subscription to this discussion, please e-mail

>     > >> >drivers-networking-unsubscribe@community.qnx.com

>     > >>

>     > >

>     > >

>     > >

>     > >

>     > >

>     > >

>     > >_______________________________________________

>     > >

>     > >Networking Drivers

>     > >http://community.qnx.com/sf/go/post117136

>     > >To cancel your subscription to this discussion, please e-mail

>     > >drivers-networking-unsubscribe@community.qnx.com

>     >

>

>

>

>

>

>

>     _______________________________________________

>

>     Networking Drivers

>     http://community.qnx.com/sf/go/post119780

>     To cancel your subscription to this discussion, please e-mail drivers-

> networking-unsubscribe@community.qnx.com

>

>

post119781: Re: Intel I219 Gigabit ethernet support in devnp-e1000.so ?

2019-07-19T12:31:25Z

I have attached a desktop build of the latest 6.5.0 e1000 driver.

Hugh.

On 2019-07-19, 5:54 AM, "chen Wang" <community-noreply@qnx.com> wrote:

    Can the devnp-e1000.so driver in the accessory be used in the QNX 6.5.0 SP1?

    > Driver is attached.

    >

    >

    >

    > On 2016-11-17, 11:17 AM, "Davide Ancri" <community-noreply@qnx.com> wrote:

    >

    > >great news Hugh!

    > >

    > >a desktop build would be really nice for completing my tests, then we

    > >will wait the official one for the product release.

    > >

    > >thanks a lot!

    > >Davide

    > >

    > >> This device is supported in the latest 6.6.0 e1000 driver. If you want

    > >>the

    > >> official version, you will have to request it through your sales rep,

    > >> otherwise I can give you a desktop build of the driver.

    > >>

    > >>

    > >>

    > >> On 2016-11-17, 10:33 AM, "Davide Ancri" <community-noreply@qnx.com>

    > >>wrote:

    > >>

    > >> >hi all

    > >> >

    > >> >I'm trying to play with a new pc card mounting an embedded Intel I219

    > >> >Gigabit ethernet device:

    > >> >

    > >> >Class          = Network (Ethernet)

    > >> >Vendor ID      = 8086h, Intel Corporation

    > >> >Device ID      = 156fh, Unknown Unknown

    > >> >

    > >> >but devnp-e1000.so (qnx 6.6) cannot recognize it.

    > >> >

    > >> >Anyone knows if I219 support is planned in future e1000 version?

    > >> >Or maybe is there a beta version already supporting it?

    > >> >

    > >> >thanks a lot

    > >> >Davide

    > >> >

    > >> >

    > >> >

    > >> >_______________________________________________

    > >> >

    > >> >Networking Drivers

    > >> >http://community.qnx.com/sf/go/post117134

    > >> >To cancel your subscription to this discussion, please e-mail

    > >> >drivers-networking-unsubscribe@community.qnx.com

    > >>

    > >

    > >

    > >

    > >

    > >

    > >

    > >_______________________________________________

    > >

    > >Networking Drivers

    > >http://community.qnx.com/sf/go/post117136

    > >To cancel your subscription to this discussion, please e-mail

    > >drivers-networking-unsubscribe@community.qnx.com

    >













    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119780

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119780: Re: Intel I219 Gigabit ethernet support in devnp-e1000.so ?

2019-07-19T09:54:51Z

Can the devnp-e1000.so driver in the accessory be used in the QNX 6.5.0 SP1?

> Driver is attached.

>

>

>

> On 2016-11-17, 11:17 AM, "Davide Ancri" <community-noreply@qnx.com> wrote:

>

> >great news Hugh!

> >

> >a desktop build would be really nice for completing my tests, then we

> >will wait the official one for the product release.

> >

> >thanks a lot!

> >Davide

> >

> >> This device is supported in the latest 6.6.0 e1000 driver. If you want

> >>the

> >> official version, you will have to request it through your sales rep,

> >> otherwise I can give you a desktop build of the driver.

> >>

> >>

> >>

> >> On 2016-11-17, 10:33 AM, "Davide Ancri" <community-noreply@qnx.com>

> >>wrote:

> >>

> >> >hi all

> >> >

> >> >I'm trying to play with a new pc card mounting an embedded Intel I219

> >> >Gigabit ethernet device:

> >> >

> >> >Class          = Network (Ethernet)

> >> >Vendor ID      = 8086h, Intel Corporation

> >> >Device ID      = 156fh, Unknown Unknown

> >> >

> >> >but devnp-e1000.so (qnx 6.6) cannot recognize it.

> >> >

> >> >Anyone knows if I219 support is planned in future e1000 version?

> >> >Or maybe is there a beta version already supporting it?

> >> >

> >> >thanks a lot

> >> >Davide

> >> >

> >> >

> >> >

> >> >_______________________________________________

> >> >

> >> >Networking Drivers

> >> >http://community.qnx.com/sf/go/post117134

> >> >To cancel your subscription to this discussion, please e-mail

> >> >drivers-networking-unsubscribe@community.qnx.com

> >>

> >

> >

> >

> >

> >

> >

> >_______________________________________________

> >

> >Networking Drivers

> >http://community.qnx.com/sf/go/post117136

> >To cancel your subscription to this discussion, please e-mail

> >drivers-networking-unsubscribe@community.qnx.com

>

post119779: Re: Intel I219 Gigabit ethernet support in devnp-e1000.so ?

2019-07-19T09:52:09Z

Hi Hugh,Does the intel i219 have a driver that supports QNX 6.5.0 sp1?

post119730: Re: RTL8812BU USB Wifi driver

2019-06-05T18:00:37Z

Yeah. I have a board design based upon the Octavo AM335x in development. We have provision for SDIO for the WiLink8. Short term I need a USB solution.

post119729: Re: RTL8812BU USB Wifi driver

2019-06-05T17:48:49Z

If you are looking for USB WiFi under 6.5.0, then the only ones are the old Ralink etc.

The Wilink8 driver isn't a USB driver.

On 2019-06-05, 1:17 PM, "Todd Peterson(deleted)" <community-noreply@qnx.com> wrote:

    Thanks. Is there a current list of supported wifi chipsets? The ones that are installed with QNX6.5 are really old Ralink chipsets. I did find a WiLink8 driver. Will try to find an appropriate device to try it out.







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119728

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119728: Re: RTL8812BU USB Wifi driver

2019-06-05T17:17:45Z

Thanks. Is there a current list of supported wifi chipsets? The ones that are installed with QNX6.5 are really old Ralink chipsets. I did find a WiLink8 driver. Will try to find an appropriate device to try it out.

post119727: Re: RTL8812BU USB Wifi driver

2019-06-05T14:14:37Z

AFAIK, we have no intention to support this device. It would require several months of development.

On 2019-05-31, 6:17 PM, "Todd Peterson(deleted)" <community-noreply@qnx.com> wrote:

    For ARM Beagleboard (DM3730), Beaglebone Black or Pocket Beagle (AM335x). Running QNX 6.5 on Beagleboard or 6.6 on the last two. Does this driver exist? If not, how much work is required to make it work?



    The critter works on Linux on those boards.



    Here a link to the actual device that I have in hand.



    https://www.amazon.com/Realtek-RTL8192AU-Wireless-Adapter-Antenna/dp/B078NSSM7W



    Any help is greatly appreciated.



    Thanks,

    Todd







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119714

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119714: RTL8812BU USB Wifi driver

2019-05-29T04:17:38Z

For ARM Beagleboard (DM3730), Beaglebone Black or Pocket Beagle (AM335x). Running QNX 6.5 on Beagleboard or 6.6 on the last two. Does this driver exist? If not, how much work is required to make it work?

The critter works on Linux on those boards.

Here a link to the actual device that I have in hand.

https://www.amazon.com/Realtek-RTL8192AU-Wireless-Adapter-Antenna/dp/B078NSSM7W

Any help is greatly appreciated.

Thanks,

Todd

post119695: Re: io-pkt thread context nightmare

2019-05-06T10:32:52Z

Hello Nick,

thanks for your detailed explanation.

Now things got much clearer to me.

What a high price to make the netbsd stuff usable for a clean structured realtime OS...

Thanks again

Michael

post119694: Relationship between pagesize and mclbytes

2019-05-06T08:13:45Z

I want to support 9000 byes jumbo frames and want to create clusters with 9000 byte buffers.

Is setting mclbytes to 9000 the right way to do this?

What value should pagesize be set to for optimum performance?

In the Core Networking Guide the jumbo frames example should both parameters set to 8192 to support a jumbo MTU of 8100 but does not explain the significance of the pagesize value or its relationship to mclbytes.

post119690: Re: dev_attach parameters

2019-05-01T15:23:47Z

I'll add this information to the docs.

post119689: Re: dev_attach parameters

2019-05-01T15:22:05Z

Hi Nick,

Thanks - exactly what I was after!

Regards,

John

post119688: Re: dev_attach parameters

2019-05-01T14:17:07Z

Hi John,

Here's the function signature:

int

dev_attach(char *drvr, char *options, struct cfattach *ca,

void *cfat_arg, int *single, struct device **devp,

int (*print)(void *, const char *))

drvr is a string that is used for the interface name e.g. "sc" ends up creating an interface "sc0" by default.

options is the options string that was passed to the driver - this is parsed by dev_attach() looking for "name", "lan" and "unit" options which will override the the default naming of the interface. "lan" and "unit" are identical in meaning and will override the number appended to the interface naming rather than it just being a sequential number of all the ones of that type. "name" overrides the "drvr" string.

ca is the structure formed by the CFATTACH_DECL() macro which specifies the size of the device structure and the attach and detach functions.

cfat_arg is the attach arg - comes through to the driver attach function as parameter 3

single isn't really used, if the "lan" or "unit" option is in the options string then it gets set to 1, but that's it.

devp is used in two ways. First of all if it is set to non-NULL on entry then it specifies the parent device that this device is a child of. I don't recall a driver ever actually using this - there is a check on removal that the device being removed is not the parent of any remaining devices. All drivers I have seen set it to NULL to specify that there is no parent. Secondly it is set as a pointer to the dev structure that is also passed to the attach function as parameter 2 so is a way of retrieving the device structure after the call to dev_attach - again I don't recall any driver using this. I have seen a bugs where this was not initialised and luckily pointed to NULL until a code change was made when it pointed to a random value and caused the driver to crash, so please set it to NULL!

print I've never seen used, always set to NULL. dev_attach() actually does:

if (print != NULL)

(*print)(cfat_arg, NULL);

so I suppose you could use it for debugging.

Regards,

Nick.

post119687: dev_attach parameters

2019-05-01T09:38:51Z

Can someone provide a definitive description of the parameters taken by dev_attach()?

There are several posts in this forum that have asked this question going back to 2009 but no clear answer that I can find.

In particular, what does dev_attach() do with the 5th, 6th parameters? What are the expected values and how/when are they updated by dev_attach().

How is the 7th parameter used?

Thanks,

John

post119686: Re: io-pkt thread context nightmare

2019-04-30T13:50:27Z

All driver callbacks expect to run in stack context with the exception of receive and start (transmit), so the following expect to be in stack context:

Driver entry

Attach

Detach

Init

Stop

Ioctl

The driver receive function runs in an interrupt worker context. While the driver start function is often called from stack context, it must also be capable of running from interrupt worker context - in the case of bridging or fast forwarding then the Rx on the ingress interface will directly call the Tx on the egress interface without passing in to stack context.

You may be lucky and have some driver callbacks not fail when called from a context other than stack context, but this is just luck with that particular driver.

Stack context is single threaded but with multiple coroutines in a run to completion model, but the coroutines may choose to yield to avoid blocking stack context (which could block traffic on other interfaces that needs stack context). The stack context coroutines yield by calling ltsleep(), and nic_delay() is a wrapper for this. The e1000 driver (and most drivers) use this when waiting for hardware. The nic_mutex() call is used to serialise operations to the hardware - think of it as a standard mutex that works across stack context coroutines, but note that it introduces a yielding point as it may not be able to acquire the lock.

To answer your other questions:

The memcpy() isn't going to yield stack context or access the hardware so it doesn't need to be inside the mutex, nic_mutex() is taken around the update stats call because that is going to read hardware and we need to ensure that other operations are not happening on the hardware at the same time.

ifq_enqueue(ifp,m) is potentially going to call the driver start routine. While this doesn't need to be in stack context, it does need to be an mbuf handling thread - so an nw_pthread and not just a pthread.

mbufs should only be touched from nw_pthreads and not plain pthreads, but note that an nw_pthread needs to have a quiesce function for when io-pkt is updating certain structures. Ensuring that the quiesce can happen in a multi-threaded scenario takes careful planning to avoid deadlocking.

Please name any threads that you do create - by default they get an io-pkt#0x01 style name which makes people think that they are io-pkt threads and not that they belong to an lsm!

Regards,

Nick

post119685: Re: io-pkt thread context nightmare

2019-04-30T10:07:32Z

Hi Nick,

> Relying on the io-pkt resource manager places everything in the stack context

> and thus the concerns I mentioned in my earlier message with performance, both

>  io-pkt affecting your code and your code affecting io-pkt. Best performance

> would be to run in your own thread with your own resource manager and only do

> the stk_context_callback_2(), kthread_create1()  dance for those pieces of

> code that need to run in io-pkt stack context.

the problem is finding out, which functions have to be called in stack context and which have not.

Unfortunately this can be driver dependent. e.g. Our lsm sometimes reads the statistic counters with a simple direct call (ifp->if_ioctl()) to the driver. Here we got the assertion in the devctl part of the QNX7 e1000 driver, using a nic_mutex:

                                case    DRVCOM_STATS:

                                        dstp = (struct drvcom_stats *)ifdc;

                                        if (ifdc->ifdc_len != sizeof (nic_stats_t)) {

                                                error = EINVAL;

                                                break;

                                                }

                                        nic_mutex_lock (&i82544->drv_mutex);

                                        update_stats (i82544);

                                        nic_mutex_unlock (&i82544->drv_mutex);

                                        memcpy (&dstp->dcom_stats, &i82544->stats, sizeof (i82544->stats));

                                        break;

This e1000 driver seems to expect more than one thread of the BSD-scheduler could run through this ioctl. ?! Is that possible?

Is there a rule? e.g. : "You must call the ioctl entry of a driver with the stack-context!" ????

BTW.: Why is the memcpy() not in the critical section. OK, let us hope, src and dest is aligned and the memcpy() does not copy by moving bytes. ;)

What about other calls? Our lsm uses ifq_enqueue(ifp, m) to send a packet. This seems to work without the stack context, but how is the rule here?

What about the mbuf handling functions?

Kind Regards

Michael

post119683: io-pkt-v4-hc hangs in OMAPL138

2019-04-26T21:25:33Z

We use QNX6.5.0 sp1 on OMAP-L138 based custom SOC.

ifconfig and netstat stop responding when the SOC connected to a LAN with multiple devices.

Pidin outputs - one of the threads of io-pkt-v4-hc is in nano sleep

io-pkt-v4-hc 21r NANOSLEEP

When the device is connected to a smaller network with a Couple of devices unit is observed to work without any issues.

The io-pkt driver is started using the following command

io-pkt-v4-hc -d /lib/devnp-til1xx.so mac=010203040506 -ptcpip

Is there any Known issue with the OMAP-L138 ethernet driver that I am not aware of?

post119682: Re: io-pkt thread context nightmare

2019-04-26T13:50:48Z

Sorry, I forgot. You would need to call stk_context_callback_2() to get across from your thread to io-pkt stack context, but then this runs within proc0 on stack context so you would then need to kthread_create1() to get on to a proper coroutine.

Relying on the io-pkt resource manager places everything in the stack context and thus the concerns I mentioned in my earlier message with performance, both io-pkt affecting your code and your code affecting io-pkt. Best performance would be to run in your own thread with your own resource manager and only do the stk_context_callback_2(), kthread_create1() dance for those pieces of code that need to run in io-pkt stack context.

I did mention that the io-pkt threading model is highly complicated ;-)

Regards,

Nick

post119681: Re: Interface specific hooks of protocol driver (lsm-XXX.so) attached with PFIL_TYPE_IFNET are broken in QNX 7

2019-04-26T13:44:13Z

Hi Oliver,

Please get in touch with your support contact, they should be able to help you with roll out plans for this fix. Fixes are normally released through QNX Software Center, either customer specific or general release.

For your earlier questions:

1) There is no issue with casting a pointer to a u_long as QNX uses LP64 on 64 bit (and ILP32 on 32 bit)

http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.prog/topic/64bits_data_types.html

2) Unfortunately there isn't an easy way for a customer to determine the exact flags that were used to build the io-pkt binary. If you have source level access then you would be able to see the common.mk files and see that they contain a define for QNX_MFIB.

Regards,

Nick

post119680: Re: io-pkt thread context nightmare

2019-04-26T10:37:03Z

Hello Nick,

> Most driver callbacks including the ifp->if_ioctl() expect to run in stack

> context so you will need to use stk_context_callback_2() to get the code to

> run in the stack context.

"stk_context_callback_2()" seems not to be enough. We still get the "proc0" assertion.

The e1000 driver additional uses kthread_create1() inside of the stack context callback. Why?

In the meantime we use another approach:

We removed our resmgr thread and connect our interface to the normal io-pkt resmgr threads by using their dispatch handle "skt_ctl.dpp".

This seems to work perfectly, but I wonder, if this approach could have any drawbacks.

Kind Regards

Michael

post119679: Re: Interface specific hooks of protocol driver (lsm-XXX.so) attached with PFIL_TYPE_IFNET are broken in QNX 7

2019-04-26T09:58:19Z

Hi Nick,

thank you for your fast reply and valuable answer. But our affected products are a middleware (protocol stacks) which are installed on customer systems and the customer will develop it's application on top. Especially for our customers who are in the process to upgrade existing 6.x installations to 7.x it would be a little bit surprising to tell them they need a newer io-pkt they have to request with the ID mentioned in your mail. I wonder when this modified version will be distributed on more common channels like the QNX Software Center so we can write in our prerequisites for our product you need at least to update your io-pkt on QNX 7 to version x.y.z.

Can you also give a short statement to the related ambiguities mentioned in question 1 and 2 of my initial post.

Best regards,

Oliver

post119671: Re: Can WTP be used anywhere a (struct nw_work_thread *) is required?

2019-04-23T08:17:49Z

Hi Nick,

Just what I needed - thanks for clarifying.

Regards,

John

post119670: Re: Can WTP be used anywhere a (struct nw_work_thread *) is required?

2019-04-22T12:57:21Z

Hi John,

It actually doesn't matter currently - everywhere the wtp is passed to the driver it has come from the WTP macro.

I would suggest that it's probably best to use the wtp passed in to the interrupt handling threads, but there is currently no situation where it is actually required.

Regards,

Nick.

post119669: Can WTP be used anywhere a (struct nw_work_thread *) is required?

2019-04-20T11:24:46Z

In an interrupt handling thread can I use m_getcl() and m_freem() instead of m_getcl_wtp() and m_freem_wtp() respectively?

Similarly for NW_SIGLOCK() and NW_SIGLOCK_P().

Looking at different driver source there is inconsistent usage of these routines in interrupt handling threads, sometimes the wtp pointer form is used in other places the WTP form is used.

What are the rules for using WTP?

post119668: Re: Interface specific hooks of protocol driver (lsm-XXX.so) attached with PFIL_TYPE_IFNET are broken in QNX 7

2019-04-18T18:47:33Z

Hi Oliver,

We found and resolved this issue in January with the interface hook not being called when it should. Please get in touch with your support contact and ask about issue ID 2665276 COREOS-114498 and they should be able to provide you with an updated io-pkt that resolves this.

Regards,

Nick

post119667: Interface specific hooks of protocol driver (lsm-XXX.so) attached with PFIL_TYPE_IFNET are broken in QNX 7

2019-04-18T13:05:00Z

Hi,

we are a provider of Industrial Ethernet protocol stack solutions. For the required

high performance low latency communication we have developed an own protocol driver

similar to your "lsm-nraw" which runs in the stack context to bypass the IP layer

but with a much more optimized data exchange to the application. We are using this

implementation on all 6.x versions since QNX 6.4 without any problems. Unfortunately

our implementation seems to be broken in QNX 7 although it is compiled without any

errors.

In our implementation we call pfil_head_get(int af, u_long dlt) with af set to PFIL_TYPE_IFNET

to indicate an interface hook and dlt set to the respective interface pointer according

to http://www.qnx.com/developers/docs/6.4.1/io-pkt_en/user_guide/filtering.html.

Now I have two initial concerns/questions:

1. The interface pointer has to be casted to u_long which obviously is a little bit fishy

   on a 64 bit architecture.

2. At some point in time QNX introduced so called Forwarding Information Base (FIB)

   support which is documented poorly or more or less not at all. In the header <pfil.h> which

   is included to build our protocol driver the define QNX_MFIB changes the

   hook prototype as first argument of pfil_add_hook() from



   int (*func)(void *, struct mbuf **, struct ifnet *, int)



     into



   int (*func)(void *, struct mbuf **, struct ifnet *, int, int)



   The last parameter seems to be FIB related. How can one figure out at compile time

   how QNX is built or where is this build option for the different QNX versions

   documented ?



All this are more or less oddnesses one can overcome but starting with QNX 7 the hook

does not seem to be called at all. After several hours of investigation we changed our

implementation to hook with pfil_head_get(PFIL_TYPE_IFT, IFT_ETHER) instead of the interface

specific implementation PFIL_TYPE_IFNET mentioned above and this is still working on

QNX 7 with the obvious drawback that we have to handle all mbufs which are not for our

interface, too.

Now we got curious and analyzed the ether_input() routine where both hooks are handled.

Compared to earlier implementations again the FIB support seems to make the difference.

In previous QNX versions the hooks get called unconditionally but now a call to

if_get_next_fib() is performed before a hook is called. The 2nd parameter of this

call is a so called start_fib which is initialized to -1 before the call to the hooks

which are attached with PFIL_TYPE_IFT. The if_get_next_fib() is called again before

the hooks attached with PFIL_TYPE_IFNET are called but this time the start_fib is not

reset to -1 again but has the value returned from the previous call (which is 16). This causes

the call to return with 17 and to skip the execution of the PFIL_TYPE_IFNET hooks.

3 . My 3rd an most important question is if you have ever tested the interface specific

    hooks attached with PFIL_TYPE_IFNET on QNX 7 and if they run in any of your lsm-xxx.so

    protocol drivers is there anything special to do (with respect to FIBs ???) to make

    our implementation work in the same way as on 6.x.

Unfortunately we have no kernel code insight so all the results above are based on the

analysis of machine code level debugging sessions.

Best regards,

  Oliver

post119666: Re: io-pkt thread context nightmare

2019-04-17T13:09:06Z

post119663: Re: io-pkt thread context nightmare

2019-04-16T14:27:14Z

Yes, the threading model for io-pkt is highly complex and if you get it wrong you will likely get panics and crashes.

Most driver callbacks including the ifp->if_ioctl() expect to run in stack context so you will need to use stk_context_callback_2() to get the code to run in the stack context.

Stack context is single threaded, so if something else is using it then your code will have to wait. Equally you should ensure that your code doesn't block the stack context and adversely affect other operations.

post119660: io-pkt thread context nightmare

2019-04-16T08:43:17Z

Hi,

we are just porting out lsm-Modul, we developed based on the lsm.nraw sample years ago in the good old QNX 6.x times.

The Resource-Manager thread for our lsm-interface  is created with nw_pthread_create().

This thread is calling  ifp->if_ioctl() from time to time, to get the interface statistics.

Under QNX 7 this results in an io-.pkt panic, which is fired by nic_mutex_trylock(), called from the e1000 driver.

nic_mutex_trylock() tries to validate  the run context by checking the curlwp against proc0. If they are equal, we panic().

As I learnd until now, io-pkt seems to emulate half of the netbsd-kernel to run the BSD TCPIP stack.

My thread, generated by nw_pthread_create()  seems to be the wrong one for calling the  e1000 driver ioctl.

How do I get the correct thread context, to allow it.

pcreat(), kthread_create() , ...?

Do I loose performance, if my thread is part of this emulated NETBSD-scheduler ?

I am a bit confused. Please advice.

Kind Regards

Michael

post119651: Re: devnp-e1000.so Squelch Test errors

2019-04-11T13:04:48Z

Thank you , Hugh.

post119642: Re: devnp-e1000.so Squelch Test errors

2019-04-10T13:01:37Z

Take a look at the use message for the driver - pause_rx_enable and pause_tx_enable.

On 2019-04-10, 8:59 AM, "Leonid Khait" <community-noreply@qnx.com> wrote:

    Please show: how turn ON flow control of  I211, I217 Ethernet Controllers

    by devnp-e1000.so driver?







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119641

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119641: Re: devnp-e1000.so Squelch Test errors

2019-04-10T12:59:32Z

Please show: how turn ON flow control of I211, I217 Ethernet Controllers

by devnp-e1000.so driver?

post119640: Re: devnp-e1000.so Squelch Test errors

2019-04-10T12:34:08Z

If you really want to stop fifo overruns, you should use flow control.

Increasing the number of descriptors does reduce the probability of fifo overruns, but doesn't prevent them completely.

On 2019-04-10, 8:26 AM, "Leonid Khait" <community-noreply@qnx.com> wrote:

    I'm sorry, Huge!



    Correctly I understand that increasing the number of external file descriptors (by receive=nnn argument )  reduces the probability of an internal Rx FIFO buffer overran?











    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119639

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119639: Re: devnp-e1000.so Squelch Test errors

2019-04-10T12:25:59Z

I'm sorry, Huge!

Correctly I understand that increasing the number of external file descriptors (by receive=nnn argument ) reduces the probability of an internal Rx FIFO buffer overran?

post119638: Re: devnp-ravb leading to kernal fault

2019-04-08T12:35:09Z

There is documentation for ptpd and ptpd-avb in the SDP7 utilities documentation.

On 2019-04-08, 8:28 AM, "Amit Walvekar" <community-noreply@qnx.com> wrote:

    I see. Thanks for the info really helped me out. Btw, is the a PTP daemon also provided? i noticed a couple of them, "ptpd" and "ptpd-avb". I cannot seem to get them working.



    Error: can't open /var/run/kernel_clock: Bad file descriptor.



    Is there any user guide?







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119637

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119637: Re: devnp-ravb leading to kernal fault

2019-04-08T12:28:21Z

I see. Thanks for the info really helped me out. Btw, is the a PTP daemon also provided? i noticed a couple of them, "ptpd" and "ptpd-avb". I cannot seem to get them working.

Error: can't open /var/run/kernel_clock: Bad file descriptor.

Is there any user guide?

post119636: Re: devnp-ravb leading to kernal fault

2019-04-08T11:34:16Z

If you look at the documentation for slog2, you will see that it isn't interrupt safe.

On 2019-04-08, 5:01 AM, "Amit Walvekar" <community-noreply@qnx.com> wrote:

    Hello,



    You were right. I had slog2 statements inside the ISR. I removed them and it is working fine. Any idea why the log statements caused the issue?







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119634

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119635: Re: devnp-e1000.so Squelch Test errors

2019-04-08T11:33:11Z

Yes, it is so, as you can see from the description that you posted as well.

On 2019-04-06, 12:09 AM, "Leonid Khait" <community-noreply@qnx.com> wrote:

    From the description of the driver, I understand that increasing the file descriptor buffer by "receive=4096" argument will not solve the Squelch Test Error increase counter problem.



    Since this counter signals the problem is inside the NIC interface itself: the  overran of its internal FIFO buffer.



    Is it so?



    ---



    From devnp-e1000.so Description:

    ...

    The SQE (Squelch Test Errors) counter — one of the fields reported by nicinfo — isn't applicable to devnp-e1000.so, so this driver uses it in a non-standard way. You can lose packets because:



        you ran out of descriptors (the NIC was able to buffer the packet, but there was no CPU RAM available)



        or:

        the NIC was unable to buffer the packet because it overran its internal Rx FIFO



    Other drivers add the two together, but this driver uses the SQE counter for internal Rx FIFO overruns, which generally indicate excessive bus latency, perhaps misconfigured link-level flow control, or even misconfigured Rx FIFO watermarks.

    ...







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119633

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119634: Re: devnp-ravb leading to kernal fault

2019-04-08T09:01:46Z

Hello,

You were right. I had slog2 statements inside the ISR. I removed them and it is working fine. Any idea why the log statements caused the issue?

post119633: Re: devnp-e1000.so Squelch Test errors

2019-04-06T04:09:49Z

From the description of the driver, I understand that increasing the file descriptor buffer by "receive=4096" argument will not solve the Squelch Test Error increase counter problem.

Since this counter signals the problem is inside the NIC interface itself: the  overran of its internal FIFO buffer.

Is it so?

---

From devnp-e1000.so Description:

...

The SQE (Squelch Test Errors) counter — one of the fields reported by nicinfo — isn't applicable to devnp-e1000.so, so this driver uses it in a non-standard way. You can lose packets because:

    you ran out of descriptors (the NIC was able to buffer the packet, but there was no CPU RAM available)

    or:

    the NIC was unable to buffer the packet because it overran its internal Rx FIFO

Other drivers add the two together, but this driver uses the SQE counter for internal Rx FIFO overruns, which generally indicate excessive bus latency, perhaps misconfigured link-level flow control, or even misconfigured Rx FIFO watermarks.

...

post119632: Re: devnp-ravb leading to kernal fault

2019-04-05T11:34:34Z

Did you put debug statements in the ISR? AFAIK, the ravb driver is a working driver.

On 2019-04-05, 3:19 AM, "Amit Walvekar" <community-noreply@qnx.com> wrote:

    Hello,



    I am using QNX 7.0 on an RCar-H3 starter kit. I got the bsp from the QNX software center. I am currently exploring the possibilities of AVB on QNX since I was successful to have it working on the same hardware with Linux.



    I noticed that a pre-built devnp-ravb driver was already part of the bsp and is functional for legacy ethernet traffic. I built devnp-ravb driver source code with some debug statements. I load it with io-pkt and when i try to bring up the interface, there is a kernel fault with the below backtrace and a reboot.



    Shutdown[0,0] S/C/F=8/9/9 C/D=ffffff80600484d8/ffffff8060102680 state(1)= 1

    QNX Version 7.0.0 Release 2017/02/14-16:05:38EST KSB:ffffff808304c000

    $URL: http://svn.ott.qnx.com/product/branches/7.0.0/trunk/services/system/ker/timestamp.c $

    [0]PID-TID=1-1? P/T FL=08019001/0c000000 "proc/boot/procnto-smp-instr"

    [0]ASPACE PID=213022 PF=08401010 "proc/boot/io-pkt-v6-hc"



    I am having doubts whether the delivered source code actually works or is more of a reference. Also the size of the prebuilt driver(68kB) is way less than the one i manually built(365kB)(Maybe because i did not strip it). Can anyone help me out with this? Is there also a guide which can help me with the driver's APIs?



    Thanks,

    Amit







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119631

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119631: devnp-ravb leading to kernal fault

2019-04-05T07:19:47Z

Hello,

I am using QNX 7.0 on an RCar-H3 starter kit. I got the bsp from the QNX software center. I am currently exploring the possibilities of AVB on QNX since I was successful to have it working on the same hardware with Linux.

I noticed that a pre-built devnp-ravb driver was already part of the bsp and is functional for legacy ethernet traffic. I built devnp-ravb driver source code with some debug statements. I load it with io-pkt and when i try to bring up the interface, there is a kernel fault with the below backtrace and a reboot.

Shutdown[0,0] S/C/F=8/9/9 C/D=ffffff80600484d8/ffffff8060102680 state(1)= 1

QNX Version 7.0.0 Release 2017/02/14-16:05:38EST KSB:ffffff808304c000

$URL: http://svn.ott.qnx.com/product/branches/7.0.0/trunk/services/system/ker/timestamp.c $

[0]PID-TID=1-1? P/T FL=08019001/0c000000 "proc/boot/procnto-smp-instr"

[0]ASPACE PID=213022 PF=08401010 "proc/boot/io-pkt-v6-hc"

I am having doubts whether the delivered source code actually works or is more of a reference. Also the size of the prebuilt driver(68kB) is way less than the one i manually built(365kB)(Maybe because i did not strip it). Can anyone help me out with this? Is there also a guide which can help me with the driver's APIs?

Thanks,

Amit

post119627: Re: Concurrency and mutual exclusion in io-pkt network drivers

2019-04-01T13:12:11Z

Hi John,

Yes, it's a run to completion model with respect to other co-routines unless you yield. No preemption or time-slicing with respect to other co-routines. This is why you only need to consider locking when yielding and why you need to consider yielding when blocking.

Of course this is all still running on a POSIX thread which may be preempted or time-sliced with threads in other processes, so you aren't guaranteed to be on the processor all the time!

Regards,

Nick.

post119624: Re: Concurrency and mutual exclusion in io-pkt network drivers

2019-03-30T18:02:32Z

Hi Nick,

>

> nic_mutex() is used to provide mutex-like locking for the stack context

> operations - an actual mutex cannot be used.

>

> As I mentioned, the low level call that yields stack context is ltsleep()

> which can be wrapped in tsleep(). In driver code it is usually the nic_delay()

> call that yields context or blockop().

Does this mean that if a stack callback does not yield it will run to completion? In other words, there is no preemption or time slicing in the scheduling of co-routines?

post119622: Re: Concurrency and mutual exclusion in io-pkt network drivers

2019-03-28T17:19:11Z

Hi John,

In general it depends on how long the wait is. The rule of thumb that I use is < 1ms then you can busy wait, otherwise use nic_delay(). When you are busy waiting you are blocking io-pkt stack context so you are potentially affecting traffic on other interfaces / Unix Domain Sockets etc.

Regards,

Nick

post119621: Re: Concurrency and mutual exclusion in io-pkt network drivers

2019-03-28T16:55:41Z

Hi Nick,

Thanks again for the clear and detailed information.

I take the point re nic_delay(). However, some drivers I've seen use nic_delay when waiting for register bits to change, e.g. following a reset, or waiting for the MII bus to become free at the start of the MII read/write routines.

Is that still preferable to doing a busy-wait using nanosleep_ns()?

Regards,

John

post119620: Re: Concurrency and mutual exclusion in io-pkt network drivers

2019-03-28T15:02:54Z

Hi John,

While the start callback is usually called from stack context, there are 3 scenarios where it is called from an interrupt event handler thread:

1) Bridging. The Ethernet frame is received by the receiving interface's Rx interrupt event handler. The call to ifp->if_input() will perform a bridging lookup and call the output interface's start callback all within this same context.

2) Fast Forwarding. Similar to the Bridging scenario but with an IP flow.

3) Tx after Tx descriptors are full. The start callback is usually called by stack context everytime that a packet is added to the interface Tx queue. The start callback populates the Tx descriptors, but if it runs out of room then it sets IFF_OACTIVE, enables Tx completion interrupts and returns. When a Tx completion interrupt fires then the Tx interrupt event handler will run. This should take the ifp->if_snd_ex lock, reap the used descriptors, and continue to populate the Tx descriptors now that it has more space. It may run out of space again in which case this pattern repeats. Eventually it will drain the Tx queue and it should clear IFF_OACTIVE and disable the Tx completion interrupt (to avoid wasting CPU). Now that IFF_OACTIVE is clear then the stack context will call the driver start callback each time it places a packet to be transmitted on the Tx queue.

Just to clarify one thing about the ifp->if_snd_ex. It is actually the lock for the interface Tx queue, so io-pkt stack context takes the lock each time it wants to add a packet on to the queue. We can reuse it in the stop callback to indicate that the start callback isn't running because the start callback is always called with the lock held.

You are correct about nic_delay() when it yields stack context. The stack context can now perform any other stack context operations including driver callbacks, timer callouts etc. N.B. This includes calling the detach callback, which invariably leads to a crash after the detach callback has removed the interface, the delay expires and then the stack context tries to switch back to running code that may no longer be in memory, or if it is then it refers to an interface that no longer exists and the structures have been freed. The most painful to debug crashes come from when that freed memory is actually reused for another interface.

nic_mutex() is used to provide mutex-like locking for the stack context operations - an actual mutex cannot be used.

As I mentioned, the low level call that yields stack context is ltsleep() which can be wrapped in tsleep(). In driver code it is usually the nic_delay() call that yields context or blockop().

A note on delays:

io-pkt has a best timer granularity of 8.5ms, but it can extend out to 50ms if no traffic is running. This means that a call to nic_delay(1) can be a 50ms delay rather than a 1ms delay. If there are many such calls in succession this can lead to a driver taking many seconds to setup some hardware. In these scenarios it is best to call blockop(). This will yield stack context at that point and execute the code in the io-pkt main thread (thread 1). nic_delay() detects the context it is running under and will switch to using normal sleep calls with the granularity of the system timer (default 1ms). At the completion of the blockop() then the original stack context routine is placed in a ready state - although note that if the stack context is currently performing some other operation it may not run immediately.

Regards,

Nick.

post119617: Re: Concurrency and mutual exclusion in io-pkt network drivers

2019-03-28T09:10:02Z

Hi Nick,

> The ifp->if_snd_ex is only held by the stack when the driver start callback is

>  called, the stop callback needs to lock it first to ensure that the driver

> start isn't currently running.

How is it possible for the stack to call the stop callback if the start callback is still running? Doesn't that imply another thread of execution? I thought the driver callbacks (and callouts) were invoked in the stack context.

> nic_mutex_lock() is used to synchronise across multiple io-pkt coroutines

> running on the stack context thread. This is necessary any time that the stack

>  context thread can yield - at the lowest level it is a call to ltsleep(), but

>  at the driver level this is often wrapped up in a nic_delay() call.

Does this mean that if a driver callback uses nic_delay() the stack context can invoke another driver callback (or timer callout)? The nic_mutex is therefore used to protect driver critical resources in this situation - is that correct?

Apart from nic_delay() what other calls result in a callback yielding to another stack coroutine that could result in the stack entering another driver callback?

Regards,

John

post119616: Re: Concurrency and mutual exclusion in io-pkt network drivers

2019-03-27T18:47:23Z

The ifp->if_snd_ex is only held by the stack when the driver start callback is called, the stop callback needs to lock it first to ensure that the driver start isn't currently running.

A new mutex would be initialised with NW_EX_INIT() and destroyed with NW_EX_DESTROY().

nic_mutex_lock() is used to synchronise across multiple io-pkt coroutines running on the stack context thread. This is necessary any time that the stack context thread can yield - at the lowest level it is a call to ltsleep(), but at the driver level this is often wrapped up in a nic_delay() call.

Remember that io-pkt stack context is single threaded hence you do need to yield rather than sitting in a blocking call. If you don't yield then you can impact other stack context operations such as traffic on other interfaces.

post119615: Re: MDI API description in QNX7 documentation

2019-03-27T18:29:55Z

I can't find an up to date example in a BSP so I've attached it here.

post119614: Re: MDI API description in QNX7 documentation

2019-03-27T15:19:23Z

Hi Nick,

Thanks, I found some 6.3.2 documentation online which covers many of the routines, even though it is quite old.

Is the smsc9500 driver available in one the reference BSPs?

Regards,

John

post119613: Re: Concurrency and mutual exclusion in io-pkt network drivers

2019-03-27T14:47:50Z

Hi Nick,

Thanks - it's beginning to make more sense now.

I see the stack already uses ifp->if_snd_ex to serialise access to transmit resources. It appears this mutex is held when the start and stop callbacks are entered - is that correct?

Are you saying I can create additional mutex if I need to serialise access to other driver resources in stack context and interrupt processing threads? Should the new mutex be initialised using NW_EX_INIT?

What are the rules using nic_mutex_lock()? I mean how you do recognise situations where it might be required?

Regards,

John

post119612: Re: MDI API description in QNX7 documentation

2019-03-27T12:41:21Z

Hi John,

Unfortunately there isn't a document describing this (and many other io-pkt APIs). I tend to refer people to the smsc9500 driver as one where the MDI driver API has been thoroughly tested and is known to work well.

Regards,

Nick

post119611: Re: Concurrency and mutual exclusion in io-pkt network drivers

2019-03-27T12:37:59Z

Hi John,

Yes, the stack context thread and multiple interrupt event handling threads can run concurrently.

nic_mutex_lock() is for locking the multiple coroutines that can run on the stack context thread, it will panic() if called from an interrupt event handling thread. Take a look at NW_SIGLOCK() / NW_SIGLOCK_P() for providing locking between an interrupt event handling thread and a stack context thread.

Regards,

Nick

post119609: MDI API description in QNX7 documentation

2019-03-27T11:11:01Z

Is the MDI API described in the QNX7 documentation set?

It does not appear to be part of the QNX Neutrino RTOS C Library Reference. Is there a separate networking API reference document?

Thanks,

John

post119608: Concurrency and mutual exclusion in io-pkt network drivers

2019-03-27T11:04:07Z

Hello,

I am developing a driver for a PCI-based network interface for QNX 7. I have read the Writing Network Drivers for io-pkt section in the Core Networking Stack User's Guide and looked at the ravb and mx6x driver source.

It is still not entirely clear to me if and when there may be more than one thread executing the driver code. I don't anticipate having to create my own separate driver threads.

My device has MSI-X interrupts so I plan to have multiple ISRs, one for each MSI-X interrupt source. I would therefore expect that multiple interrupt event handling threads could run concurrently. If that is possible I will need to protect driver resources, including device registers, from concurrent access.

Can the io-pkt stack context thread run concurrently with the interrupt event handling threads? For example, can the stack queue packets for transmission or update the link speed, etc, while receive and transmit interrupt events are being processed by io-pkt worker threads?

The drivers source I have looked at has almost no locking. There is a little use of nic_mutex_lock/unlock but only in some peripheral cases. Is nic_mutex_lock/unlock the right mechanism to provide access serialisation in the driver code?

BTW, I cannot find mention of nic_mutex_lock/unlock and nic_delay in the documentation. Where are these functions described?

If anyone can shed some light on this it would be greatly appreciated.

Thanks,

John

post119605: Re: io-pkt-v4-hc blocking

2019-03-26T15:02:33Z

Please try the attached io-pkt-v4-hc.

On 2019-03-25, 8:25 AM, "Leonid Khait" <community-noreply@qnx.com> wrote:

    Occasionally we have a problem removing io-pkt-v4-hc from execution with message

    ...

    Process 286737 (io-pkt-v4-hc) terminated SIGSEGV code=1 fltno=11 ip=08101485 (io-pkt-v4-hc@m_free_wtp+0x15) ref=82d1b0ec.

    ...



    Please explain what could be the reason?



    Could there be a problem with devnp-e1000.so?



    Could there be a reason for the malfunction of the Etnernet interface chip ?



    Core dump , use -i io-pkt-v4-hc and Error message photos attached to this Message.







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119603

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119604: Re: SIOCGDRVSPEC ioctl: Operation not permitted

2019-03-26T05:33:35Z

Hello again,

I changed the socket type from AF_UNIX to AF_INET and the ioctl is reaching the driver.

post119603: Re: io-pkt-v4-hc blocking

2019-03-25T12:25:08Z

Occasionally we have a problem removing io-pkt-v4-hc from execution with message

...

Process 286737 (io-pkt-v4-hc) terminated SIGSEGV code=1 fltno=11 ip=08101485 (io-pkt-v4-hc@m_free_wtp+0x15) ref=82d1b0ec.

...

Please explain what could be the reason?

Could there be a problem with devnp-e1000.so?

Could there be a reason for the malfunction of the Etnernet interface chip ?

Core dump , use -i io-pkt-v4-hc and Error message photos attached to this Message.

post119601: SIOCGDRVSPEC ioctl: Operation not permitted

2019-03-25T10:56:11Z

Hello,

I am using Neutrino 7.0 on an RCAR H3 starter kit. I wanted to check the functionality of the ravb driver provided with the BSP. The ioctl calls for driver specific commands return error code 103: Operation not permitted. I tried another method in this forum using IOV's and MsgSendv_r but they return the same error aswell. Here is the code snippet i use.

int sock = socket(AF_UNIX, SOCK_DGRAM, IPPROTO_IP);

if (sock == -1) {

return -1;

};

struct ifdrv drv;

ptp_time_t ts;

drv.ifd_cmd = PTP_GET_TIME;

drv.ifd_len = sizeof(ts);

drv.ifd_data = &ts;

strcpy(drv.ifd_name,"ravb0");

int retVal = ioctl(sock, SIOCGDRVSPEC,&drv);

if(retVal)

{

cout << "error: " << errno << endl;

cout << strerror(errno) << endl;

}

I checked the driver code aswell and it supports the command.

Can you please help?

post119596: Re: io-pkt-v4-hc blocking

2019-03-21T06:27:38Z

> Dear Hugh,

> your new driver version works mach more stably on the ping test,

> especially with the argument receave = 4096.

>

> We will check if this version solves network problems that we occasionally

> have.

>

> Thank you very much

post119595: Re: io-pkt-v4-hc blocking

2019-03-21T05:16:15Z

Dear Hugh,

your new driver version works mach more stably on the ping test,

especially with the argument reseave = 4096.

We will check if this version solves network problems that we occasionally have.

Thank you very much

post119593: Re: io-pkt-v4-hc blocking

2019-03-20T12:17:52Z

Please try the attached driver. Also realize that you are trying to send 200000 messages in 1 second, so it might be an idea to increase the receive and transmit buffers with the "receive=nnn" and "transmit=nnn" command line options to the driver. The defaults for both are 512.

On 2019-03-20, 12:16 AM, "Leonid Khait" <community-noreply@qnx.com> wrote:

    #use -i devnp-e1000.so



    NAME=devnp-e1000.so

    DESCRIPTION=Driver for Intel 82544 Gigabit Ethernet controllers

    DATE=2015/11/30-12:50:20-EST

    STATE=stable

    HOST=gusbuild8

    USER=builder

    VERSION=1344

    TAGID=PSP_networking_br650_be650SP1



    Thanks in advance,

    Leonid













    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119590

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119590: Re: io-pkt-v4-hc blocking

2019-03-20T04:16:31Z

#use -i devnp-e1000.so

NAME=devnp-e1000.so

DESCRIPTION=Driver for Intel 82544 Gigabit Ethernet controllers

DATE=2015/11/30-12:50:20-EST

STATE=stable

HOST=gusbuild8

USER=builder

VERSION=1344

TAGID=PSP_networking_br650_be650SP1

Thanks in advance,

Leonid

post119589: Re: io-pkt-v4-hc blocking

2019-03-19T11:52:04Z

Please post the output from "use -i devnp-e1000.so".

On 2019-03-13, 11:29 PM, "Leonid Khait" <community-noreply@qnx.com> wrote:

    When in use QNX6.5 and Intel Ethernet card

    ...

    #io-pkt-v4-hc -de1000

    #ifconfig wm0 192.168.1.1 up

    ...

    and we try to send a lot of pings through network



    #ping -l 100000 -s1590 192.168.1.2

    then  io-pkt-v4-hs stack becomes blocked.



    When we try to use another RTL Ethernet card

    ...

    #io-pkt-v4-hc -drtl

    #ifconfig en0 192.168.1.1 up

    #ping -l 100000 -s1590 192.168.1.2



    then  no such blocking occurs.



    What could be the reason?



















    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119579

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119579: io-pkt-v4-hc blocking

2019-03-14T03:29:12Z

When in use QNX6.5 and Intel Ethernet card

...

#io-pkt-v4-hc -de1000

#ifconfig wm0 192.168.1.1 up

...

and we try to send a lot of pings through network

#ping -l 100000 -s1590 192.168.1.2

then io-pkt-v4-hs stack becomes blocked.

When we try to use another RTL Ethernet card

...

#io-pkt-v4-hc -drtl

#ifconfig en0 192.168.1.1 up

#ping -l 100000 -s1590 192.168.1.2

then no such blocking occurs.

What could be the reason?

post119564: Re: How to disable receive in mpc85xx

2019-03-05T15:36:49Z

I have no idea as to what is happening, so you will have to debug your code.

On 2019-03-05, 10:14 AM, "Vijaya V" <community-noreply@qnx.com> wrote:

    Thanks a lot for your response.



    I am testing with these changes. I have applied storm such that receive disable and enable happens frequently. It is working for quiet some time. And then there is a kind of hang on communications side. I can see trough print statement that receive is enabled. My application also seems to be running. The problem is occurring randomly.



    How do I debug this situation. Is there any tool or utility?



    Thanks & Regards

    Vijaya







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119563

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119563: Re: How to disable receive in mpc85xx

2019-03-05T15:14:51Z

Thanks a lot for your response.

I am testing with these changes. I have applied storm such that receive disable and enable happens frequently. It is working for quiet some time. And then there is a kind of hang on communications side. I can see trough print statement that receive is enabled. My application also seems to be running. The problem is occurring randomly.

How do I debug this situation. Is there any tool or utility?

Thanks & Regards

Vijaya

post119562: Re: How to disable receive in mpc85xx

2019-03-05T13:48:53Z

    *(base + MPC_DMACTRL) &= ~(DMACTRL_GRS | DMACTRL_GTS);

On 2019-03-05, 8:46 AM, "Vijaya V" <community-noreply@qnx.com> wrote:

    I think the code you provided should be added while disabling receive.  Similarly is there anything to be added while enabling receive?







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119561

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119561: Re: How to disable receive in mpc85xx

2019-03-05T13:46:17Z

I think the code you provided should be added while disabling receive. Similarly is there anything to be added while enabling receive?

post119560: Re: How to disable receive in mpc85xx

2019-03-05T12:35:32Z

You might want to add the following as well:

    if  ((*(base + MPC_DMACTRL) & DMACTRL_GRS) == 0) {

        /* Graceful receive stop and wait for completion. */

        *(base + MPC_DMACTRL) |= DMACTRL_GRS;

        timeout = MPC_TIMEOUT;

        do {

            nanospin_ns (10);

            if (! --timeout)

                break;

            status = *(base + MPC_IEVENT);

        } while ((status & IEVENT_GRSC) != IEVENT_GRSC);

        if (!timeout) {

            log(LOG_ERR, "%s(): DMA GRS stop failed", __FUNCTION__);

        }

    }

On 2019-03-05, 5:54 AM, "Vijaya V" <community-noreply@qnx.com> wrote:

    I got hold of the code. For enabling and disabling Rx, I am trying below code:



    Disable Rx:



    *(base + MPC_MACCFG1) &= ~MACCFG1_RXEN;



    Enable Rx:



    *(base + MPC_MACCFG1) |= MACCFG1_RXEN;



    Is this sufficient or do I need to modify any other registers.



    Thanks& Regards

    Vijaya







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119559

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119559: Re: How to disable receive in mpc85xx

2019-03-05T10:54:18Z

I got hold of the code. For enabling and disabling Rx, I am trying below code:

Disable Rx:

*(base + MPC_MACCFG1) &= ~MACCFG1_RXEN;

Enable Rx:

*(base + MPC_MACCFG1) |= MACCFG1_RXEN;

Is this sufficient or do I need to modify any other registers.

Thanks& Regards

Vijaya

post119551: Re: Does QNX support Netlink messages to receive interface and route events

2019-02-28T15:40:57Z

We do not support Linux Netlink, but we do support the BSD Routing Socket. This will give you route and interface events.

post119550: Does QNX support Netlink messages to receive interface and route events

2019-02-28T06:37:10Z

Similar to linux netlink messages ,does QNX support route and interface events mechanism

post119548: Re: How to disable receive in mpc85xx

2019-02-27T14:44:05Z

It is changes to driver code.

post119547: Re: How to disable receive in mpc85xx

2019-02-27T14:43:25Z

How do I achieve this custom ioctl ()? Is there a sample code for shutting off receive in hardware? Does it require changes to driver code?

Appreciate your help on this.

Thanks & Regards

Vijaya

post119546: Re: How to disable receive in mpc85xx

2019-02-27T14:24:04Z

I suggest contacting your support contact, they should be able to provide you with the latest version of the driver code.

You would need to add a custom ioctl() that shuts off the receive in hardware to get it to drop packets with the minimum CPU load if you are worried about network storms. Any other option is still going to have some CPU usage as it runs the Rx descriptor ring.

post119545: Re: How to disable receive in mpc85xx

2019-02-27T14:14:43Z

Thanks for your reply.

I am trying to deal with network storm conditions. I need to disable Rx when number of packets received crosses a limit in a given time. This is to give application code required time to process already received packets. Taking down the interface (using ifconfig down etc) is not an option as it would disturb the transmit also.

1) What are your suggestions to handle storm conditions? Any other ways other than taking down the interface?

2) I have only devnp-mpc85xx.so file. How do I get latest driver code?

Thanks & Regards

Vijaya

post119544: Re: How to disable receive in mpc85xx

2019-02-26T14:25:15Z

There's no way in the standard driver to just disable receive and leave transmit active. If you need to do this then you would need to customise the driver and drop the received packets.

If you need to stop receiving and also transmitting then you could do the equivalent of "ifconfig ... down". This is an ioctl() for SIOCGIFFLAGS, clear IFF_UP from the returned flags and then do ioctl() for SIOCSIFFLAGS.

post119543: How to disable receive in mpc85xx

2019-02-26T14:18:16Z

Hi,

I need a help.

I am using devnp-mpc85xx.so driver and stack version is io-pkt-v6-hc. Based on certain conditions I need to disable receiving packets for sometime and then enable it later. I wanted to achieve it in my application code. Can someone help me what should I do to achieve it.

Thanks & Regards

Vijaya

post119360: Re: devnp-e1000.so Squelch Test errors

2018-12-17T12:45:19Z

You can try increasing the number of receive buffers with the "receive=nnn" command line option, where nnn can be between 64 and 4096. The default used to be 128 receive buffers, so you can try anything higher than that.

On 2018-12-14, 9:01 PM, "Leonid Khait" <community-noreply@qnx.com> wrote:

    Sorry my mistake:

     ...

        Driver devnp-e100.so vid = 0x8086, did = 0x15b3

    ...



    So, is it hardware problem or driver e1000 error?



    That problem happens too infrequently.



    How to solve that,



    Thank you.







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119359

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119359: Re: devnp-e1000.so Squelch Test errors

2018-12-15T02:01:01Z

Sorry my mistake:

...

Driver devnp-e100.so vid = 0x8086, did = 0x15b3

...

So, is it hardware problem or driver e1000 error?

That problem happens too infrequently.

How to solve that,

Thank you.

post119358: Re: devnp-e1000.so Squelch Test errors

2018-12-14T13:42:31Z

Squelch test errors are from the missed packet count register (receive overruns) of the e1000.

On 2018-12-14, 2:21 AM, "Leonid Khait" <community-noreply@qnx.com> wrote:

    #nicinfo wm0



    shows an increase in the number of errors

    ...

    Squelch Test errors .......

    ...



    Which leads to a failure in the qnet and Tcpip protocols.



    Driver devnp-qnet.so vid = 0x8086, did = 0x15b3



    NAME = devnp-e1000.so

    DESCRIPTION = Driver for Intel 82544 Gigabit Ethernet controllers

    DATE = 2015/11 / 30-12: 50: 20-EST

    STATE = stable

    HOST = gusbuild8

    USER = builder

    VERSION = 1344

    TAGID = PSP_networking_br650_be650SP1



    What could be the causes of failures, what could be the recommendations?



    Thanks







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119357

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119357: devnp-e1000.so Squelch Test errors

2018-12-14T07:21:09Z

#nicinfo wm0

shows an increase in the number of errors

...

Squelch Test errors .......

...

Which leads to a failure in the qnet and Tcpip protocols.

Driver devnp-qnet.so vid = 0x8086, did = 0x15b3

NAME = devnp-e1000.so

DESCRIPTION = Driver for Intel 82544 Gigabit Ethernet controllers

DATE = 2015/11 / 30-12: 50: 20-EST

STATE = stable

HOST = gusbuild8

USER = builder

VERSION = 1344

TAGID = PSP_networking_br650_be650SP1

What could be the causes of failures, what could be the recommendations?

Thanks

post119305: Re: Intel I210 NIC only shows link status DOWN

2018-11-22T15:48:21Z

That's fine. Thanks again for all your help.

post119304: Re: Intel I210 NIC only shows link status DOWN

2018-11-22T15:44:28Z

At this stage I think that is best that you contact your QNX Sales rep to make arrangements to get this problem resolved.

Thanks, Hugh.

On 2018-11-22, 10:31 AM, "John Scarrott" <community-noreply@qnx.com> wrote:

    Still no luck.



    Slog here:



    Jan 01 00:01:14.513                    iopkt.36871                           0  -----ONLINE-----

    Jan 01 00:01:14.514                    iopkt.36871          main_buffer*     0  tcpip starting

    Jan 01 00:01:14.514                    iopkt.36871          main_buffer      0  Unable to open /dev/random: errno: 2

    Jan 01 00:01:14.514                    iopkt.36871          main_buffer      0  Falling back on internal pseudo random generator

    Jan 01 00:01:14.516                    iopkt.36871          main_buffer      0  initializing IPsec...

    Jan 01 00:01:14.516                    iopkt.36871          main_buffer      0   done



    Jan 01 00:01:14.516                    iopkt.36871          main_buffer      0  IPsec: Initialized Security Association Processing.



    Jan 01 00:01:14.519                    iopkt.36871          main_buffer      0  devnp-e1000.so (null)

    Jan 01 00:01:14.521             io_pkt_v6_hc.36871                           0  -----ONLINE-----

    Jan 01 00:01:14.521             io_pkt_v6_hc.36871              pci_log*     0  INFO ,1,0,4 [36871:2]: SLOG module load successful for pid 36871 (io-pkt-v6-hc)

    Jan 01 00:01:14.521             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Attempt module load of /lib/dll/pci/pci_hw-Intel_x86_APL.so

    Jan 01 00:01:14.521             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module is compatible with Library ver 2.0

    Jan 01 00:01:14.521             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module /lib/dll/pci/pci_hw-Intel_x86_APL.so, v2.1 loaded successfully

    Jan 01 00:01:14.522          io_pkt_v6_hc.36871..0                           0  -----ONLINE-----

    Jan 01 00:01:14.522             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Attempt module load of /lib/dll/pci/pci_debug2.so

    Jan 01 00:01:14.522             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module /lib/dll/pci/pci_debug2.so, v2.1 loaded successfully

    Jan 01 00:01:14.522          io_pkt_v6_hc.36871..0              pci_dbg*     0  DEBUG,1,1,4 [36871:2]: find_ecam_base(): trying offset 0x60 for vid/did 8086/5af0

    Jan 01 00:01:14.523          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,1,4 [36871:2]: find_ecam_base(): found ecam base 0xe0000000

    Jan 01 00:01:14.534          io_pkt_v6_hc.36871..1                           0  -----ONLINE-----

    Jan 01 00:01:14.534                    iopkt.36871          main_buffer      0  wm0



    Jan 01 00:01:14.534             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: Successful connection to PCI server on /dev/pci

    Jan 01 00:01:14.534             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Capability modules will be searched for in directory /lib/dll/pci

    Jan 01 00:01:14.534             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Attempt module load of /lib/dll/pci/pci_cap-0x10-8086157b.so

    Jan 01 00:01:14.534             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x10.so

    Jan 01 00:01:14.534          io_pkt_v6_hc.36871..1                 slog*     0  *** found B5:D0:F0

    Jan 01 00:01:14.534          io_pkt_v6_hc.36871..1                 slog      0  *** device is supported, attaching

    Jan 01 00:01:14.534                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:3]: msg_handler(msg type: 33, connect_entry: 806e0f8) reply_len = 8, OK [PCI_ERR_OK]

    Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: Module is compatible with Library ver 2.0

    Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module /lib/dll/pci/pci_cap-0x10.so, v2.0 loaded successfully

    Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x10-8086157b.so ... not found

    Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x10.so

    Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Attempt module load of /lib/dll/pci/pci_cap-0x11-8086157b.so

    Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x11.so

    Jan 01 00:01:14.535          io_pkt_v6_hc.36871..1                 slog      0  Unable to enable PCIe capabilities, Requested Operation, Condition Or Data Already Exists [PCI_ERR_EALREADY]

    Jan 01 00:01:14.536             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: Module is compatible with Library ver 2.0

    Jan 01 00:01:14.536             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module /lib/dll/pci/pci_cap-0x11.so, v2.0 loaded successfully

    Jan 01 00:01:14.536             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x11-8086157b.so ... not found

    Jan 01 00:01:14.536             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x11.so

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820e088) returns 5

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 3 disabled

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 4 disabled

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X capabilities enabled

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 0 unmasked

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 1 unmasked

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 2 unmasked

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  *** mmap_device_memory @ 81100000 to 180097000

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  *** 3 irqs

    Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  translate 0x17a112000, len 1000





    #slay io-pkt-v6-hc

    # io-pkt-v6-hc -de1000 -vvvvv

    # ifconfig wm0 up

    *plugged in cable here*

    # nicinfo

    wm0:

      INTEL PRO/1000 Gigabit (Copper) Ethernet Controller



      Link is DOWN



      Physical Node ID ........................... 00E04B 6564AD

      Current Physical Node ID ................... 00E04B 6564AD

      Current Operation Rate ..................... Unknown

      Active Interface Type ...................... MII

        Active PHY address ....................... 1

      Maximum Transmittable data Unit ............ 1500

      Maximum Receivable data Unit ............... 1500

      Hardware Interrupt ......................... 0x100

      Hardware Interrupt ......................... 0x101

      Hardware Interrupt ......................... 0x102

      Memory Aperture ............................ 0x81100000 - 0x8111ffff

      Promiscuous Mode ........................... Off

      Multicast Support .......................... Enabled



      Packets Transmitted OK ..................... 0

      Bytes Transmitted OK ....................... 0

      Broadcast Packets Transmitted OK ........... 0

      Multicast Packets Transmitted OK ........... 0

      Memory Allocation Failures on Transmit ..... 0



      Packets Received OK ........................ 2

      Bytes Received OK .......................... 618

      Broadcast Packets Received OK .............. 2

      Multicast Packets Received OK .............. 0

      Memory Allocation Failures on Receive ...... 0



      Single Collisions on Transmit .............. 0

      Multiple Collisions on Transmit ............ 0

      Deferred Transmits ......................... 0

      Late Collision on Transmit errors .......... 0

      Transmits aborted (excessive collisions) ... 0

      Jabber detected ............................ 0

      Receive Alignment errors ................... 0

      Received packets with CRC errors ........... 0

      Packets Dropped on receive ................. 0

      Oversized Packets received ................. 0

      Short packets .............................. 0

      Squelch Test errors ........................ 0

      Invalid Symbol Errors ...................... 0











    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119303

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119303: Re: Intel I210 NIC only shows link status DOWN

2018-11-22T15:30:54Z

Still no luck.

Slog here:

Jan 01 00:01:14.513                    iopkt.36871                           0  -----ONLINE-----

Jan 01 00:01:14.514                    iopkt.36871          main_buffer*     0  tcpip starting

Jan 01 00:01:14.514                    iopkt.36871          main_buffer      0  Unable to open /dev/random: errno: 2

Jan 01 00:01:14.514                    iopkt.36871          main_buffer      0  Falling back on internal pseudo random generator

Jan 01 00:01:14.516                    iopkt.36871          main_buffer      0  initializing IPsec...

Jan 01 00:01:14.516                    iopkt.36871          main_buffer      0   done

Jan 01 00:01:14.516                    iopkt.36871          main_buffer      0  IPsec: Initialized Security Association Processing.

Jan 01 00:01:14.519                    iopkt.36871          main_buffer      0  devnp-e1000.so (null)

Jan 01 00:01:14.521             io_pkt_v6_hc.36871                           0  -----ONLINE-----

Jan 01 00:01:14.521             io_pkt_v6_hc.36871              pci_log*     0  INFO ,1,0,4 [36871:2]: SLOG module load successful for pid 36871 (io-pkt-v6-hc)

Jan 01 00:01:14.521             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Attempt module load of /lib/dll/pci/pci_hw-Intel_x86_APL.so

Jan 01 00:01:14.521             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module is compatible with Library ver 2.0

Jan 01 00:01:14.521             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module /lib/dll/pci/pci_hw-Intel_x86_APL.so, v2.1 loaded successfully

Jan 01 00:01:14.522          io_pkt_v6_hc.36871..0                           0  -----ONLINE-----

Jan 01 00:01:14.522             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Attempt module load of /lib/dll/pci/pci_debug2.so

Jan 01 00:01:14.522             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module /lib/dll/pci/pci_debug2.so, v2.1 loaded successfully

Jan 01 00:01:14.522          io_pkt_v6_hc.36871..0              pci_dbg*     0  DEBUG,1,1,4 [36871:2]: find_ecam_base(): trying offset 0x60 for vid/did 8086/5af0

Jan 01 00:01:14.523          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,1,4 [36871:2]: find_ecam_base(): found ecam base 0xe0000000

Jan 01 00:01:14.534          io_pkt_v6_hc.36871..1                           0  -----ONLINE-----

Jan 01 00:01:14.534                    iopkt.36871          main_buffer      0  wm0

Jan 01 00:01:14.534             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: Successful connection to PCI server on /dev/pci

Jan 01 00:01:14.534             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Capability modules will be searched for in directory /lib/dll/pci

Jan 01 00:01:14.534             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Attempt module load of /lib/dll/pci/pci_cap-0x10-8086157b.so

Jan 01 00:01:14.534             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x10.so

Jan 01 00:01:14.534          io_pkt_v6_hc.36871..1                 slog*     0  *** found B5:D0:F0

Jan 01 00:01:14.534          io_pkt_v6_hc.36871..1                 slog      0  *** device is supported, attaching

Jan 01 00:01:14.534                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:3]: msg_handler(msg type: 33, connect_entry: 806e0f8) reply_len = 8, OK [PCI_ERR_OK]

Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: Module is compatible with Library ver 2.0

Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module /lib/dll/pci/pci_cap-0x10.so, v2.0 loaded successfully

Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x10-8086157b.so ... not found

Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x10.so

Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Attempt module load of /lib/dll/pci/pci_cap-0x11-8086157b.so

Jan 01 00:01:14.535             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x11.so

Jan 01 00:01:14.535          io_pkt_v6_hc.36871..1                 slog      0  Unable to enable PCIe capabilities, Requested Operation, Condition Or Data Already Exists [PCI_ERR_EALREADY]

Jan 01 00:01:14.536             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: Module is compatible with Library ver 2.0

Jan 01 00:01:14.536             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,0,4 [36871:2]: Module /lib/dll/pci/pci_cap-0x11.so, v2.0 loaded successfully

Jan 01 00:01:14.536             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x11-8086157b.so ... not found

Jan 01 00:01:14.536             io_pkt_v6_hc.36871              pci_log      0  INFO ,1,1,4 [36871:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x11.so

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820e088) returns 5

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..0              pci_dbg      0  DEBUG,1,3,4 [36871:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 3 disabled

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 4 disabled

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X capabilities enabled

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 0 unmasked

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 1 unmasked

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  MSI-X interrupt entry 2 unmasked

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  *** mmap_device_memory @ 81100000 to 180097000

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  *** 3 irqs

Jan 01 00:01:14.536          io_pkt_v6_hc.36871..1                 slog      0  translate 0x17a112000, len 1000

#slay io-pkt-v6-hc

# io-pkt-v6-hc -de1000 -vvvvv

# ifconfig wm0 up

*plugged in cable here*

# nicinfo

wm0:

  INTEL PRO/1000 Gigabit (Copper) Ethernet Controller

  Link is DOWN

  Physical Node ID ........................... 00E04B 6564AD

  Current Physical Node ID ................... 00E04B 6564AD

  Current Operation Rate ..................... Unknown

  Active Interface Type ...................... MII

    Active PHY address ....................... 1

  Maximum Transmittable data Unit ............ 1500

  Maximum Receivable data Unit ............... 1500

  Hardware Interrupt ......................... 0x100

  Hardware Interrupt ......................... 0x101

  Hardware Interrupt ......................... 0x102

  Memory Aperture ............................ 0x81100000 - 0x8111ffff

  Promiscuous Mode ........................... Off

  Multicast Support .......................... Enabled

  Packets Transmitted OK ..................... 0

  Bytes Transmitted OK ....................... 0

  Broadcast Packets Transmitted OK ........... 0

  Multicast Packets Transmitted OK ........... 0

  Memory Allocation Failures on Transmit ..... 0

  Packets Received OK ........................ 2

  Bytes Received OK .......................... 618

  Broadcast Packets Received OK .............. 2

  Multicast Packets Received OK .............. 0

  Memory Allocation Failures on Receive ...... 0

  Single Collisions on Transmit .............. 0

  Multiple Collisions on Transmit ............ 0

  Deferred Transmits ......................... 0

  Late Collision on Transmit errors .......... 0

  Transmits aborted (excessive collisions) ... 0

  Jabber detected ............................ 0

  Receive Alignment errors ................... 0

  Received packets with CRC errors ........... 0

  Packets Dropped on receive ................. 0

  Oversized Packets received ................. 0

  Short packets .............................. 0

  Squelch Test errors ........................ 0

  Invalid Symbol Errors ...................... 0

post119302: Re: Intel I210 NIC only shows link status DOWN

2018-11-22T15:12:54Z

One more test please! Remove the network cable, start the driver with "verbose=3" on the command line, "ifconfig wm0 up" and then plug in the network cable. Run "nicinfo wm0" to see if the link is up.

If the link still doesn't come up, then I will need the hardware to debug this problem. Please also send me the slog2info output.

Hugh.

On 2018-11-22, 8:58 AM, "John Scarrott" <community-noreply@qnx.com> wrote:

    I appreciate how difficult these things can be to debug without the hardware, thanks for your help!



    pidin irq looks like this:





         pid tid name

           1   1 /procnto-smp-instr

           1   2 /procnto-smp-instr

                    0            0x2    0 -P-N- @0xffff800000077f50:0

           1   3 /procnto-smp-instr

           1   4 /procnto-smp-instr

           1   5 /procnto-smp-instr

           1   6 /procnto-smp-instr

           1   7 /procnto-smp-instr

           1   8 /procnto-smp-instr

           1   9 /procnto-smp-instr

           1  10 /procnto-smp-instr

           1  11 /procnto-smp-instr

           1  12 /procnto-smp-instr

           1  13 /procnto-smp-instr

           1  14 /procnto-smp-instr

           1  15 /procnto-smp-instr

           1  16 /procnto-smp-instr

           2   1 bin/slogger2

           2   2 bin/slogger2

           3   1 sbin/pci-server

           3   2 sbin/pci-server

           3   3 sbin/pci-server

           4   1 sbin/pipe

           4   2 sbin/pipe

           4   3 sbin/pipe

           5   1 bin/devc-pty

           6   1 usr/sbin/qconn

           6   2 usr/sbin/qconn

           8   1 usr/sbin/inetd

        4103   1 sbin/io-pkt-v6-hc

        4103   2 sbin/io-pkt-v6-hc

                    1          0x100    0 T---- @0x1004fa9c0:0x821dcc0

                    2          0x102    0 T---- @0x1004fa7a0:0x821dcc0

                    3          0x101    0 T---- @0x1004fa820:0x821dcc0

        4103   3 sbin/io-pkt-v6-hc

       16393   1 sbin/devc-ser8250

                    4            0x4    0 T---- @0x804b540:0x805e088

                    5            0x3    0 T---- @0x804b540:0x805e0d8

       16395   1 bin/sh

       20492   1 bin/sh

       24586   1 sbin/io-usb-otg

       24586   2 sbin/io-usb-otg

       24586   3 sbin/io-usb-otg

       24586   4 sbin/io-usb-otg

       24586   5 sbin/io-usb-otg

       24586   6 sbin/io-usb-otg

       24586   7 sbin/io-usb-otg

       24586   8 sbin/io-usb-otg

       24586   9 sbin/io-usb-otg

       24586  10 sbin/io-usb-otg

       24586  11 sbin/io-usb-otg

                    6          0x103    0 TP--- =PULSE 0x40000014:24 0x1:0

       24586  12 sbin/io-usb-otg

       24586  13 sbin/io-usb-otg

       24589   1 sbin/devb-umass

       24589   2 sbin/devb-umass

       24589   3 sbin/devb-umass

       24589   4 sbin/devb-umass

       24589   5 sbin/devb-umass

       24589   6 sbin/devb-umass

       24589   7 sbin/devb-umass

       24589   8 sbin/devb-umass

       24589   9 sbin/devb-umass

       24589  10 sbin/devb-umass

       24590   1 sbin/devc-con-hid

       24591   1 bin/sh

       24592   1 bin/sh

       24593   1 bin/slog2info

       36882   1 bin/pidin









    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119301

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119301: Re: Intel I210 NIC only shows link status DOWN

2018-11-22T13:58:27Z

I appreciate how difficult these things can be to debug without the hardware, thanks for your help!

pidin irq looks like this:

     pid tid name

       1   1 /procnto-smp-instr

       1   2 /procnto-smp-instr

                0            0x2    0 -P-N- @0xffff800000077f50:0

       1   3 /procnto-smp-instr

       1   4 /procnto-smp-instr

       1   5 /procnto-smp-instr

       1   6 /procnto-smp-instr

       1   7 /procnto-smp-instr

       1   8 /procnto-smp-instr

       1   9 /procnto-smp-instr

       1  10 /procnto-smp-instr

       1  11 /procnto-smp-instr

       1  12 /procnto-smp-instr

       1  13 /procnto-smp-instr

       1  14 /procnto-smp-instr

       1  15 /procnto-smp-instr

       1  16 /procnto-smp-instr

       2   1 bin/slogger2

       2   2 bin/slogger2

       3   1 sbin/pci-server

       3   2 sbin/pci-server

       3   3 sbin/pci-server

       4   1 sbin/pipe

       4   2 sbin/pipe

       4   3 sbin/pipe

       5   1 bin/devc-pty

       6   1 usr/sbin/qconn

       6   2 usr/sbin/qconn

       8   1 usr/sbin/inetd

    4103   1 sbin/io-pkt-v6-hc

    4103   2 sbin/io-pkt-v6-hc

                1          0x100    0 T---- @0x1004fa9c0:0x821dcc0

                2          0x102    0 T---- @0x1004fa7a0:0x821dcc0

                3          0x101    0 T---- @0x1004fa820:0x821dcc0

    4103   3 sbin/io-pkt-v6-hc

   16393   1 sbin/devc-ser8250

                4            0x4    0 T---- @0x804b540:0x805e088

                5            0x3    0 T---- @0x804b540:0x805e0d8

   16395   1 bin/sh

   20492   1 bin/sh

   24586   1 sbin/io-usb-otg

   24586   2 sbin/io-usb-otg

   24586   3 sbin/io-usb-otg

   24586   4 sbin/io-usb-otg

   24586   5 sbin/io-usb-otg

   24586   6 sbin/io-usb-otg

   24586   7 sbin/io-usb-otg

   24586   8 sbin/io-usb-otg

   24586   9 sbin/io-usb-otg

   24586  10 sbin/io-usb-otg

   24586  11 sbin/io-usb-otg

                6          0x103    0 TP--- =PULSE 0x40000014:24 0x1:0

   24586  12 sbin/io-usb-otg

   24586  13 sbin/io-usb-otg

   24589   1 sbin/devb-umass

   24589   2 sbin/devb-umass

   24589   3 sbin/devb-umass

   24589   4 sbin/devb-umass

   24589   5 sbin/devb-umass

   24589   6 sbin/devb-umass

   24589   7 sbin/devb-umass

   24589   8 sbin/devb-umass

   24589   9 sbin/devb-umass

   24589  10 sbin/devb-umass

   24590   1 sbin/devc-con-hid

   24591   1 bin/sh

   24592   1 bin/sh

   24593   1 bin/slog2info

   36882   1 bin/pidin

post119300: Re: Intel I210 NIC only shows link status DOWN

2018-11-22T13:41:16Z

When you run "pidin irq", what interrupt does the USB driver get? The e1000 driver definitely works, so this has something to do with interrupts, but not having the hardware here makes it difficult to debug.

On 2018-11-22, 5:06 AM, "John Scarrott" <community-noreply@qnx.com> wrote:

    I had another look at the USB and it actually works. I was just starting the driver incorrectly. So as far I can tell it is only the ethernet that doesn't work.







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119298

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119298: Re: Intel I210 NIC only shows link status DOWN

2018-11-22T10:06:46Z

I had another look at the USB and it actually works. I was just starting the driver incorrectly. So as far I can tell it is only the ethernet that doesn't work.

post119297: Re: Intel I210 NIC only shows link status DOWN

2018-11-15T21:47:21Z

I manually enabled USB support to check as you asked. It isn't super important for my use case so I hadn't added it to the startup script yet. I won't have a chance to look at it until next week now, but thanks for all the help so far. I wonder if a BIOS setting has broken it?

post119296: Re: Intel I210 NIC only shows link status DOWN

2018-11-15T18:01:53Z

Feedback from our PCI developer:

Nothing jumps out in the log file. I have an Apollo Lake here (not the Kontron board specifically) and I can assure you MSI's work.

A couple of notes from the build file.

They should limit the bus scan when they start the pci-server to avoid polluting the logs (--bus-scan-limit=6 should be sufficient)

Also, they said USB isn't working but in the build file it isn't even started and there is no record in the sloginfo of USB running.

Can you reconfirm. They must be doing something wrong

On 2018-11-15, 9:08 AM, "John Scarrott" <community-noreply@qnx.com> wrote:

    I'm also attaching my startup script in case that helps







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119295

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119295: Re: Intel I210 NIC only shows link status DOWN

2018-11-15T17:08:47Z

I'm also attaching my startup script in case that helps

post119294: Re: Intel I210 NIC only shows link status DOWN

2018-11-15T17:06:11Z

I am no using startup-x86 but it has made no difference. I've attached the slog output. Thanks

post119293: Re: Intel I210 NIC only shows link status DOWN

2018-11-15T16:56:47Z

Please can you try the following:

They should be able to use startup-x86 with UEFI for the boot.

Tell them to make sure slogger2 -s2048k in the build file before pci-server and  then have them send the output of slog2info

Also have them make sure that where the PCI components are located (usually /lib/dll/pci/) is in their LD_LIBRARY_PATH. Maybe it can't find the modules it needs. slog2info will tell us.

On 2018-11-15, 5:46 AM, "John Scarrott" <community-noreply@qnx.com> wrote:

    I don't know if this makes any difference but I am using startup-UEFI as the BIOS does not seem to support legacy booting.







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119292

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119292: Re: Intel I210 NIC only shows link status DOWN

2018-11-15T13:46:48Z

I don't know if this makes any difference but I am using startup-UEFI as the BIOS does not seem to support legacy booting.

post119291: Re: Intel I210 NIC only shows link status DOWN

2018-11-15T09:55:26Z

     pid tid name

       1   1 /procnto-smp-instr

       1   2 /procnto-smp-instr

                0            0x2    0 -P-N- @0xffff800000077f50:0

       1   3 /procnto-smp-instr

       1   4 /procnto-smp-instr

       1   5 /procnto-smp-instr

       1   6 /procnto-smp-instr

       1   7 /procnto-smp-instr

       1   8 /procnto-smp-instr

       1   9 /procnto-smp-instr

       1  10 /procnto-smp-instr

       1  11 /procnto-smp-instr

       1  12 /procnto-smp-instr

       1  13 /procnto-smp-instr

       1  14 /procnto-smp-instr

       1  15 /procnto-smp-instr

       1  16 /procnto-smp-instr

       2   1 bin/slogger2

       2   2 bin/slogger2

       3   1 sbin/pci-server

       3   2 sbin/pci-server

       3   3 sbin/pci-server

       4   1 sbin/pipe

       4   2 sbin/pipe

       4   3 sbin/pipe

       5   1 bin/devc-pty

       6   1 usr/sbin/qconn

       6   2 usr/sbin/qconn

       8   1 usr/sbin/inetd

    4103   1 sbin/devb-sdmmc

                1           0x27    0 TP--- =PULSE 0x40000006:21 0x3:0

    4103   2 sbin/devb-sdmmc

    4103   3 sbin/devb-sdmmc

    4103   4 sbin/devb-sdmmc

    4103   5 sbin/devb-sdmmc

    4103   6 sbin/devb-sdmmc

    4103   7 sbin/devb-sdmmc

    4103   8 sbin/devb-sdmmc

    4103   9 sbin/devb-sdmmc

    4103  10 sbin/devb-sdmmc

    4105   1 sbin/io-pkt-v6-hc

    4105   2 sbin/io-pkt-v6-hc

                2          0x100    0 T---- @0x1004fa9c0:0x821dcc0

                3          0x102    0 T---- @0x1004fa7a0:0x821dcc0

                4          0x101    0 T---- @0x1004fa820:0x821dcc0

    4105   3 sbin/io-pkt-v6-hc

   32779   1 sbin/dhclient

   36874   1 sbin/devc-ser8250

                5            0x4    0 T---- @0x804b540:0x805e088

                6            0x3    0 T---- @0x804b540:0x805e0d8

   36877   1 bin/sh

   40972   1 sbin/devc-con-hid

   40974   1 bin/sh

   40975   1 bin/sh

   57360   1 bin/pidin

Replugging doesn't help, and after you mentioned it USB does not work either. I've also tried multiple cables, switches, etc.

PCI_MODULE_BLACKLIST=pci_cap-0x11.so io-pkt-v6-hc -de1000 verbose=3

Didn't seem to do anything much.

post119290: Re: Intel I210 NIC only shows link status DOWN

2018-11-14T17:50:30Z

We need to find out if it is a problem with MSIX interrupts. Please can you post the output from "pidin irq"? Is USB working?

Also, if you unplug the link and then re-plug it, does the link come up?

You can also try the following:

PCI_MODULE_BLACKLIST=pci_cap-0x11.so io-pkt-v6-hc -de1000 verbose=3

Ifconfig wm0 192.168.0.1

Does the link come up after doing this?

On 2018-11-14, 9:08 AM, "John Scarrott" <community-noreply@qnx.com> wrote:

    Yeah there is no link UP event in slog after calling ifconfig up, all I get is this:



    Jan 01 00:00:30.099          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,1,4 [53257:2]: find_ecam_base(): found ecam base 0xe0000000

    Jan 01 00:00:30.116          io_pkt_v6_hc.53257..1                 slog*     0  *** found B5:D0:F0

    Jan 01 00:00:30.117                    iopkt.53257          main_buffer      0  wm0



    Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: Successful connection to PCI server on /dev/pci

    Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Capability modules will be searched for in directory /lib/dll/pci

    Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Attempt module load of /lib/dll/pci/pci_cap-0x10-8086157b.so

    Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x10.so

    Jan 01 00:00:30.117          io_pkt_v6_hc.53257..1                 slog      0  *** device is supported, attaching

    Jan 01 00:00:30.117                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 33, connect_entry: 806c1d8) reply_len = 8, OK [PCI_ERR_OK]

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: Module is compatible with Library ver 2.0

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Module /lib/dll/pci/pci_cap-0x10.so, v2.0 loaded successfully

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x10-8086157b.so ... not found

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x10.so

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Attempt module load of /lib/dll/pci/pci_cap-0x11-8086157b.so

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x11.so

    Jan 01 00:00:30.118          io_pkt_v6_hc.53257..1                 slog      0  Unable to enable PCIe capabilities, Requested Operation, Condition Or Data Already Exists [PCI_ERR_EALREADY]

    Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: Module is compatible with Library ver 2.0

    Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Module /lib/dll/pci/pci_cap-0x11.so, v2.0 loaded successfully

    Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x11-8086157b.so ... not found

    Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x11.so

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820e088) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 3 disabled

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 4 disabled

    Jan 01 00:00:30.119                   pci_server.3              pci_log      0  INFO ,1,1,4 [3:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x11-8086157b.so ... not found

    Jan 01 00:00:30.119                   pci_server.3              pci_log      0  INFO ,1,1,4 [3:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x11   pci_dbg      0  DEBUG,1,3,4 [3:2]: rsrcdb_irq_resv(0, 0x0, 3, 80692c8->[0]=174,...) returned OK [PCI_ERR_OK]

    Jan 01 00:00:30.119                   pci_server.3              pci_log      0  INFO ,1,2,4 [3:2]: hw_alloc_irq(B5:D0:F0, 0, 0x0, 3, 806d268) OK [PCI_ERR_OK]

    Jan 01 00:00:30.119                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: _cap_msix_get_nirq(806b490) returns 5

    Jan 01 00:00:30.119                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: MSI-X vector table (5 vectors, sz=0x1000) at 81120000 mapped to 180095000 for server and pid 53257

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X capabilities enabled

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 0 unmasked

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 1 unmasked

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 2 unmasked

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  *** mmap_device_memory @ 81100000 to 180097000

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  *** 3 irqs

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  translate 0x17a4a2000, len 1000

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  bmtrans is 0x0

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  i82544_pci_attach: rar entries 16

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: _cap_msix_get_nirq(806b490) returns 5

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: MSI-X PBA (5 vectors, sz=0x1000) at 81122000 mapped to 180096000 for server and pid 53257

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 25, connect_entry: 806c1d8) reply_len = 100, OK [PCI_ERR_OK]

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 24, connect_entry: 806c1d8) reply_len = 224, OK [PCI_ERR_OK]

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 23, connect_entry: 806c1d8) reply_len = 20, OK [PCI_ERR_OK]

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 22, connect_entry: 806c1d8) reply_len = 0, OK [PCI_ERR_OK]

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  INTEL PRO/1000 Gigabit (Copper)

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Vendor .............. 0x8086

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Device .............. 0x157b

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Revision ............ 0x0

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Memory base ......... 0x81100000





    Thanks for the quick response! It really means a lot. I'm not sure how I would go about debugging the interupts, any advice?







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119288

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119289: Re: Intel I210 NIC only shows link status DOWN

2018-11-14T17:14:44Z

I'll ask out PCI developer to take a look at this.

On 2018-11-14, 9:08 AM, "John Scarrott" <community-noreply@qnx.com> wrote:

    Yeah there is no link UP event in slog after calling ifconfig up, all I get is this:



    Jan 01 00:00:30.099          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,1,4 [53257:2]: find_ecam_base(): found ecam base 0xe0000000

    Jan 01 00:00:30.116          io_pkt_v6_hc.53257..1                 slog*     0  *** found B5:D0:F0

    Jan 01 00:00:30.117                    iopkt.53257          main_buffer      0  wm0



    Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: Successful connection to PCI server on /dev/pci

    Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Capability modules will be searched for in directory /lib/dll/pci

    Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Attempt module load of /lib/dll/pci/pci_cap-0x10-8086157b.so

    Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x10.so

    Jan 01 00:00:30.117          io_pkt_v6_hc.53257..1                 slog      0  *** device is supported, attaching

    Jan 01 00:00:30.117                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 33, connect_entry: 806c1d8) reply_len = 8, OK [PCI_ERR_OK]

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: Module is compatible with Library ver 2.0

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Module /lib/dll/pci/pci_cap-0x10.so, v2.0 loaded successfully

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x10-8086157b.so ... not found

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x10.so

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Attempt module load of /lib/dll/pci/pci_cap-0x11-8086157b.so

    Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x11.so

    Jan 01 00:00:30.118          io_pkt_v6_hc.53257..1                 slog      0  Unable to enable PCIe capabilities, Requested Operation, Condition Or Data Already Exists [PCI_ERR_EALREADY]

    Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: Module is compatible with Library ver 2.0

    Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Module /lib/dll/pci/pci_cap-0x11.so, v2.0 loaded successfully

    Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x11-8086157b.so ... not found

    Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x11.so

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820e088) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 3 disabled

    Jan 01 00:00:30.119          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 4 disabled

    Jan 01 00:00:30.119                   pci_server.3              pci_log      0  INFO ,1,1,4 [3:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x11-8086157b.so ... not found

    Jan 01 00:00:30.119                   pci_server.3              pci_log      0  INFO ,1,1,4 [3:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x11   pci_dbg      0  DEBUG,1,3,4 [3:2]: rsrcdb_irq_resv(0, 0x0, 3, 80692c8->[0]=174,...) returned OK [PCI_ERR_OK]

    Jan 01 00:00:30.119                   pci_server.3              pci_log      0  INFO ,1,2,4 [3:2]: hw_alloc_irq(B5:D0:F0, 0, 0x0, 3, 806d268) OK [PCI_ERR_OK]

    Jan 01 00:00:30.119                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: _cap_msix_get_nirq(806b490) returns 5

    Jan 01 00:00:30.119                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: MSI-X vector table (5 vectors, sz=0x1000) at 81120000 mapped to 180095000 for server and pid 53257

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X capabilities enabled

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 0 unmasked

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 1 unmasked

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 2 unmasked

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  *** mmap_device_memory @ 81100000 to 180097000

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  *** 3 irqs

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  translate 0x17a4a2000, len 1000

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  bmtrans is 0x0

    Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  i82544_pci_attach: rar entries 16

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: _cap_msix_get_nirq(806b490) returns 5

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: MSI-X PBA (5 vectors, sz=0x1000) at 81122000 mapped to 180096000 for server and pid 53257

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 25, connect_entry: 806c1d8) reply_len = 100, OK [PCI_ERR_OK]

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 24, connect_entry: 806c1d8) reply_len = 224, OK [PCI_ERR_OK]

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 23, connect_entry: 806c1d8) reply_len = 20, OK [PCI_ERR_OK]

    Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 22, connect_entry: 806c1d8) reply_len = 0, OK [PCI_ERR_OK]

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  INTEL PRO/1000 Gigabit (Copper)

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Vendor .............. 0x8086

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Device .............. 0x157b

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Revision ............ 0x0

    Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Memory base ......... 0x81100000





    Thanks for the quick response! It really means a lot. I'm not sure how I would go about debugging the interupts, any advice?







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119288

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119288: Re: Intel I210 NIC only shows link status DOWN

2018-11-14T17:08:39Z

Yeah there is no link UP event in slog after calling ifconfig up, all I get is this:

Jan 01 00:00:30.099          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,1,4 [53257:2]: find_ecam_base(): found ecam base 0xe0000000

Jan 01 00:00:30.116          io_pkt_v6_hc.53257..1                 slog*     0  *** found B5:D0:F0

Jan 01 00:00:30.117                    iopkt.53257          main_buffer      0  wm0

Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: Successful connection to PCI server on /dev/pci

Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Capability modules will be searched for in directory /lib/dll/pci

Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Attempt module load of /lib/dll/pci/pci_cap-0x10-8086157b.so

Jan 01 00:00:30.117             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x10.so

Jan 01 00:00:30.117          io_pkt_v6_hc.53257..1                 slog      0  *** device is supported, attaching

Jan 01 00:00:30.117                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 33, connect_entry: 806c1d8) reply_len = 8, OK [PCI_ERR_OK]

Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: Module is compatible with Library ver 2.0

Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Module /lib/dll/pci/pci_cap-0x10.so, v2.0 loaded successfully

Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x10-8086157b.so ... not found

Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x10.so

Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Attempt module load of /lib/dll/pci/pci_cap-0x11-8086157b.so

Jan 01 00:00:30.118             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Re-attempt module load of /lib/dll/pci/pci_cap-0x11.so

Jan 01 00:00:30.118          io_pkt_v6_hc.53257..1                 slog      0  Unable to enable PCIe capabilities, Requested Operation, Condition Or Data Already Exists [PCI_ERR_EALREADY]

Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: Module is compatible with Library ver 2.0

Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,0,4 [53257:2]: Module /lib/dll/pci/pci_cap-0x11.so, v2.0 loaded successfully

Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x11-8086157b.so ... not found

Jan 01 00:00:30.119             io_pkt_v6_hc.53257              pci_log      0  INFO ,1,1,4 [53257:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x11.so

Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820e088) returns 5

Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:00:30.119          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:00:30.119          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 3 disabled

Jan 01 00:00:30.119          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 4 disabled

Jan 01 00:00:30.119                   pci_server.3              pci_log      0  INFO ,1,1,4 [3:2]: B5:D0:F0 - Check for /lib/dll/pci/pci_cap-0x11-8086157b.so ... not found

Jan 01 00:00:30.119                   pci_server.3              pci_log      0  INFO ,1,1,4 [3:2]: B5:D0:F0 - Found /lib/dll/pci/pci_cap-0x11   pci_dbg      0  DEBUG,1,3,4 [3:2]: rsrcdb_irq_resv(0, 0x0, 3, 80692c8->[0]=174,...) returned OK [PCI_ERR_OK]

Jan 01 00:00:30.119                   pci_server.3              pci_log      0  INFO ,1,2,4 [3:2]: hw_alloc_irq(B5:D0:F0, 0, 0x0, 3, 806d268) OK [PCI_ERR_OK]

Jan 01 00:00:30.119                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: _cap_msix_get_nirq(806b490) returns 5

Jan 01 00:00:30.119                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: MSI-X vector table (5 vectors, sz=0x1000) at 81120000 mapped to 180095000 for server and pid 53257

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..0              pci_dbg      0  DEBUG,1,3,4 [53257:2]: _cap_msix_get_nirq(820ad78) returns 5

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X capabilities enabled

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 0 unmasked

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 1 unmasked

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  MSI-X interrupt entry 2 unmasked

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  *** mmap_device_memory @ 81100000 to 180097000

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  *** 3 irqs

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  translate 0x17a4a2000, len 1000

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  bmtrans is 0x0

Jan 01 00:00:30.120          io_pkt_v6_hc.53257..1                 slog      0  i82544_pci_attach: rar entries 16

Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: _cap_msix_get_nirq(806b490) returns 5

Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: MSI-X PBA (5 vectors, sz=0x1000) at 81122000 mapped to 180096000 for server and pid 53257

Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 25, connect_entry: 806c1d8) reply_len = 100, OK [PCI_ERR_OK]

Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 24, connect_entry: 806c1d8) reply_len = 224, OK [PCI_ERR_OK]

Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 23, connect_entry: 806c1d8) reply_len = 20, OK [PCI_ERR_OK]

Jan 01 00:00:30.120                pci_server.3..0              pci_dbg      0  DEBUG,1,3,4 [3:2]: msg_handler(msg type: 22, connect_entry: 806c1d8) reply_len = 0, OK [PCI_ERR_OK]

Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  INTEL PRO/1000 Gigabit (Copper)

Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Vendor .............. 0x8086

Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Device .............. 0x157b

Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Revision ............ 0x0

Jan 01 00:00:30.437          io_pkt_v6_hc.53257..1                 slog      0  Memory base ......... 0x81100000

Thanks for the quick response! It really means a lot. I'm not sure how I would go about debugging the interupts, any advice?

post119287: Re: Intel I210 NIC only shows link status DOWN

2018-11-14T16:55:39Z

Yes, it appears that interrupts are not working. You can start the driver as follows - "io-pkt-v6-hc -de1000 verbose=3", which will output some debug information to slog2info. If you don't see a "Link up" message in slog2info after running ifconfig wm0 169.254.0.1, then it definitely looks like an interrupt problem on your board.

On 2018-11-14, 8:02 AM, "John Scarrott" <community-noreply@qnx.com> wrote:

    I'm trying to get QNX 7 working on a kontron mAL10 E3930. I've got the board booting fine but cannot get the network up and running.



    I'm running:



    io-pkt-v6-hc -d e1000 -p tcpip -vvvv &

    if_up -r 10 -p wm0

    ifconfig wm0 169.254.0.1 up



    which works fine with no errors reported and nothing obviously wrong in the slog. But ifconfig shows this:



    wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

            capabilities rx=1f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM>

            capabilities tx=7f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM,TSO4,TSO6>

            enabled=0

            address: 00:e0:4b:65:64:ad

            media: Ethernet autoselect (none)

            status: no carrier

            inet 169.254.0.1 netmask 0xffff0000 broadcast 169.254.255.255

            inet6 fe80::2e0:4bff:fe65:64ad%wm0 prefixlen 64 scopeid 0x11



    The link light works and I can disable it fine using the ifconfig wm0 down command.



    nicinfo reports:

    wm0:

      INTEL PRO/1000 Gigabit (Copper) Ethernet Controller



      Link is DOWN



      Physical Node ID ........................... 00E04B 6564AD

      Current Physical Node ID ................... 00E04B 6564AD

      Current Operation Rate ..................... Unknown

      Active Interface Type ...................... MII

        Active PHY address ....................... 1

      Maximum Transmittable data Unit ............ 1500

      Maximum Receivable data Unit ............... 1500

      Hardware Interrupt ......................... 0x100

      Hardware Interrupt ......................... 0x101

      Hardware Interrupt ......................... 0x102

      Memory Aperture ............................ 0x81100000 - 0x8111ffff

      Promiscuous Mode ........................... Off

      Multicast Support .......................... Enabled



      Packets Transmitted OK ..................... 0

      Bytes Transmitted OK ....................... 0

      Broadcast Packets Transmitted OK ........... 0

      Multicast Packets Transmitted OK ........... 0

      Memory Allocation Failures on Transmit ..... 0



      Packets Received OK ........................ 142

      Bytes Received OK .......................... 31449

      Broadcast Packets Received OK .............. 142

      Multicast Packets Received OK .............. 0

      Memory Allocation Failures on Receive ...... 0



      Single Collisions on Transmit .............. 0

      Multiple Collisions on Transmit ............ 0

      Deferred Transmits ......................... 0

      Late Collision on Transmit errors .......... 0

      Transmits aborted (excessive collisions) ... 0

      Jabber detected ............................ 0

      Receive Alignment errors ................... 0

      Received packets with CRC errors ........... 0

      Packets Dropped on receive ................. 0

      Oversized Packets received ................. 0

      Short packets .............................. 0

      Squelch Test errors ........................ 514

      Invalid Symbol Errors ...................... 0





    My only thoughts are perhaps the interrupts aren't setup correctly but I am unsure how to configure them.







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post119286

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post119286: Intel I210 NIC only shows link status DOWN

2018-11-14T16:02:08Z

I'm trying to get QNX 7 working on a kontron mAL10 E3930. I've got the board booting fine but cannot get the network up and running.

I'm running:

io-pkt-v6-hc -d e1000 -p tcpip -vvvv &

if_up -r 10 -p wm0

ifconfig wm0 169.254.0.1 up

which works fine with no errors reported and nothing obviously wrong in the slog. But ifconfig shows this:

wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

        capabilities rx=1f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM>

        capabilities tx=7f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM,TSO4,TSO6>

        enabled=0

        address: 00:e0:4b:65:64:ad

        media: Ethernet autoselect (none)

        status: no carrier

        inet 169.254.0.1 netmask 0xffff0000 broadcast 169.254.255.255

        inet6 fe80::2e0:4bff:fe65:64ad%wm0 prefixlen 64 scopeid 0x11

The link light works and I can disable it fine using the ifconfig wm0 down command.

nicinfo reports:

wm0:

  INTEL PRO/1000 Gigabit (Copper) Ethernet Controller

  Link is DOWN

  Physical Node ID ........................... 00E04B 6564AD

  Current Physical Node ID ................... 00E04B 6564AD

  Current Operation Rate ..................... Unknown

  Active Interface Type ...................... MII

    Active PHY address ....................... 1

  Maximum Transmittable data Unit ............ 1500

  Maximum Receivable data Unit ............... 1500

  Hardware Interrupt ......................... 0x100

  Hardware Interrupt ......................... 0x101

  Hardware Interrupt ......................... 0x102

  Memory Aperture ............................ 0x81100000 - 0x8111ffff

  Promiscuous Mode ........................... Off

  Multicast Support .......................... Enabled

  Packets Transmitted OK ..................... 0

  Bytes Transmitted OK ....................... 0

  Broadcast Packets Transmitted OK ........... 0

  Multicast Packets Transmitted OK ........... 0

  Memory Allocation Failures on Transmit ..... 0

  Packets Received OK ........................ 142

  Bytes Received OK .......................... 31449

  Broadcast Packets Received OK .............. 142

  Multicast Packets Received OK .............. 0

  Memory Allocation Failures on Receive ...... 0

  Single Collisions on Transmit .............. 0

  Multiple Collisions on Transmit ............ 0

  Deferred Transmits ......................... 0

  Late Collision on Transmit errors .......... 0

  Transmits aborted (excessive collisions) ... 0

  Jabber detected ............................ 0

  Receive Alignment errors ................... 0

  Received packets with CRC errors ........... 0

  Packets Dropped on receive ................. 0

  Oversized Packets received ................. 0

  Short packets .............................. 0

  Squelch Test errors ........................ 514

  Invalid Symbol Errors ...................... 0

My only thoughts are perhaps the interrupts aren't setup correctly but I am unsure how to configure them.

post119275: Re: how to use devnp-rum.so ?

2018-11-05T06:05:43Z

update

I disabled security of my router, then configure /etc/wpa_supplicant.conf

network={

ssid="MYWIFI"

key_mgmt=NONE

}

RT2501/RT2573 USB dongle is able to DHCP wifi address, and ping router 192.168.31.1

However, never able to get WPA-PSK working.

network={

    ssid="MYWIFI"

    key_mgmt=WPA-PSK

    psk="1234567890"

}

Please advise, thanks in advance.

Mike

post119274: how to use devnp-rum.so ?

2018-11-03T12:14:34Z

Hi QNX,

             beaglebone black, QNX 6.5SP1, bsp-nto650-ti-beaglebone-sp1-trunk-201209071340, devnp-rum.so,

             148f:2573 Ralink Technology, Corp. RT2501/RT2573 Wireless Adapter

I am working on this usb wifi dongle, RT2501/RT2573 Wireless Adapter, with beaglebone black on QNX 6.5SP1.

# io-pkt-v4-hc -drum

# ifconfig rum0 up

# wpa_supplicant -B -i rum0 -c /etc/wpa_supplicant.conf

# dhcp.client -i rum0

#  if_up -r 15 rum0

       if_up: retries exhausted

       Process 131097 (if_up) exited status=7.

# ifconfig rum0

rum0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

ssid MYWIFI nwkey 65536:"","","",""

powersave off

bssid 28:6c:07:9a:c1:8d chan 4

address: 78:44:76:7a:8c:af

media: IEEE802.11 autoselect (OFDM36 mode 11g)

status: active

inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255

# cat /etc/wpa_supplicant.conf

network={

    ssid="MYWIFI"

    psk="1234567890"

}

I also tried to setup a fixed network address,

# io-pkt-v4-hc -drum

# ifconfig rum0 up

# wpa_supplicant -B -i rum0 -c /etc/wpa_supplicant.conf

# ifconfig rum0 192.168.31.201

# ifconfig rum0

rum0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

ssid MYWIFI nwkey 65536:"","","",""

powersave off

bssid 28:6c:07:9a:c1:8d chan 4

address: 78:44:76:7a:8c:af

media: IEEE802.11 autoselect (OFDM36 mode 11g)

status: active

inet 192.168.31.201 netmask 0xffffff00 broadcast 192.168.31.255

# ping 192.168.31.1

PING 192.168.31.1 (192.168.31.1): 56 data bytes

ping: sendto: Host is down

ping: sendto: Host is down

ping: sendto: Host is down

The router is working fine, my lapton/smart phone are surfing INTERNET now.

Please advise, thanks in advance

Mike

post119273: please help build the example packages

2018-11-01T12:26:10Z

Hi QNX,

beaglebone black, QNX 6.5SP1, bsp-nto650-ti-beaglebone-sp1-trunk-201209071340

I am working on usb-wifi drivers, and collected example packages from the previous post in this forum, http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/discussion.drivers.topc22270

such as run.src.tar.gz, rum_ural.tar.gz in the post attachment.

However, the package cannot be compiled, apparently missing libraries, such as /sys/kernel.h

Please advise, thanks in advance.

Mike

post119224: Re: Ethernet AVB driver for I.MX6 Solo X

2018-10-19T16:42:30Z

The i,MX6 SoloX driver includes support for Ethernet AVB consisting of ioctl()s that set traffic shaping, multiple Tx and Rx queues and a low latency receive thread for AVB traffic. It also supports PTP.

Regards,

Nick

post119223: Ethernet AVB driver for I.MX6 Solo X

2018-10-19T15:52:06Z

Hi,

In founday27 I see a link to download i.MX6SoloX BSP, wanted to know if this BSP includes corresponding Ethernet AVB driver i.e. driver for Traffic shaping, Multi queues which is part of SoloX SoC? I am assuming PTP driver will any way available in BSP. Please do let me know if not i.MX6Solo X then any other BSP of any other h/w includes these driver?

Thanks a lot in advance for help.

Regards

Ashok

post119046: [QNX 6.6] Ethernet over USB using RNDIS on x86

2018-08-10T21:42:30Z

I have an x86 target which is acting as a USB host to communicate with a USB device using RNDIS. I'm using QNX 6.6. I'm attempting the following:

io-pkt-v4-hc verbose -p tcpip

io-usb-dcd -dehci -duhci -dohci

waitfor /dev/io-usb-dcd/io-usb 5

mount -Tio-pkt -o mac=00D056F2B512,usbdnet_mac=00D056F2B513,protocol=rndis devnp-usbdnet.so

if_up -p rndis0

ifconfig rndis0 10.100.8.113

what I see is to the following:

# sloginfo -c

Time             Sev Major Minor Args

Jul 16 15:51:19    5    14     0 tcpip starting

Jul 16 15:51:19    3    14     0 Using pseudo random generator.  See "random" option

Jul 16 15:51:19    5    14     0 initializing IPsec... done

Jul 16 15:51:19    5    14     0 IPsec: Initialized Security Association Processing.

Jul 16 15:51:19    2    10     0 usbmgr_connection_create() Failed to attach to root device for cfg (status = 19)

Jul 16 15:51:19    2    10     0 usbdif_init() Couln't create configuration connection to the usb stack... using default

descriptors ( error = 19 )

Jul 16 15:51:19    5    14     0 rndis0

Questions:

1) The usbdnet_mac is incorrect. How do I display the MAC address of the local USB port in QNX? I will try to see if I

can give it when I attached the device to Windows.

2) Does anyone have a suggestion of usbmgr_connection_create() is failing to attach?

The device I wish to communicate with is showing up on USB 5. See attached file for info from the "usb -v" command.

post118973: Re: Intel i218 and QNX 6.3.2

2018-07-19T14:39:41Z

Th i218 isn't supported by the 6.3.2 driver, so if you want support for it, you will have to contact your sales representative.

On 2018-07-19, 9:55 AM, "Ramiro Vota" <community-noreply@qnx.com> wrote:

    Hi everybody, I recently bought an Advantech's ARK 1550. This machine has an intel i210 and an intel i218 ethernet chipset.

    I´ve installed QNX 6.3.2 and I downloaded the driver devn-e1000.so from the post http://community.qnx.com/sf/go/projects.networking/discussion.drivers.topc27366

    This driver works OK for the i210, but I can´t make it work for the i218.

    Is there any update of the devn-e1000.so that works with the i218?

    The device PCI-ID is DID=0x155A.

    Thanks in advance.

      Ramiro











    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118971

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118971: Intel i218 and QNX 6.3.2

2018-07-19T14:12:32Z

Hi everybody, I recently bought an Advantech's ARK 1550. This machine has an intel i210 and an intel i218 ethernet chipset.

I´ve installed QNX 6.3.2 and I downloaded the driver devn-e1000.so from the post http://community.qnx.com/sf/go/projects.networking/discussion.drivers.topc27366

This driver works OK for the i210, but I can´t make it work for the i218.

Is there any update of the devn-e1000.so that works with the i218?

The device PCI-ID is DID=0x155A.

Thanks in advance.

Ramiro

post118959: Re: Intel I210 and I217 Gigabit ethernet support in devnp-e1000.so (qnx 6.5)?

2018-07-16T12:44:42Z

The enumeration files are out of date, so you will have to do the following:

Edit the /etc/rc.d/rc.local file and add the following

slay -f io-pkt-v4 io-pkt-v4-hc io-pkt-v6-hc dhcp.client

sleep 2

io-pkt-v4-hc -de1000

if_up -p wm0

dhcp.client -iwm0

You can modify the above to suite your needs.

Hugh.

On 2018-07-16, 8:20 AM, "Santosh Patil" <community-noreply@qnx.com> wrote:

    It's full fledged OS, installed. From QNX 6.5 NTO ISO.



    I just replaced your provided files.







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118958

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118958: Re: Intel I210 and I217 Gigabit ethernet support in devnp-e1000.so (qnx 6.5)?

2018-07-16T12:38:14Z

It's full fledged OS, installed. From QNX 6.5 NTO ISO.

I just replaced your provided files.

post118957: Re: Intel I210 and I217 Gigabit ethernet support in devnp-e1000.so (qnx 6.5)?

2018-07-16T12:35:41Z

Please post your build file, so that I can see what you are doing.

Thanks, Hugh.

On 2018-07-16, 6:59 AM, "Santosh Patil" <community-noreply@qnx.com> wrote:

    Hello Hugh,



    Thanks a lot for your help. They did actually work.



    Just one thing, they could not start on start-up, I had to run the script manually to get divers up and running. Which I can put into some boot-up script.







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118956

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118956: Re: Intel I210 and I217 Gigabit ethernet support in devnp-e1000.so (qnx 6.5)?

2018-07-16T11:17:06Z

Hello Hugh,

Thanks a lot for your help. They did actually work.

Just one thing, they could not start on start-up, I had to run the script manually to get divers up and running. Which I can put into some boot-up script.

post118922: Re: Intel I210 and I217 Gigabit ethernet support in devnp-e1000.so (qnx 6.5)?

2018-07-09T13:35:11Z

I have attached the latest io-pkt-v4-hc.

On 2018-07-09, 8:26 AM, "Santosh Patil" <community-noreply@qnx.com> wrote:

    Hello,



    I'm trying devnp-e1000.so.



    I copied that particular file into home folder and ran



    /sbin/io-pkt-v4-hc

    mount -T io-pkt /home/devnp-e1000.so



    after running this I can see interfaces in



    nicinfo and also in gui-network-interface.



    But soon after running this command I'm getting following error and /sbin/io-pkt-v4-hc process gets halted



    "ldd:FATAL: Unresolved symbol "stk_context_callback_2" called from devnp-e1000.so"



    AM I missing to load another library which is required ?







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118919

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118920: Re: Intel I210 and I217 Gigabit ethernet support in devnp-e1000.so (qnx 6.5)?

2018-07-09T12:47:57Z

You will need the latest io-pkt-v4-hc to resolve this symbol. I'll have to see where you can find it and get back to you.

On 2018-07-09, 8:26 AM, "Santosh Patil" <community-noreply@qnx.com> wrote:

    Hello,



    I'm trying devnp-e1000.so.



    I copied that particular file into home folder and ran



    /sbin/io-pkt-v4-hc

    mount -T io-pkt /home/devnp-e1000.so



    after running this I can see interfaces in



    nicinfo and also in gui-network-interface.



    But soon after running this command I'm getting following error and /sbin/io-pkt-v4-hc process gets halted



    "ldd:FATAL: Unresolved symbol "stk_context_callback_2" called from devnp-e1000.so"



    AM I missing to load another library which is required ?







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118919

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118919: Re: Intel I210 and I217 Gigabit ethernet support in devnp-e1000.so (qnx 6.5)?

2018-07-09T12:44:19Z

Hello,

I'm trying devnp-e1000.so.

I copied that particular file into home folder and ran

/sbin/io-pkt-v4-hc

mount -T io-pkt /home/devnp-e1000.so

after running this I can see interfaces in

nicinfo and also in gui-network-interface.

But soon after running this command I'm getting following error and /sbin/io-pkt-v4-hc process gets halted

"ldd:FATAL: Unresolved symbol "stk_context_callback_2" called from devnp-e1000.so"

AM I missing to load another library which is required ?

post118766: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-12T17:03:54Z

Good news that you have it working! The QNX7 PCI server is a completely new driver and bears no resemblance to the QNX6 PCI server. The PCI source code that you have should be the latest, as there haven't been any changes to the code for a long time.

Hugh.

On 2018-04-12, 12:36 PM, "Brian Carnes(deleted)" <community-noreply@qnx.com> wrote:

    > Why are you running QNX6.6 with qemu-system-x86_64? Surely you should be running qemu-system-i386?



    No.  We run everything (Linux, qnx 6.6, qnx 7.0) under qemu-system-x86_64.



    It works for the same reason that you can boot qnx6.6 (or any 32-bit only OS) on 64-bit 86 hardware.



    Since we have been deploying qnx 6.6 to 64-bit hardware since the beginning, it’d actually be inappropriate to test it under qemu-system-i386…



    > Even if we're seeing two types of failures here (TBD)



    Two types of failures, with identical symptoms.



    Seen-on-hardware failure is related to a supermicro server (as opposed to advantech), and is presumably a BSP issue.



    qemu failure is described below.



    > If you can't triage or fix the issue directly, can you post the snippet of code that is failing inside of pci-bios-v2?



    You didn’t respond to this, but we found pci-bios-v2 source code publicly available at:



    http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/X86Bios



    The problem occurs in bios-v2.c , in function bios_avail_irq().  With no support for PIIX3, get_LPC_vendorId() returns 0xffff, the originally assigned IRQ gets blown away on line 442,  and everything errors out at the switch’s default block.



    We added rudimentary support for PIIX3 and preserving the IRQ assignment, and now see networking running fine under qemu for qnx6.6, whether in bios or apic mode.



    I don’t believe your users have access to QNX7’s pci-server source code (do we?) - I’d be interested in your assessment of why things work under QNX7…. Was there a fix in QNX7 that could get back ported into QNX6/pci-bios-v2?



    Regards,



      Brian









    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118765

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118765: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-12T16:55:16Z

> Why are you running QNX6.6 with qemu-system-x86_64? Surely you should be running qemu-system-i386?

No.  We run everything (Linux, qnx 6.6, qnx 7.0) under qemu-system-x86_64.

It works for the same reason that you can boot qnx6.6 (or any 32-bit only OS) on 64-bit 86 hardware.

Since we have been deploying qnx 6.6 to 64-bit hardware since the beginning, it’d actually be inappropriate to test it under qemu-system-i386…

> Even if we're seeing two types of failures here (TBD)

Two types of failures, with identical symptoms.

Seen-on-hardware failure is related to a supermicro server (as opposed to advantech), and is presumably a BSP issue.

qemu failure is described below.

> If you can't triage or fix the issue directly, can you post the snippet of code that is failing inside of pci-bios-v2?

You didn’t respond to this, but we found pci-bios-v2 source code publicly available at:

http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/X86Bios

The problem occurs in bios-v2.c , in function bios_avail_irq().  With no support for PIIX3, get_LPC_vendorId() returns 0xffff, the originally assigned IRQ gets blown away on line 442,  and everything errors out at the switch’s default block.

We added rudimentary support for PIIX3 and preserving the IRQ assignment, and now see networking running fine under qemu for qnx6.6, whether in bios or apic mode.

I don’t believe your users have access to QNX7’s pci-server source code (do we?) - I’d be interested in your assessment of why things work under QNX7…. Was there a fix in QNX7 that could get back ported into QNX6/pci-bios-v2?

Regards,

  Brian

post118764: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-12T15:34:14Z

Why are you running QNX6.6 with qemu-system-x86_64? Surely you should be running qemu-system-i386?

On 2018-04-11, 10:29 AM, "Brian Carnes(deleted)" <community-noreply@qnx.com> wrote:

    sloginfo w/ "pci-bios* -vvv" output attached as files to this post.



    The significant part seems to be:



    Apr 10 22:05:25    6    17     0 get_an_irq Requested MSI[X] vectors 0

    Apr 10 22:05:25    2    17     0 get_an_irq: No irq2

    Apr 10 22:05:25    2    10     0 pci_attach_device failed



    We see an identical failure when running w/ "pci-bios[-v2] -M -vvv", to disable MSI and MSI-X completely, so the problem appears to be in the fallback, non-MSI interrupt handling logic.



    From earlier, note that /sbin/pci output shows it is sitting on IRQ11.  It's been a long time since I've had to think about such things, but this sounds like something in the IRQ2 -> IRQ8-IRQ15 slave PIC logic.



    You should be able to reproduce this all under qemu-system-x86_64 over there.  Things work under QNX6.6/startup-bios, QNX7, and Linux.  They do not work under QNX6.6/startup-apic.



    Thanks.









    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118759

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118761: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-11T17:29:03Z

The original bug report was from real hardware. In brief, it was "USB works reliably under only one of startup-bios/startup-apic under qnx 6.6, networking only works under the other..."

These rapid iterations running your experimental drivers, etc. are happening on our regression testing testbed, which is using qemu for "VM-in-the-loop continuous integration/testing", pending enough HW being present for true "HW-in-the-loop CI/testing..."

Since we have a nice clean failure example in qemu, I hadn't pushed your requests back to the team w/ hardware.

Based on your question, I've now pinged the original team that reported this on hardware.

Even if we're seeing two types of failures here (TBD), it'd be nice to fix the original issue and the running-under-qemu issue.

If you can't triage or fix the issue directly, can you post the snippet of code that is failing inside of pci-bios-v2? We have folks with qemu-innards-expertise over here.

I'll let you know when I hear back from the on-hardware original bug folks.

Thanks

post118760: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-11T16:00:06Z

Just to be clear, this problem only occurs running under qemu?

Thanks, Hugh.

On 2018-04-11, 10:29 AM, "Brian Carnes(deleted)" <community-noreply@qnx.com> wrote:

    sloginfo w/ "pci-bios* -vvv" output attached as files to this post.



    The significant part seems to be:



    Apr 10 22:05:25    6    17     0 get_an_irq Requested MSI[X] vectors 0

    Apr 10 22:05:25    2    17     0 get_an_irq: No irq2

    Apr 10 22:05:25    2    10     0 pci_attach_device failed



    We see an identical failure when running w/ "pci-bios[-v2] -M -vvv", to disable MSI and MSI-X completely, so the problem appears to be in the fallback, non-MSI interrupt handling logic.



    From earlier, note that /sbin/pci output shows it is sitting on IRQ11.  It's been a long time since I've had to think about such things, but this sounds like something in the IRQ2 -> IRQ8-IRQ15 slave PIC logic.



    You should be able to reproduce this all under qemu-system-x86_64 over there.  Things work under QNX6.6/startup-bios, QNX7, and Linux.  They do not work under QNX6.6/startup-apic.



    Thanks.









    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118759

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118759: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-11T14:49:07Z

sloginfo w/ "pci-bios* -vvv" output attached as files to this post.

The significant part seems to be:

Apr 10 22:05:25    6    17     0 get_an_irq Requested MSI[X] vectors 0

Apr 10 22:05:25    2    17     0 get_an_irq: No irq2

Apr 10 22:05:25    2    10     0 pci_attach_device failed

We see an identical failure when running w/ "pci-bios[-v2] -M -vvv", to disable MSI and MSI-X completely, so the problem appears to be in the fallback, non-MSI interrupt handling logic.

From earlier, note that /sbin/pci output shows it is sitting on IRQ11.  It's been a long time since I've had to think about such things, but this sounds like something in the IRQ2 -> IRQ8-IRQ15 slave PIC logic.

You should be able to reproduce this all under qemu-system-x86_64 over there.  Things work under QNX6.6/startup-bios, QNX7, and Linux.  They do not work under QNX6.6/startup-apic.

Thanks.

post118758: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-10T13:46:52Z

Please can you rebuild your boot image and make sure that you have "slogger -s512k" and also "pci-bios -vvv". I need to get the full output from both the driver and the PCI server, as it appears that the pci_attach_device() is failing on MSI interrupts for some reason. Please post the complete sloginfo output.

Thanks, Hugh.

On 2018-04-09, 3:46 PM, "Brian Carnes(deleted)" <community-noreply@qnx.com> wrote:

    Your latest driver with extra logging, under pci-bios-v2:



    Time             Sev Major Minor Args

    Apr 09 19:35:32    5    14     0 tcpip starting

    Apr 09 19:35:32    3    14     0 Using pseudo random generator.  See "random" option

    Apr 09 19:35:32    5    14     0 initializing IPsec... done

    Apr 09 19:35:32    5    14     0 IPsec: Initialized Security Association Processing.

    Apr 09 19:35:32    5    14     0 wm0

    Apr 09 19:35:32    6    10     0 i82544_pci_attach1

    Apr 09 19:35:32    6    10     0 i82544_pci_attach2 - media_rate -1 - duplex -1

    Apr 09 19:35:32    6    10     0 i82544_pci_attach3 - busdevice 0x100e

    Apr 09 19:35:32    6    10     0 i82544_pci_attach4

    Apr 09 19:35:32    6    10     0 i82544_pci_attach5

    Apr 09 19:35:32    6    10     0 i82544_pci_attach6

    Apr 09 19:35:32    2    10     0 pci_attach_device failed

    Apr 09 19:35:32    2    14     0 Unable to init /tmp/devnp-e1000.so: No such device





    And running this same driver under pci-bios (v1) still gives an Abort that is not present in the original 6.6.0 devnp-e1000.so, but shows that it makes it past pci_attach_device():



    Time             Sev Major Minor Args

    Apr 09 19:35:42    6    17     0 intrinfo size = 320  entry size = 64  count = 5Apr 09 19:35:42    6    17     0 base = 0x80010000  num = 6  cascade = 07fffffff  intr 48

    Apr 09 19:35:42    6    17     0 base = 0x8001ffff  num = 1  cascade = 07fffffff  intr 47

    Apr 09 19:35:42    6    17     0 base = 0x80000000  num = 3  cascade = 07fffffff  intr 2

    Apr 09 19:35:42    6    17     0 base = 0x00000000  num = 24  cascade = 07fffffff  intr 54

    Apr 09 19:35:42    6    17     0 base = 0x00000100  num = 177  cascade = 07fffffff  intr 78

    Apr 09 19:35:42    6    17     0 scan_device exiting

    Apr 09 19:35:42    6    17     0 scan_device exiting

    Apr 09 19:35:42    6    17     0 scan_device exiting

    Apr 09 19:35:42    2    17     0 scan_windows: Alloc failed fd000008 - Size 1000000

    Apr 09 19:35:42    5    14     0 tcpip starting

    Apr 09 19:35:42    3    14     0 Using pseudo random generator.  See "random" option

    Apr 09 19:35:42    5    14     0 initializing IPsec... done

    Apr 09 19:35:42    5    14     0 IPsec: Initialized Security Association Processing.

    Apr 09 19:35:42    5    14     0 wm0

    Apr 09 19:35:42    6    10     0 i82544_pci_attach1

    Apr 09 19:35:42    6    10     0 i82544_pci_attach2 - media_rate -1 - duplex -1

    Apr 09 19:35:42    6    10     0 i82544_pci_attach3 - busdevice 0x100e

    Apr 09 19:35:42    6    10     0 i82544_pci_attach4

    Apr 09 19:35:42    6    10     0 i82544_pci_attach5

    Apr 09 19:35:42    6    10     0 i82544_pci_attach6

    Apr 09 19:35:42    6    10     0 i82544_pci_attach7

    Apr 09 19:35:42    6    10     0 i82544_pci_attach8

    Apr 09 19:35:42    6    10     0 e1000_set_mac_type

    Apr 09 19:35:42    6    10     0 e1000_init_mac_ops_generic

    ...

    Apr 09 19:35:42    1    14     0 nic_delay() called from proc0!











    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118755

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118757: Re: Intel e1000 Gbit driver for QNX6.3.x

2018-04-10T11:55:59Z

No, we don't have a tigon3 driver update for 6.3.

Hugh.

On 2018-04-10, 3:23 AM, "mario sangalli" <community-noreply@qnx.com> wrote:

    Thanks, Hugh! It works for me.



    just another help: the second NIC card is a 1Gb broadcom BCM5785 chip, DID=0x1699,

    I've tested the tigon3 driver under 6.5 version and works fine, whilst the 6.3.2 tigon3

    driver do not recognize the chip and when started stop to works after few ping,



    Have You a tigon3 update driver for 6.3 ?

    Any help is appreciated,

    Thanks again

    Mario









    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118756

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118756: Re: Intel e1000 Gbit driver for QNX6.3.x

2018-04-10T07:42:27Z

Thanks, Hugh! It works for me.

just another help: the second NIC card is a 1Gb broadcom BCM5785 chip, DID=0x1699,

I've tested the tigon3 driver under 6.5 version and works fine, whilst the 6.3.2 tigon3

driver do not recognize the chip and when started stop to works after few ping,

Have You a tigon3 update driver for 6.3 ?

Any help is appreciated,

Thanks again

Mario

post118755: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-09T20:05:20Z

Your latest driver with extra logging, under pci-bios-v2:

Time             Sev Major Minor Args

Apr 09 19:35:32    5    14     0 tcpip starting

Apr 09 19:35:32    3    14     0 Using pseudo random generator.  See "random" option

Apr 09 19:35:32    5    14     0 initializing IPsec... done

Apr 09 19:35:32    5    14     0 IPsec: Initialized Security Association Processing.

Apr 09 19:35:32    5    14     0 wm0

Apr 09 19:35:32    6    10     0 i82544_pci_attach1

Apr 09 19:35:32    6    10     0 i82544_pci_attach2 - media_rate -1 - duplex -1

Apr 09 19:35:32    6    10     0 i82544_pci_attach3 - busdevice 0x100e

Apr 09 19:35:32    6    10     0 i82544_pci_attach4

Apr 09 19:35:32    6    10     0 i82544_pci_attach5

Apr 09 19:35:32    6    10     0 i82544_pci_attach6

Apr 09 19:35:32    2    10     0 pci_attach_device failed

Apr 09 19:35:32    2    14     0 Unable to init /tmp/devnp-e1000.so: No such device

And running this same driver under pci-bios (v1) still gives an Abort that is not present in the original 6.6.0 devnp-e1000.so, but shows that it makes it past pci_attach_device():

Time             Sev Major Minor Args

Apr 09 19:35:42    6    17     0 intrinfo size = 320  entry size = 64  count = 5Apr 09 19:35:42    6    17     0 base = 0x80010000  num = 6  cascade = 07fffffff  intr 48

Apr 09 19:35:42    6    17     0 base = 0x8001ffff  num = 1  cascade = 07fffffff  intr 47

Apr 09 19:35:42    6    17     0 base = 0x80000000  num = 3  cascade = 07fffffff  intr 2

Apr 09 19:35:42    6    17     0 base = 0x00000000  num = 24  cascade = 07fffffff  intr 54

Apr 09 19:35:42    6    17     0 base = 0x00000100  num = 177  cascade = 07fffffff  intr 78

Apr 09 19:35:42    6    17     0 scan_device exiting

Apr 09 19:35:42    6    17     0 scan_device exiting

Apr 09 19:35:42    6    17     0 scan_device exiting

Apr 09 19:35:42    2    17     0 scan_windows: Alloc failed fd000008 - Size 1000000

Apr 09 19:35:42    5    14     0 tcpip starting

Apr 09 19:35:42    3    14     0 Using pseudo random generator.  See "random" option

Apr 09 19:35:42    5    14     0 initializing IPsec... done

Apr 09 19:35:42    5    14     0 IPsec: Initialized Security Association Processing.

Apr 09 19:35:42    5    14     0 wm0

Apr 09 19:35:42    6    10     0 i82544_pci_attach1

Apr 09 19:35:42    6    10     0 i82544_pci_attach2 - media_rate -1 - duplex -1

Apr 09 19:35:42    6    10     0 i82544_pci_attach3 - busdevice 0x100e

Apr 09 19:35:42    6    10     0 i82544_pci_attach4

Apr 09 19:35:42    6    10     0 i82544_pci_attach5

Apr 09 19:35:42    6    10     0 i82544_pci_attach6

Apr 09 19:35:42    6    10     0 i82544_pci_attach7

Apr 09 19:35:42    6    10     0 i82544_pci_attach8

Apr 09 19:35:42    6    10     0 e1000_set_mac_type

Apr 09 19:35:42    6    10     0 e1000_init_mac_ops_generic

...

Apr 09 19:35:42    1    14     0 nic_delay() called from proc0!

post118754: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-09T19:03:49Z

I have inserted some debug code into the driver to try and determine what is happening, so please run the attached driver as before and post the sloginfo output.

Thanks, Hugh.

On 2018-04-09, 2:30 PM, "Brian Carnes(deleted)" <community-noreply@qnx.com> wrote:

    Thank you, Hugh.



    With your new driver, I get the same results:



    # io-pkt-v4-hc -d /tmp/devnp-e1000.so verbose=4 -p tcpip stacksize=8192



    yields



    Unable to init /tmp/devnp-e1000.so: No such device



    And slogger output of:



    Time             Sev Major Minor Args

    Apr 09 17:52:52    6    17     0 intrinfo size = 320  entry size = 64  count = 5

    Apr 09 17:52:52    6    17     0 base = 0x80010000  num = 6  cascade = 0x7fffffff  intr 48

    Apr 09 17:52:52    6    17     0 base = 0x8001ffff  num = 1  cascade = 0x7fffffff  intr 47

    Apr 09 17:52:52    6    17     0 base = 0x80000000  num = 3  cascade = 0x7fffffff  intr 2

    Apr 09 17:52:52    6    17     0 base = 0x00000000  num = 24  cascade = 0x7fffffff  intr 54

    Apr 09 17:52:52    6    17     0 base = 0x00000100  num = 177  cascade = 0x7fffffff  intr 78

    Apr 09 17:52:52    6    17     0 find_host_bridge - bridge_count 0 - num_pci_bridges 0

    Apr 09 17:52:52    2    17     0 scan_windows: Alloc failed 0xfd000008 - Size 0x1000000

    Apr 09 17:52:52    5    14     0 tcpip starting

    Apr 09 17:52:52    3    14     0 Using pseudo random generator.  See "random" option

    Apr 09 17:52:52    5    14     0 initializing IPsec... done

    Apr 09 17:52:52    5    14     0 IPsec: Initialized Security Association Processing.

    Apr 09 17:52:52    5    14     0 wm0

    Apr 09 17:52:52    2    10     0 pci_attach_device failed

    Apr 09 17:52:52    2    14     0 Unable to init devnp-e1000.so: No such device



    running the same experiment under pci-bios (v1), with the original devnp-e1000.so, where things work, produces logging info of:



    Time             Sev Major Minor Args

    Apr 09 17:52:48    6    17     0 intrinfo size = 320  entry size = 64  count = 5

    Apr 09 17:52:48    6    17     0 base = 0x80010000  num = 6  cascade = 07fffffff  intr 48

    Apr 09 17:52:48    6    17     0 base = 0x8001ffff  num = 1  cascade = 07fffffff  intr 47

    Apr 09 17:52:48    6    17     0 base = 0x80000000  num = 3  cascade = 07fffffff  intr 2

    Apr 09 17:52:48    6    17     0 base = 0x00000000  num = 24  cascade = 07fffffff  intr 54

    Apr 09 17:52:48    6    17     0 base = 0x00000100  num = 177  cascade = 07fffffff  intr 78

    Apr 09 17:52:48    6    17     0 scan_device exiting

    Apr 09 17:52:48    6    17     0 scan_device exiting

    Apr 09 17:52:48    6    17     0 scan_device exiting

    Apr 09 17:52:48    2    17     0 scan_windows: Alloc failed fd000008 - Size 1000000

    Apr 09 17:52:49    5    14     0 tcpip starting

    Apr 09 17:52:49    3    14     0 Using pseudo random generator.  See "random" option

    Apr 09 17:52:49    5    14     0 initializing IPsec... done

    Apr 09 17:52:49    5    14     0 IPsec: Initialized Security Association Processing.

    Apr 09 17:52:49    5    14     0 wm0

    Apr 09 17:52:49    6    10     0 e1000_set_mac_type

    Apr 09 17:52:49    6    10     0 e1000_init_mac_ops_generic

    ...





    Interestingly, doing a quick run of your experimental driver from within pci-bios (v1) mode, it no longer works as the shipping devnp-e1000.so does, but instead yields an abort:



    # io-pkt-v4-hc -d /tmp/devnp-e1000.so verbose=4 -p tcpip stacksize=8192 -v

    Abort



    # sloginfo

    Time             Sev Major Minor Args

    Apr 09 17:53:09    6    17     0 intrinfo size = 320  entry size = 64  count = 5

    Apr 09 17:53:09    6    17     0 base = 0x80010000  num = 6  cascade = 07fffffff  intr 48

    Apr 09 17:53:09    6    17     0 base = 0x8001ffff  num = 1  cascade = 07fffffff  intr 47

    Apr 09 17:53:09    6    17     0 base = 0x80000000  num = 3  cascade = 07fffffff  intr 2

    Apr 09 17:53:09    6    17     0 base = 0x00000000  num = 24  cascade = 07fffffff  intr 54

    Apr 09 17:53:09    6    17     0 base = 0x00000100  num = 177  cascade = 07fffffff  intr 78

    Apr 09 17:53:09    6    17     0 scan_device exiting

    Apr 09 17:53:09    6    17     0 scan_device exiting

    Apr 09 17:53:09    6    17     0 scan_device exiting

    Apr 09 17:53:09    2    17     0 scan_windows: Alloc failed fd000008 - Size 1000000

    Apr 09 17:53:09    5    14     0 tcpip starting

    Apr 09 17:53:09    3    14     0 Using pseudo random generator.  See "random" option

    Apr 09 17:53:09    5    14     0 initializing IPsec... done

    Apr 09 17:53:09    5    14     0 IPsec: Initialized Security Association Processing.

    Apr 09 17:53:09    5    14     0 wm0

    Apr 09 17:53:09    6    10     0 e1000_set_mac_type

    Apr 09 17:53:09    6    10     0 e1000_init_mac_ops_generic

    Apr 09 17:53:09    6    10     0 e1000_init_phy_ops_generic

    Apr 09 17:53:09    6    10     0 e1000_init_nvm_ops_generic

    Apr 09 17:53:09    6    10     0 e1000_init_function_pointers_82540

    Apr 09 17:53:09    6    10     0 e1000_init_mac_params_82540

    Apr 09 17:53:09    6    10     0 e1000_init_nvm_params_82540

    Apr 09 17:53:09    6    10     0 e1000_get_phy_id

    Apr 09 17:53:09    6    10     0 e1000_read_phy_reg_m88

    Apr 09 17:53:09    6    10     0 e1000_null_ops_generic

    Apr 09 17:53:09    6    10     0 e1000_read_phy_reg_mdic

    Apr 09 17:53:09    6    10     0 e1000_null_phy_generic

    Apr 09 17:53:09    6    10     0 e1000_read_phy_reg_m88

    Apr 09 17:53:09    6    10     0 e1000_null_ops_generic

    Apr 09 17:53:09    6    10     0 e1000_read_phy_reg_mdic

    Apr 09 17:53:09    6    10     0 e1000_null_phy_generic

    Apr 09 17:53:09    6    10     0 e1000_null_ops_generic

    Apr 09 17:53:09    6    10     0 i82544_pci_attach: rar entries 15

    Apr 09 17:53:09    6    10     0 e1000_get_bus_info_pci_generic

    Apr 09 17:53:09    6    10     0 e1000_null_ops_generic

    Apr 09 17:53:09    6    10     0 e1000_reset_hw_82540

    Apr 09 17:53:09    6    10     0 Masking off all interrupts



    Apr 09 17:53:09    1    14     0 nic_delay() called from proc0!

    #







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118753

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118753: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-09T18:49:51Z

Thank you, Hugh.

With your new driver, I get the same results:

# io-pkt-v4-hc -d /tmp/devnp-e1000.so verbose=4 -p tcpip stacksize=8192

yields

Unable to init /tmp/devnp-e1000.so: No such device

And slogger output of:

Time             Sev Major Minor Args

Apr 09 17:52:52    6    17     0 intrinfo size = 320  entry size = 64  count = 5

Apr 09 17:52:52    6    17     0 base = 0x80010000  num = 6  cascade = 0x7fffffff  intr 48

Apr 09 17:52:52    6    17     0 base = 0x8001ffff  num = 1  cascade = 0x7fffffff  intr 47

Apr 09 17:52:52    6    17     0 base = 0x80000000  num = 3  cascade = 0x7fffffff  intr 2

Apr 09 17:52:52    6    17     0 base = 0x00000000  num = 24  cascade = 0x7fffffff  intr 54

Apr 09 17:52:52    6    17     0 base = 0x00000100  num = 177  cascade = 0x7fffffff  intr 78

Apr 09 17:52:52    6    17     0 find_host_bridge - bridge_count 0 - num_pci_bridges 0

Apr 09 17:52:52    2    17     0 scan_windows: Alloc failed 0xfd000008 - Size 0x1000000

Apr 09 17:52:52    5    14     0 tcpip starting

Apr 09 17:52:52    3    14     0 Using pseudo random generator.  See "random" option

Apr 09 17:52:52    5    14     0 initializing IPsec... done

Apr 09 17:52:52    5    14     0 IPsec: Initialized Security Association Processing.

Apr 09 17:52:52    5    14     0 wm0

Apr 09 17:52:52    2    10     0 pci_attach_device failed

Apr 09 17:52:52    2    14     0 Unable to init devnp-e1000.so: No such device

running the same experiment under pci-bios (v1), with the original devnp-e1000.so, where things work, produces logging info of:

Time             Sev Major Minor Args

Apr 09 17:52:48    6    17     0 intrinfo size = 320  entry size = 64  count = 5

Apr 09 17:52:48    6    17     0 base = 0x80010000  num = 6  cascade = 07fffffff  intr 48

Apr 09 17:52:48    6    17     0 base = 0x8001ffff  num = 1  cascade = 07fffffff  intr 47

Apr 09 17:52:48    6    17     0 base = 0x80000000  num = 3  cascade = 07fffffff  intr 2

Apr 09 17:52:48    6    17     0 base = 0x00000000  num = 24  cascade = 07fffffff  intr 54

Apr 09 17:52:48    6    17     0 base = 0x00000100  num = 177  cascade = 07fffffff  intr 78

Apr 09 17:52:48    6    17     0 scan_device exiting

Apr 09 17:52:48    6    17     0 scan_device exiting

Apr 09 17:52:48    6    17     0 scan_device exiting

Apr 09 17:52:48    2    17     0 scan_windows: Alloc failed fd000008 - Size 1000000

Apr 09 17:52:49    5    14     0 tcpip starting

Apr 09 17:52:49    3    14     0 Using pseudo random generator.  See "random" option

Apr 09 17:52:49    5    14     0 initializing IPsec... done

Apr 09 17:52:49    5    14     0 IPsec: Initialized Security Association Processing.

Apr 09 17:52:49    5    14     0 wm0

Apr 09 17:52:49    6    10     0 e1000_set_mac_type

Apr 09 17:52:49    6    10     0 e1000_init_mac_ops_generic

...

Interestingly, doing a quick run of your experimental driver from within pci-bios (v1) mode, it no longer works as the shipping devnp-e1000.so does, but instead yields an abort:

# io-pkt-v4-hc -d /tmp/devnp-e1000.so verbose=4 -p tcpip stacksize=8192 -v

Abort

# sloginfo

Time             Sev Major Minor Args

Apr 09 17:53:09    6    17     0 intrinfo size = 320  entry size = 64  count = 5

Apr 09 17:53:09    6    17     0 base = 0x80010000  num = 6  cascade = 07fffffff  intr 48

Apr 09 17:53:09    6    17     0 base = 0x8001ffff  num = 1  cascade = 07fffffff  intr 47

Apr 09 17:53:09    6    17     0 base = 0x80000000  num = 3  cascade = 07fffffff  intr 2

Apr 09 17:53:09    6    17     0 base = 0x00000000  num = 24  cascade = 07fffffff  intr 54

Apr 09 17:53:09    6    17     0 base = 0x00000100  num = 177  cascade = 07fffffff  intr 78

Apr 09 17:53:09    6    17     0 scan_device exiting

Apr 09 17:53:09    6    17     0 scan_device exiting

Apr 09 17:53:09    6    17     0 scan_device exiting

Apr 09 17:53:09    2    17     0 scan_windows: Alloc failed fd000008 - Size 1000000

Apr 09 17:53:09    5    14     0 tcpip starting

Apr 09 17:53:09    3    14     0 Using pseudo random generator.  See "random" option

Apr 09 17:53:09    5    14     0 initializing IPsec... done

Apr 09 17:53:09    5    14     0 IPsec: Initialized Security Association Processing.

Apr 09 17:53:09    5    14     0 wm0

Apr 09 17:53:09    6    10     0 e1000_set_mac_type

Apr 09 17:53:09    6    10     0 e1000_init_mac_ops_generic

Apr 09 17:53:09    6    10     0 e1000_init_phy_ops_generic

Apr 09 17:53:09    6    10     0 e1000_init_nvm_ops_generic

Apr 09 17:53:09    6    10     0 e1000_init_function_pointers_82540

Apr 09 17:53:09    6    10     0 e1000_init_mac_params_82540

Apr 09 17:53:09    6    10     0 e1000_init_nvm_params_82540

Apr 09 17:53:09    6    10     0 e1000_get_phy_id

Apr 09 17:53:09    6    10     0 e1000_read_phy_reg_m88

Apr 09 17:53:09    6    10     0 e1000_null_ops_generic

Apr 09 17:53:09    6    10     0 e1000_read_phy_reg_mdic

Apr 09 17:53:09    6    10     0 e1000_null_phy_generic

Apr 09 17:53:09    6    10     0 e1000_read_phy_reg_m88

Apr 09 17:53:09    6    10     0 e1000_null_ops_generic

Apr 09 17:53:09    6    10     0 e1000_read_phy_reg_mdic

Apr 09 17:53:09    6    10     0 e1000_null_phy_generic

Apr 09 17:53:09    6    10     0 e1000_null_ops_generic

Apr 09 17:53:09    6    10     0 i82544_pci_attach: rar entries 15

Apr 09 17:53:09    6    10     0 e1000_get_bus_info_pci_generic

Apr 09 17:53:09    6    10     0 e1000_null_ops_generic

Apr 09 17:53:09    6    10     0 e1000_reset_hw_82540

Apr 09 17:53:09    6    10     0 Masking off all interrupts

Apr 09 17:53:09    1    14     0 nic_delay() called from proc0!

#

post118752: Re: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-09T17:53:05Z

I have attached the latest 6.6.0 devnp-e1000.so driver to this email for you to try. If it still doesn't work under apic mode, will you please do the following and post the sloginfo output:

Make sure that slogger is started with "slogger -s512k"

slay io-pkt-v4-hc

io-pkt-v4-hc -de1000 verbose=4 -p tcpip stacksize=8192

sloginfo > file

post the output "file"

Thanks, Hugh.

On 2018-04-09, 1:22 PM, "Brian Carnes(deleted)" <community-noreply@qnx.com> wrote:

    We've been able to isolate this to a minimal test case that reproduces under qemu.



    io-pkt-v4-hc and/or e1000.so is able to find the networking hardware while under startup-bios (w/ pci-bios), but not under startup-apic (w/ pci-bios-v2 named as pci-bios in the build file as instructed[1])



    is there an update to e1000/io-pkt-v4-hc we should obtain to work under apic mode?  Are there any workarounds to enable using this network adapter w/ apic?



    QNX 6.6, startup-apic mode:



    # io-pkt-v4-hc -d e1000 -v

    Unable to init devnp-e1000.so: No such device



    QNX 6.6, startup-bios mode:



    # io-pkt-v4-hc -d e1000 -v

    # ifconfig -a

    ... heathy output...



    QNX7 (x86_64) works for us as well.  It is only qnx 6.6, under startup-apic that it misbehaves.



    In both working and "no such device" cases under QNX6.6, /usr/sbin/pci reports:



    # pci

    PCI version    = 2.10

    ...

    Class          = Network (Ethernet)

    Vendor ID      = 8086h, Intel Corporation

    Device ID      = 100eh,  82540EM Gigabit Ethernet Controller

    PCI index      = 0h

    BAR - 0 [Mem]  = febc0000h enabled

    BAR - 1 [I/O]  = c000h enabled

    PCI Expansion ROM = feb80000h disabled

    PCI Int Pin    = INT A

    Interrupt line = 11

    CPU Interrupt  = bh



    While we have customized startup-* binaries elsewhere, for the above tests we reverted to using vanilla QNX shipped startup-{bios,apic} to rule out our unrelated changes.



    As a third, rule-violating experiment, to give you another datapoint:  We tried running our system with the forbidden combination of startup-apic, and pci-bios-v1.  Under this frankenstein combo, the network driver does load correctly.  So to the extent that one can separate apic mode from pci-bios-v2 mode, the problem seems to lie within pci-bios-v2.



    Additional version info:



    # uname -a

    QNX localhost 6.6.0 2014/02/22-18:29:34EST x86pc x86



    ## under startup-bios, w/ pci-bios (v1)

    # strings /proc/boot/pci-bios | tail

    DESCRIPTION=BIOS PCI server

    DATE=2014/02/21-13:06:13-EST

    STATE=stable

    HOST=sdp-builder-08

    USER=builder

    VERSION=6.6.0

    TAGID=276



    ## under startup-apic, w/ pci-bios-v2

    # strings /proc/boot/pci-bios | tail

    DESCRIPTION=BIOS PCI server

    DATE=2014/02/21-15:40:42-EST

    STATE=stable

    HOST=sdp-builder-08

    USER=builder

    VERSION=6.6.0

    TAGID=277



    [1] http://www.qnx.com/developers/docs/6.6.0_anm11_wf10/#com.qnx.doc.neutrino.utilities/topic/p/pci-bios.html







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118751

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118751: [QNX 6.6] intel e1000 network driver works under startup-bios, not under startup-apic

2018-04-09T17:41:34Z

We've been able to isolate this to a minimal test case that reproduces under qemu.

io-pkt-v4-hc and/or e1000.so is able to find the networking hardware while under startup-bios (w/ pci-bios), but not under startup-apic (w/ pci-bios-v2 named as pci-bios in the build file as instructed[1])

is there an update to e1000/io-pkt-v4-hc we should obtain to work under apic mode?  Are there any workarounds to enable using this network adapter w/ apic?

QNX 6.6, startup-apic mode:

# io-pkt-v4-hc -d e1000 -v

Unable to init devnp-e1000.so: No such device

QNX 6.6, startup-bios mode:

# io-pkt-v4-hc -d e1000 -v

# ifconfig -a

... heathy output...

QNX7 (x86_64) works for us as well.  It is only qnx 6.6, under startup-apic that it misbehaves.

In both working and "no such device" cases under QNX6.6, /usr/sbin/pci reports:

# pci

PCI version    = 2.10

...

Class          = Network (Ethernet)

Vendor ID      = 8086h, Intel Corporation

Device ID      = 100eh,  82540EM Gigabit Ethernet Controller

PCI index      = 0h

BAR - 0 [Mem]  = febc0000h enabled

BAR - 1 [I/O]  = c000h enabled

PCI Expansion ROM = feb80000h disabled

PCI Int Pin    = INT A

Interrupt line = 11

CPU Interrupt  = bh

While we have customized startup-* binaries elsewhere, for the above tests we reverted to using vanilla QNX shipped startup-{bios,apic} to rule out our unrelated changes.

As a third, rule-violating experiment, to give you another datapoint:  We tried running our system with the forbidden combination of startup-apic, and pci-bios-v1.  Under this frankenstein combo, the network driver does load correctly.  So to the extent that one can separate apic mode from pci-bios-v2 mode, the problem seems to lie within pci-bios-v2.

Additional version info:

# uname -a

QNX localhost 6.6.0 2014/02/22-18:29:34EST x86pc x86

## under startup-bios, w/ pci-bios (v1)

# strings /proc/boot/pci-bios | tail

DESCRIPTION=BIOS PCI server

DATE=2014/02/21-13:06:13-EST

STATE=stable

HOST=sdp-builder-08

USER=builder

VERSION=6.6.0

TAGID=276

## under startup-apic, w/ pci-bios-v2

# strings /proc/boot/pci-bios | tail

DESCRIPTION=BIOS PCI server

DATE=2014/02/21-15:40:42-EST

STATE=stable

HOST=sdp-builder-08

USER=builder

VERSION=6.6.0

TAGID=277

[1] http://www.qnx.com/developers/docs/6.6.0_anm11_wf10/#com.qnx.doc.neutrino.utilities/topic/p/pci-bios.html

post118745: Re: Intel e1000 Gbit driver for QNX6.3.x

2018-04-05T16:06:32Z

Thank you very much, I will test as soon as possible!

post118744: Re: Intel e1000 Gbit driver for QNX6.3.x

2018-04-05T15:31:17Z

Please try the attached driver and let me know if it works. If not, I'll have to find a 6.3.0 machine and compile the latest driver for you.

Thanks, Hugh.

On 2018-04-05, 11:05 AM, "mario sangalli" <community-noreply@qnx.com> wrote:

    I'm sorry, it is  0x1539, the 0x1699 is for a second ethernet: a Broadcom BCM54610 chip,

    in 6.5 i've used the tigon3 driver: if it is available also for 6.3, it should be an alternative to

    intel chip,

    thanks, mario









    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118743

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118743: Re: Intel e1000 Gbit driver for QNX6.3.x

2018-04-05T15:25:06Z

I'm sorry, it is 0x1539, the 0x1699 is for a second ethernet: a Broadcom BCM54610 chip,

in 6.5 i've used the tigon3 driver: if it is available also for 6.3, it should be an alternative to

intel chip,

thanks, mario

post118742: Re: Intel e1000 Gbit driver for QNX6.3.x

2018-04-05T13:27:36Z

Are you sure that this is the correct device ID? I have just downloaded the latest Linux driver source from Intel and there is no device ID 0x1699. All i210 adapters are in the 0x15xx range.

On 2018-04-05, 8:59 AM, "mario sangalli" <community-noreply@qnx.com> wrote:

    Thanks for support:

    it's an Intel I210/I211 chip, with DID=x1699



    Mario











    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118741

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118741: Re: Intel e1000 Gbit driver for QNX6.3.x

2018-04-05T13:18:51Z

Thanks for support:

it's an Intel I210/I211 chip, with DID=x1699

Mario

post118740: Re: Intel e1000 Gbit driver for QNX6.3.x

2018-04-05T12:14:04Z

What is the device PCI-ID that you want to support? We have an old e1000 driver for 6.3.0, but it doesn't support the latest Intel device IDs.

On 2018-04-05, 6:27 AM, "mario sangalli" <community-noreply@qnx.com> wrote:

    Dear All,

    I've to update a 6.3 x86 application with a Intel Gbit chip...

    I'm search for a devn-e1000.so driver or similar if available,

    I will appreciate any support, best regards

    mario













    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118739

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118739: Intel e1000 Gbit driver for QNX6.3.x

2018-04-05T10:47:17Z

Dear All,

I've to update a 6.3 x86 application with a Intel Gbit chip...

I'm search for a devn-e1000.so driver or similar if available,

I will appreciate any support, best regards

mario

post118584: Re: Issues with devnp-rtl8169.so SP1

2018-02-15T16:28:21Z

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

post118571: Re: Issues with devnp-rtl8169.so SP1

2018-02-13T15:14:10Z

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

post118568: Re: Issues with devnp-rtl8169.so SP1

2018-02-13T14:18:15Z

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.

post118562: Re: Issues with devnp-rtl8169.so SP1

2018-02-12T13:33:13Z

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

post118558: Re: Issues with devnp-rtl8169.so SP1

2018-02-12T08:02:19Z

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.

post118549: Re: Issues with devnp-rtl8169.so SP1

2018-02-09T18:43:06Z

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

post118526: Re: Porting NetBSD Network Driver

2018-02-07T20:12:23Z

Thanks for the reply and clarification.

I think this significantly complicates my situation. I will need to rethink how I should approach my problem.

post118525: Re: Porting NetBSD Network Driver

2018-02-07T19:58:51Z

Yes, 6.6.0 and later. In 6.5.0 SP1 then it is under /usr/include/drvr

6.4.1 is so old that much of what I described is not present.

post118524: Re: Porting NetBSD Network Driver

2018-02-07T19:55:39Z

Thank you for the replies.

Is /usr/include/netdrvr/ something that was introduced in a later version of QNX? I'm looking at our version, which is stuck at 6.4.1, and I cannot find /usr/include/netdrvr.

post118523: Re: Porting NetBSD Network Driver

2018-02-07T19:05:21Z

DELAY is defined in usr/include/io-pkt/machine/param.h

#define DELAY(_x) (((_x) >= 1000) ? (delay)(((_x) / 1000) + 1) : nanospin_ns((_x) * 1000L))

There are several things to consider with delays of any sort in a driver:

1) QNX kernel timer tick resolution. By default the timer tick is 1ms so any form of delay/sleep call will have that resolution. nanospin_ns() can be used for shorter delays but suffers from calibration issues.

2) io-pkt is in general behaviour single threaded - there is a single "network stack context" that performs most operations. Performing a delay in one driver in the stack context will usually block traffic on other interfaces.

3) To overcome point 2 we have introduced nic_delay() in usr/include/netdrvr/nicsupport.h However note that in yielding stack context to permit traffic to flow on other interfaces, it also permits other operations to happen on your driver - including such things as removal e.g. on a USB interface. Care needs to be taken with locking.

4) Adding to the complexity, the stack context can migrate between posix threads so the locks need to be nic_mutex and not pthread_mutex - see usr/include/netdrvr/nic_mutex.h

5) io-pkt internal timers as used by nic_delay() tick at between 8ms and 50ms depending on traffic. If you have many calls to nic_delay() for a short delays then you can find this taking significant clock time. Moving the entire block of code across to a blockop solves this issue and makes the nic_delay() behave like a normal delay.

Think very carefully about delays in drivers, they have historically been the cause of many issues!

post118522: Re: Porting NetBSD Network Driver

2018-02-07T19:00:20Z

The definition for DELAY() can be found in usr/include/io-pkt/machine/param.h and it cannot be used in an interrupt service routine.

nanospin_ns() can be used in an interrupt service routine, but it isn't recommended. See the docs.

On 2018-02-07, 12:49 PM, "Danny Yen(deleted)" <community-noreply@qnx.com> wrote:

    In the documentation, under "Differences between ported NetBSD drivers and native drivers", it says that there are two different "delay" functions: delay() and DELAY(), where DELAY() is reentrant. However, Neutrino's version of delay() is very different (millisecond instead of microsecond). That's why QNX had defined a DELAY() to support microsecond. Furthermore, ported drivers should define delay() to DELAY().



    My question is two folds:

    1. Where can I actually find DELAY()? I see delay() in unistd.h but I can't seem to find DELAY() anywhere. Momentics does not seem to recognize it.

    2. Is Neutrino's implementation of DELAY() or delay() reentrant, i.e. safe to be used in an interrupt or process context?







    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118521

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118521: Porting NetBSD Network Driver

2018-02-07T18:10:03Z

In the documentation, under "Differences between ported NetBSD drivers and native drivers", it says that there are two different "delay" functions: delay() and DELAY(), where DELAY() is reentrant. However, Neutrino's version of delay() is very different (millisecond instead of microsecond). That's why QNX had defined a DELAY() to support microsecond. Furthermore, ported drivers should define delay() to DELAY().

My question is two folds:

1. Where can I actually find DELAY()? I see delay() in unistd.h but I can't seem to find DELAY() anywhere. Momentics does not seem to recognize it.

2. Is Neutrino's implementation of DELAY() or delay() reentrant, i.e. safe to be used in an interrupt or process context?

post118514: Re: Issues with devnp-rtl8169.so SP1

2018-02-01T20:12:53Z

Ok thanks. I'll dig up 6.6 and see if that works better.

post118513: Re: Issues with devnp-rtl8169.so SP1

2018-02-01T19:06:45Z

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

    http://community.qnx.com/sf/go/post118510

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118510: Re: Issues with devnp-rtl8169.so SP1

2018-02-01T17:12:05Z

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)

post118508: Re: Issues with devnp-rtl8169.so SP1

2018-02-01T16:49:28Z

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

>

>

post118507: Re: Issues with devnp-rtl8169.so SP1

2018-02-01T13:50:53Z

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

post118505: Issues with devnp-rtl8169.so SP1

2018-01-31T19:43:19Z

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 ;-)

post118435: Re: QNX 7 E1000 Driver Very Slow Sending Only

2018-01-23T13:28:50Z

Good news! Glad it is working for you.

Nicinfo only displays hardware errors, so you need to run netstat to see TCP/UDP problems.

Hugh.

On 2018-01-22, 6:02 PM, "Tim Sowden(deleted)" <community-noreply@qnx.com> wrote:

    > Seeing a lot of TCP retransmit timeouts & ICMP errors -- have you got a really

    >  congested link or flapping port between the 2 hosts (possible bad switchport

    > or cable)?

    >

    > Under TCP stats:

    > tim:   4616 retransmit timeouts

    > tim1:  4616 retransmit timeouts

    > tim2:  4702 retransmit timeouts

    >

    > Under ICMP stats:

    > tim:  261737 calls to icmp_error

    >             destination unreachable:  261737

    > tim1:  261748 calls to icmp_error

    >             destination unreachable:  261748

    > tim2:  261933 calls to icmp_error

    >             destination unreachable:  261933

    >

    >



    The computers are all located in a lab with no outside access (closed network) so there is very little traffic.



    I swapped Ethernet cables on the chance it might have been a bad cable I used but that made no difference. I was *this* close to writing back when I decided to switch ports on the Netgear router. I hadn't done that prior because I had plugged into a port that was being used by another computer in our lab so I *knew* it was good.



    Of course the instant I plugged into another port everything started working in both directions. So the port must have been degraded after all and just no one has noticed because they haven't transferred any large amount of data in the bad direction on the prior machine that was plugged in there!



    One final question though. I swore prior versions of QNX showed these types of hardware issues in Nicinfo which was the first place I went when I was having problems. The fact there were no errors reported there made me think it was a configuration issue vs a hardware one.



    Thanks for all your help,



    Tim









    _______________________________________________



    Networking Drivers

    http://community.qnx.com/sf/go/post118432

    To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

post118432: Re: RE: QNX 7 E1000 Driver Very Slow Sending Only

2018-01-22T23:23:17Z

> Seeing a lot of TCP retransmit timeouts & ICMP errors -- have you got a really

>  congested link or flapping port between the 2 hosts (possible bad switchport

> or cable)?

>

> Under TCP stats:

> tim:   4616 retransmit timeouts

> tim1:  4616 retransmit timeouts

> tim2:  4702 retransmit timeouts

>

> Under ICMP stats:

> tim:  261737 calls to icmp_error

>             destination unreachable:  261737

> tim1:  261748 calls to icmp_error

>             destination unreachable:  261748

> tim2:  261933 calls to icmp_error

>             destination unreachable:  261933

>

>

The computers are all located in a lab with no outside access (closed network) so there is very little traffic.

I swapped Ethernet cables on the chance it might have been a bad cable I used but that made no difference. I was *this* close to writing back when I decided to switch ports on the Netgear router. I hadn't done that prior because I had plugged into a port that was being used by another computer in our lab so I *knew* it was good.

Of course the instant I plugged into another port everything started working in both directions. So the port must have been degraded after all and just no one has noticed because they haven't transferred any large amount of data in the bad direction on the prior machine that was plugged in there!

One final question though. I swore prior versions of QNX showed these types of hardware issues in Nicinfo which was the first place I went when I was having problems. The fact there were no errors reported there made me think it was a configuration issue vs a hardware one.

Thanks for all your help,

Tim