http://community.qnx.com/sf/discussion/do/listTopics/projects.networking/discussion.drivers Posts for Networking Drivers http://community.qnx.com/sf/go/post101627 A bit more info... with: #io-pkt-v4 -d mx53 mac=00049fcc9ab5 mx51_attach(): IF 0: Base register 0x63FEC000 mx51_attach(): IF 0: IRQ 87 Which looks ok. sloginfo... Jan 01 00:00:09 5 14 0 IMX 51 FEC Jan 01 00:00:09 5 14 0 Vendor .............. 0x0 Jan 01 00:00:09 5 14 0 Device .............. 0x0 Jan 01 00:00:09 5 14 0 Revision ............ 0x0 Jan 01 00:00:09 5 14 0 Memory base ......... 0x63fec000 Jan 01 00:00:09 5 14 0 Interrupt ........... 0x57 Jan 01 00:00:09 5 14 0 MAC address ......... 00049f cc9ab5 Not sure about the 0x0 - guess they are not set. Then attempt # nicinfo fec0 fec0: IMX 51 FEC Ethernet Controller and it hangs! I guess this is something serious :-( Any thoughts? Thanks Simon Thu, 23 May 2013 09:57:55 GMT http://community.qnx.com/sf/go/post101627 Simon Conway 2013-05-23T09:57:55Z http://community.qnx.com/sf/go/post101599 Hi, I am having some difficulty setting up an ip stack on our platform which uses QNX running on an imx controller. I have read through all the documentation I can find on the QNX web pages regarding the ip stack as I was unfamiliar with it. What I now understand is that I need to load the QNX supplied driver for the imx FEC. I am using…. io-pkt-v4 -d mx53 mac=xxxxxxxxxxxx With ifconfig I get… fec0: flags=802<BROADCAST,SIMPLEX> mtu 1500 address: xx:xx:xx:xx:xx:xx media: Ethernet none When I connect a cable between my PC and our platform the LAN connection reports “connected”. This possibly indicates that the HW is working ok. The next step is to assign a static ip address to this interface. I try… ifconfig fec0 192.168.128.161 This hangs. It looks like the imx has stopped so I am assuming, maybe incorrectly, that the driver is the cause of this. I tried: if_up -p fec0 which has exit status of 0 which means the interface is present but not necessarily configured. if_up -a fec0 returns "if_up: retries exhausted" with exit status 7 No sure exactly what the 7 means but this implies that the interface is not configured. Any ideas what I am missing in configuring the interface? On the same platform the asix driver for usb dongle is working fine. What functions in the driver are called as a result of the ifconfig command? I couldn’t find this information on the QNX support pages. With this I could attempt to debug the problem. I am also wondering if my setup is missing something. Do I need to run anything else? Are there any tools that would help diagnose the problem? Unfortunately I am new to the finer details of networking and am learning as I go so any useful information would be appreciated. Thanks Simon Wed, 22 May 2013 14:27:43 GMT http://community.qnx.com/sf/go/post101599 Simon Conway 2013-05-22T14:27:43Z http://community.qnx.com/sf/go/post101559 Hugh, I have placed the requested options for slogger and pci-bios into the diskboot call. In the attachment are the log for two executions of PCI_tst Regards --Armin Hugh Brown wrote: > Armin, > > Please modify your build file to start the attached pci-bios with '-vvv', > then boot your machine and make sure that you have a large enough slog > buffer (256k). Then run your program and send me the FULL sloginfo output. > > After the procmgr_symlink line in the build file, add the following: > > seedres > slogger -s256k > pci-bios -vvv > waitfor /dev/pci > > Thanks, Hugh. > > > > > On 2013-05-16 1:29 PM, "Armin Steinhoff" <community-noreply@qnx.com> wrote: > >> Hugh, >> >> I have done a fresh installation on a new disk in order to exclude any >> side effects from a corrupted installation of QNX 6.4.1. >> >> After recompiling and linking ... I see the same wrong behavior !! >> >> Regards >> >> --Armin >> >> Hugh Brown wrote: >>> Armin, >>> >>> I have run your code on a 6.4.1 machine with the same version of the PCI >>> server and everything works fine. I just had to change the device IDs in >>> the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if >>> there is something strange on your system. Can you boot it with a >>> minimal >>> O/S and run your program again? >>> >>> Hugh. >>> >> >> >> >> >> _______________________________________________ >> >> Networking Drivers >> http://community.qnx.com/sf/go/post101498 >> To cancel your subscription to this discussion, please e-mail >> drivers-networking-unsubscribe@community.qnx.com > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post101513 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Mon, 20 May 2013 12:45:52 GMT http://community.qnx.com/sf/go/post101559 Armin Steinhoff 2013-05-20T12:45:52Z http://community.qnx.com/sf/go/post101513 Armin, Please modify your build file to start the attached pci-bios with '-vvv', then boot your machine and make sure that you have a large enough slog buffer (256k). Then run your program and send me the FULL sloginfo output. After the procmgr_symlink line in the build file, add the following: seedres slogger -s256k pci-bios -vvv waitfor /dev/pci Thanks, Hugh. On 2013-05-16 1:29 PM, "Armin Steinhoff" <community-noreply@qnx.com> wrote: >Hugh, > >I have done a fresh installation on a new disk in order to exclude any >side effects from a corrupted installation of QNX 6.4.1. > >After recompiling and linking ... I see the same wrong behavior !! > >Regards > >--Armin > >Hugh Brown wrote: >> Armin, >> >> I have run your code on a 6.4.1 machine with the same version of the PCI >> server and everything works fine. I just had to change the device IDs in >> the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if >> there is something strange on your system. Can you boot it with a >>minimal >> O/S and run your program again? >> >> Hugh. >> > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post101498 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Fri, 17 May 2013 12:07:43 GMT http://community.qnx.com/sf/go/post101513 Hugh Brown 2013-05-17T12:07:43Z http://community.qnx.com/sf/go/post101498 Hugh, I have done a fresh installation on a new disk in order to exclude any side effects from a corrupted installation of QNX 6.4.1. After recompiling and linking ... I see the same wrong behavior !! Regards --Armin Hugh Brown wrote: > Armin, > > I have run your code on a 6.4.1 machine with the same version of the PCI > server and everything works fine. I just had to change the device IDs in > the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if > there is something strange on your system. Can you boot it with a minimal > O/S and run your program again? > > Hugh. > Thu, 16 May 2013 17:29:52 GMT http://community.qnx.com/sf/go/post101498 Armin Steinhoff 2013-05-16T17:29:52Z http://community.qnx.com/sf/go/post101491 Hugh, I have tested after booting from a distribution CD of QNX6.4.1 and observed the same wrong behavior of "pci_attach_device"! It happens also at customer site with a fresh installation of QNX 6.4.1 . There is simply a bug. Please have a look to the kernel trace I have sent with a recent mail. Regards --Armin Hugh Brown wrote: > Armin, > > I have run your code on a 6.4.1 machine with the same version of the PCI > server and everything works fine. I just had to change the device IDs in > the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if > there is something strange on your system. Can you boot it with a minimal > O/S and run your program again? > > Hugh. > Thu, 16 May 2013 16:09:40 GMT http://community.qnx.com/sf/go/post101491 Armin Steinhoff 2013-05-16T16:09:40Z http://community.qnx.com/sf/go/post101481 Armin, I have run your code on a 6.4.1 machine with the same version of the PCI server and everything works fine. I just had to change the device IDs in the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if there is something strange on your system. Can you boot it with a minimal O/S and run your program again? Hugh. -- Hugh Brown QNX Software Systems Limited 1001 Farrar Rd., Ottawa. ON. K2K 0B3. Telephone: 613-591-0931 On 2013-05-16 8:26 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote: >Hugh, > >this is the version of pci-bios: > ># use -i pci-bios >NAME=pci-bios >DESCRIPTION=BIOS PCI server >DATE=2009/05/20-17:12:26-EDT >STATE=stable >HOST=cctrunk >USER=builder >VERSION=6.4.1 >TAGID=166 > >The "Add" messages are not from the application ... > >Best Regards > >--Armin > >Hugh Brown wrote: >> I have no idea where the "Add" messages are coming from, as they are not >> from the PCI server. Looking at the sloginfo output, there are no errors >> displayed either. What version of the PCI server are you running (use >>-i)? >> > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post101470 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 16 May 2013 14:04:49 GMT http://community.qnx.com/sf/go/post101481 Hugh Brown 2013-05-16T14:04:49Z http://community.qnx.com/sf/go/post101470 Hugh, this is the version of pci-bios: # use -i pci-bios NAME=pci-bios DESCRIPTION=BIOS PCI server DATE=2009/05/20-17:12:26-EDT STATE=stable HOST=cctrunk USER=builder VERSION=6.4.1 TAGID=166 The "Add" messages are not from the application ... Best Regards --Armin Hugh Brown wrote: > I have no idea where the "Add" messages are coming from, as they are not > from the PCI server. Looking at the sloginfo output, there are no errors > displayed either. What version of the PCI server are you running (use -i)? > Thu, 16 May 2013 12:26:52 GMT http://community.qnx.com/sf/go/post101470 Armin Steinhoff 2013-05-16T12:26:52Z http://community.qnx.com/sf/go/post101469 I have no idea where the "Add" messages are coming from, as they are not from the PCI server. Looking at the sloginfo output, there are no errors displayed either. What version of the PCI server are you running (use -i)? -- Hugh Brown QNX Software Systems Limited 1001 Farrar Rd., Ottawa. ON. K2K 0B3. Telephone: 613-591-0931 On 2013-05-15 4:41 PM, "Armin Steinhoff" <community-noreply@qnx.com> wrote: >Hugh, > >I have attached slog.info. >The messages from PCI_tst are below: > ># PCI_tst >cp16xx_init: begin >cp16xx_os_pci_probe: begin >Add 205 8 Put: 806434c, beg : 8064018 end: 80a4018 >cp16xx_os_pci_probe: can't find device .. end >Add 213 7 Put: 806436c, beg : 8064018 end: 80a4018 >cp16xx_os_pci_probe: begin >Add 220 8 Put: 8064388, beg : 8064018 end: 80a4018 >Add 228 11 Put: 80643a8, beg : 8064018 end: 80a4018 >cp16xx_init: end >Add 239 7 Put: 80643d4, beg : 8064018 end: 80a4018 > >The messages including "Add .." are from pci-bios or slogger ? > >Regards > >--Armin > >Hugh Brown wrote: >> Armin, >> >> Please make sure that you have a large slog buffer (slogger -s256k) and >> then run the pci server with -vvv and send me the sloginfo output after >> you have run your program. >> >> Thanks, Hugh. >> > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post101464 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 16 May 2013 11:54:58 GMT http://community.qnx.com/sf/go/post101469 Hugh Brown 2013-05-16T11:54:58Z http://community.qnx.com/sf/go/post101468 Hugh, in the attachment is a kernel trace about the operation of "PCI_tst". Regards --Armin Hugh Brown wrote: > Armin, > > Please make sure that you have a large slog buffer (slogger -s256k) and > then run the pci server with -vvv and send me the sloginfo output after > you have run your program. > > Thanks, Hugh. > Thu, 16 May 2013 09:42:32 GMT http://community.qnx.com/sf/go/post101468 Armin Steinhoff 2013-05-16T09:42:32Z http://community.qnx.com/sf/go/post101464 Hugh, I have attached slog.info. The messages from PCI_tst are below: # PCI_tst cp16xx_init: begin cp16xx_os_pci_probe: begin Add 205 8 Put: 806434c, beg : 8064018 end: 80a4018 cp16xx_os_pci_probe: can't find device .. end Add 213 7 Put: 806436c, beg : 8064018 end: 80a4018 cp16xx_os_pci_probe: begin Add 220 8 Put: 8064388, beg : 8064018 end: 80a4018 Add 228 11 Put: 80643a8, beg : 8064018 end: 80a4018 cp16xx_init: end Add 239 7 Put: 80643d4, beg : 8064018 end: 80a4018 The messages including "Add .." are from pci-bios or slogger ? Regards --Armin Hugh Brown wrote: > Armin, > > Please make sure that you have a large slog buffer (slogger -s256k) and > then run the pci server with -vvv and send me the sloginfo output after > you have run your program. > > Thanks, Hugh. > Wed, 15 May 2013 20:42:00 GMT http://community.qnx.com/sf/go/post101464 Armin Steinhoff 2013-05-15T20:42:00Z http://community.qnx.com/sf/go/post101455 Armin, Please make sure that you have a large slog buffer (slogger -s256k) and then run the pci server with -vvv and send me the sloginfo output after you have run your program. Thanks, Hugh. -- Hugh Brown QNX Software Systems Limited 1001 Farrar Rd., Ottawa. ON. K2K 0B3. Telephone: 613-591-0931 On 2013-05-15 11:11 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote: >Hugh, > >Hugh Brown wrote: >> Armin, >> >> You should always clear the pci_dev_info buffer before inserting the >> vendor and device as the buffer will contain information from the >>previous >> attach and could cause confusion in the PCI server. > >After resetting the buffer to all zero and a new initialization .. the >PCI server remains confused :) > >Regards > >--Armin > > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post101452 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Wed, 15 May 2013 15:14:32 GMT http://community.qnx.com/sf/go/post101455 Hugh Brown 2013-05-15T15:14:32Z http://community.qnx.com/sf/go/post101452 Hugh, Hugh Brown wrote: > Armin, > > You should always clear the pci_dev_info buffer before inserting the > vendor and device as the buffer will contain information from the previous > attach and could cause confusion in the PCI server. After resetting the buffer to all zero and a new initialization .. the PCI server remains confused :) Regards --Armin Wed, 15 May 2013 15:11:37 GMT http://community.qnx.com/sf/go/post101452 Armin Steinhoff 2013-05-15T15:11:37Z http://community.qnx.com/sf/go/post101451 Hugh, I have checked with the debugger the status of the "pci_dev_buffer" after the first unsucessfull "pci_attach_device" call ... the buffer remains unchanged. OK ... I will switch to "pci_find_device" ... Thanks --Armin Hugh Brown wrote: > Armin, > > You should always clear the pci_dev_info buffer before inserting the > vendor and device as the buffer will contain information from the previous > attach and could cause confusion in the PCI server. You could also use the > pci_find_device() function instead of the pci_attach_device function. > > Hugh. > Wed, 15 May 2013 14:34:37 GMT http://community.qnx.com/sf/go/post101451 Armin Steinhoff 2013-05-15T14:34:37Z http://community.qnx.com/sf/go/post101436 > -----Message d'origine----- > De : Armin Steinhoff [mailto:community-noreply@qnx.com] > Envoyé : 15 mai 2013 03:40 > À : drivers-networking@community.qnx.com > Cc : Mario Charest; Mario Charest > Objet : Re: pci_attach_problem on bus 7 > > Mario, > > what is a "rogue program doing too many calls to fast" ?? > Do you believe it is not allowed to search a PCI interface by subsequent > usage of "pci_attach_device" calls?? Not at all, I was just trying to give pointers. > > --Armin > > PS: the example program is an uncommented and small extract of the > original resource manager > > Mario Charest wrote: > > > >> -----Message d'origine----- > >> De : Armin Steinhoff [mailto:community-noreply@qnx.com] > >> Envoyé : 14 mai 2013 15:10 > >> À : drivers-networking > >> Objet : Re: pci_attach_problem on bus 7 > >> > >> Hugh, > >> > >> "pci_att" finds the PCI board ... so pci_attach_device is OK. The > >> real problem is a little bit strange: > >> our resource manager has to look for three different PCI boards. The > >> actual board must be found in the second trail. > >> > >> When I start "PCI_tst" within a terminal window ... the PCI board > >> isn't recognized by the second "pci_attach_device". > >> But when I execute the code step by step by the debugger -> the board > >> is recognized ! > > Maybe I`m confusing it with something else ( gns) but could it be related to > a protection against rogue program doing too many calls to fast? > > > >> Source code and binaries are attached > >> > >> Regards > >> > >> --Armin > >> > >> > >> > >> > >> _______________________________________________ > >> > >> Networking Drivers > >> http://community.qnx.com/sf/go/post101410 > >> To cancel your subscription to this discussion, please e-mail > >> drivers- networking-unsubscribe@community.qnx.com > > > > > > > > _______________________________________________ > > > > Networking Drivers > > http://community.qnx.com/sf/go/post101415 > > To cancel your subscription to this discussion, please e-mail > > drivers-networking-unsubscribe@community.qnx.com > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post101429 > To cancel your subscription to this discussion, please e-mail drivers- > networking-unsubscribe@community.qnx.com Wed, 15 May 2013 12:13:01 GMT http://community.qnx.com/sf/go/post101436 Mario Charest 2013-05-15T12:13:01Z http://community.qnx.com/sf/go/post101435 Armin, You should always clear the pci_dev_info buffer before inserting the vendor and device as the buffer will contain information from the previous attach and could cause confusion in the PCI server. You could also use the pci_find_device() function instead of the pci_attach_device function. Hugh. -- Hugh Brown QNX Software Systems Limited 1001 Farrar Rd., Ottawa. ON. K2K 0B3. Telephone: 613-591-0931 On 2013-05-14 3:09 PM, "Armin Steinhoff" <community-noreply@qnx.com> wrote: >Hugh, > >"pci_att" finds the PCI board ... so pci_attach_device is OK. The real >problem is a little bit strange: >our resource manager has to look for three different PCI boards. The >actual board must be found in the second trail. > >When I start "PCI_tst" within a terminal window ... the PCI board isn't >recognized by the second "pci_attach_device". >But when I execute the code step by step by the debugger -> the board is >recognized ! > >Source code and binaries are attached > >Regards > >--Armin > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post101410 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Wed, 15 May 2013 11:33:37 GMT http://community.qnx.com/sf/go/post101435 Hugh Brown 2013-05-15T11:33:37Z http://community.qnx.com/sf/go/post101429 Mario, what is a "rogue program doing too many calls to fast" ?? Do you believe it is not allowed to search a PCI interface by subsequent usage of "pci_attach_device" calls?? --Armin PS: the example program is an uncommented and small extract of the original resource manager Mario Charest wrote: > >> -----Message d'origine----- >> De : Armin Steinhoff [mailto:community-noreply@qnx.com] >> Envoyé : 14 mai 2013 15:10 >> À : drivers-networking >> Objet : Re: pci_attach_problem on bus 7 >> >> Hugh, >> >> "pci_att" finds the PCI board ... so pci_attach_device is OK. The real problem >> is a little bit strange: >> our resource manager has to look for three different PCI boards. The actual >> board must be found in the second trail. >> >> When I start "PCI_tst" within a terminal window ... the PCI board isn't >> recognized by the second "pci_attach_device". >> But when I execute the code step by step by the debugger -> the board is >> recognized ! > Maybe I`m confusing it with something else ( gns) but could it be related to a protection against rogue program doing too many calls to fast? > >> Source code and binaries are attached >> >> Regards >> >> --Armin >> >> >> >> >> _______________________________________________ >> >> Networking Drivers >> http://community.qnx.com/sf/go/post101410 >> To cancel your subscription to this discussion, please e-mail drivers- >> networking-unsubscribe@community.qnx.com > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post101415 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Wed, 15 May 2013 07:40:30 GMT http://community.qnx.com/sf/go/post101429 Armin Steinhoff 2013-05-15T07:40:30Z http://community.qnx.com/sf/go/post101415 > -----Message d'origine----- > De : Armin Steinhoff [mailto:community-noreply@qnx.com] > Envoyé : 14 mai 2013 15:10 > À : drivers-networking > Objet : Re: pci_attach_problem on bus 7 > > Hugh, > > "pci_att" finds the PCI board ... so pci_attach_device is OK. The real problem > is a little bit strange: > our resource manager has to look for three different PCI boards. The actual > board must be found in the second trail. > > When I start "PCI_tst" within a terminal window ... the PCI board isn't > recognized by the second "pci_attach_device". > But when I execute the code step by step by the debugger -> the board is > recognized ! Maybe I`m confusing it with something else ( gns) but could it be related to a protection against rogue program doing too many calls to fast? > > Source code and binaries are attached > > Regards > > --Armin > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post101410 > To cancel your subscription to this discussion, please e-mail drivers- > networking-unsubscribe@community.qnx.com Tue, 14 May 2013 19:38:58 GMT http://community.qnx.com/sf/go/post101415 Mario Charest 2013-05-14T19:38:58Z http://community.qnx.com/sf/go/post101412 > Hugh, here is the binary! > > "pci_att" finds the PCI board ... so pci_attach_device is OK. The real problem > is a little bit strange: > our resource manager has to look for three different PCI boards. The actual > board must be found in the second trail. > > When I start "PCI_tst" within a terminal window ... the PCI board isn't > recognized by the second "pci_attach_device". > But when I execute the code step by step by the debugger -> the board is > recognized ! > > Source code and binaries are attached > > Regards > > --Armin Tue, 14 May 2013 19:11:05 GMT http://community.qnx.com/sf/go/post101412 Armin Steinhoff 2013-05-14T19:11:05Z http://community.qnx.com/sf/go/post101410 Hugh, "pci_att" finds the PCI board ... so pci_attach_device is OK. The real problem is a little bit strange: our resource manager has to look for three different PCI boards. The actual board must be found in the second trail. When I start "PCI_tst" within a terminal window ... the PCI board isn't recognized by the second "pci_attach_device". But when I execute the code step by step by the debugger -> the board is recognized ! Source code and binaries are attached Regards --Armin Tue, 14 May 2013 19:09:49 GMT http://community.qnx.com/sf/go/post101410 Armin Steinhoff 2013-05-14T19:09:49Z http://community.qnx.com/sf/go/post101294 Armin, I don't see any reason why the pci_attach_device should fail. Please can you run the attached program as 'pci_att 0x110a 0x4036' and send me the output. Thanks, Hugh. On 2013-05-10 8:36 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote: >Hugh, > >here is the output of "pci -vv" : > >Class = Network (Ethernet) >Vendor ID = 110ah, Siemens Nixdorf AG >Device ID = 4036h, Unknown Unknown >PCI index = 0h >Class Codes = 020000h >Revision ID = 1h >Bus number = 7 >Device number = 1 >Function num = 0 >Status Reg = 210h >Command Reg = 107h > I/O space access enabled > Memory space access enabled > Bus Master enabled > Special Cycle operations ignored > Memory Write and Invalidate disabled > Palette Snooping disabled > Parity Error Response disabled > Data/Address stepping disabled > SERR# driver enabled > Fast back-to-back transactions to different agents disabled >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 40h >Cache Line Size= 0h >PCI Mem Address = f7ff0000h 32bit length 65536 enabled >PCI Mem Address = f0ff0000h prefetchable 32bit length 65536 enabled >PCI Mem Address = f0000000h prefetchable 32bit length 8388608 enabled >PCI Mem Address = f6000000h 32bit length 16777216 enabled >PCI Mem Address = ee000000h prefetchable 32bit length 33554432 enabled >Subsystem Vendor ID = 1h >Subsystem ID = 1h >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT A >Interrupt line = 10 >CPU Interrupt = ah >Capabilities Pointer = 48h >Capability ID = 1h - Power Management >Capabilities = 7e0ah - 0h >Device Dependent Registers: >0x040: 0a11 3640 0100 0100 0100 0a7e 0000 0000 >0x050: 0000 0000 0000 ffff 0800 ffff 0800 80ff >0x060: 0000 00ff 0800 00fe 0000 0000 0000 0040 >0x070: 0000 0060 0000 0010 0000 0030 0000 0020 >0x080: 0000 0000 0001 0000 0000 0a7e 0100 0002 >0x090: 0100 0080 0000 0000 0800 00c0 0800 00d0 >0x0a0: 0000 0000 0100 ffbf 0700 003f 0800 00f0 >0x0b0: 0800 00f0 0000 0000 0000 0000 0000 0000 >0x0c0: 0000 0000 0000 0010 0000 0020 0200 0000 >0x0d0: 0f0f 0f0f 0000 0000 00f9 3f00 0000 0000 >0x0e0: 0000 0000 0000 0000 0000 0000 0000 0000 >0x0f0: 0100 0000 0100 0000 0100 0000 0100 0000 > > > >Hugh Brown wrote: >> Please supply the output from 'pci -vv' so that I can see all the >> information. >> >> >> >> On 2013-05-10 5:50 AM, "Armin Steinhoff" <community-noreply@qnx.com> >>wrote: >> >>> pci_attach_problem on bus 7 >>> >>> This is the PCI bus tree of an ASUS P7P55D motherboard: >>> >>> -[0000:00]-+-00.0 Intel Corporation Core Processor DMI >>> +-03.0-[01]----00.0 nVidia Corporation G96 [GeForce 9500 GT] >>> +-08.0 Intel Corporation Core Processor System Management >>> Registers >>> +-08.1 Intel Corporation Core Processor Semaphore and >>> Scratchpad Registers >>> +-08.2 Intel Corporation Core Processor System Control and >>> Status Registers >>> +-08.3 Intel Corporation Core Processor Miscellaneous >>> Registers >>> +-10.0 Intel Corporation Core Processor QPI Link >>> +-10.1 Intel Corporation Core Processor QPI Routing and >>> Protocol Registers >>> +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 >>> Enhanced Host Controller >>> +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High >>> Definition Audio >>> +-1c.0-[06]-- >>> +-1c.4-[05]-- >>> +-1c.5-[04]-- >>> +-1c.6-[03]-- >>> +-1c.7-[02]----00.0 Realtek Semiconductor Co., Ltd. >>> RTL8111/8168B PCI Express Gigabit Ethernet controller >>> +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 >>> Enhanced Host Controller >>> +-1e.0-[07]--+-01.0 Siemens Nixdorf AG Device 4036 >>> ############################################### >>> | \-02.0 Intel Corporation 82540EM Gigabit >>> Ethernet Controller >>> +-1f.0 Intel Corporation 5 Series Chipset LPC Interface >>> Controller >>> +-1f.2 Intel Corporation 5 Series/3400 Series Chipset 6 port >>> SATA AHCI Controller >>> \-1f.3 Intel Corporation 5 Series/3400 Series Chipset SMBus >>> Controller >>> >>> Why is "pci_attach_device" not able to attach the device on bus 7 >>>(marked >>> with ####...) ??? >>> >>> Regards >>> >>> --Armin >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Networking Drivers >>> http://community.qnx.com/sf/go/post101289 >>> To cancel your subscription to this discussion, please e-mail >>> drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> _______________________________________________ >> >> Networking Drivers >> http://community.qnx.com/sf/go/post101291 >> To cancel your subscription to this discussion, please e-mail >>drivers-networking-unsubscribe@community.qnx.com >> > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post101293 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Fri, 10 May 2013 12:47:04 GMT http://community.qnx.com/sf/go/post101294 Hugh Brown 2013-05-10T12:47:04Z http://community.qnx.com/sf/go/post101293 Hugh, here is the output of "pci -vv" : Class = Network (Ethernet) Vendor ID = 110ah, Siemens Nixdorf AG Device ID = 4036h, Unknown Unknown PCI index = 0h Class Codes = 020000h Revision ID = 1h Bus number = 7 Device number = 1 Function num = 0 Status Reg = 210h Command Reg = 107h I/O space access enabled Memory space access enabled Bus Master enabled Special Cycle operations ignored Memory Write and Invalidate disabled Palette Snooping disabled Parity Error Response disabled Data/Address stepping disabled SERR# driver enabled Fast back-to-back transactions to different agents disabled Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 40h Cache Line Size= 0h PCI Mem Address = f7ff0000h 32bit length 65536 enabled PCI Mem Address = f0ff0000h prefetchable 32bit length 65536 enabled PCI Mem Address = f0000000h prefetchable 32bit length 8388608 enabled PCI Mem Address = f6000000h 32bit length 16777216 enabled PCI Mem Address = ee000000h prefetchable 32bit length 33554432 enabled Subsystem Vendor ID = 1h Subsystem ID = 1h Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT A Interrupt line = 10 CPU Interrupt = ah Capabilities Pointer = 48h Capability ID = 1h - Power Management Capabilities = 7e0ah - 0h Device Dependent Registers: 0x040: 0a11 3640 0100 0100 0100 0a7e 0000 0000 0x050: 0000 0000 0000 ffff 0800 ffff 0800 80ff 0x060: 0000 00ff 0800 00fe 0000 0000 0000 0040 0x070: 0000 0060 0000 0010 0000 0030 0000 0020 0x080: 0000 0000 0001 0000 0000 0a7e 0100 0002 0x090: 0100 0080 0000 0000 0800 00c0 0800 00d0 0x0a0: 0000 0000 0100 ffbf 0700 003f 0800 00f0 0x0b0: 0800 00f0 0000 0000 0000 0000 0000 0000 0x0c0: 0000 0000 0000 0010 0000 0020 0200 0000 0x0d0: 0f0f 0f0f 0000 0000 00f9 3f00 0000 0000 0x0e0: 0000 0000 0000 0000 0000 0000 0000 0000 0x0f0: 0100 0000 0100 0000 0100 0000 0100 0000 Hugh Brown wrote: > Please supply the output from 'pci -vv' so that I can see all the > information. > > > > On 2013-05-10 5:50 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote: > >> pci_attach_problem on bus 7 >> >> This is the PCI bus tree of an ASUS P7P55D motherboard: >> >> -[0000:00]-+-00.0 Intel Corporation Core Processor DMI >> +-03.0-[01]----00.0 nVidia Corporation G96 [GeForce 9500 GT] >> +-08.0 Intel Corporation Core Processor System Management >> Registers >> +-08.1 Intel Corporation Core Processor Semaphore and >> Scratchpad Registers >> +-08.2 Intel Corporation Core Processor System Control and >> Status Registers >> +-08.3 Intel Corporation Core Processor Miscellaneous >> Registers >> +-10.0 Intel Corporation Core Processor QPI Link >> +-10.1 Intel Corporation Core Processor QPI Routing and >> Protocol Registers >> +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 >> Enhanced Host Controller >> +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High >> Definition Audio >> +-1c.0-[06]-- >> +-1c.4-[05]-- >> +-1c.5-[04]-- >> +-1c.6-[03]-- >> +-1c.7-[02]----00.0 Realtek Semiconductor Co., Ltd. >> RTL8111/8168B PCI Express Gigabit Ethernet controller >> +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 >> Enhanced Host Controller >> +-1e.0-[07]--+-01.0 Siemens Nixdorf AG Device 4036 >> ############################################### >> | \-02.0 Intel Corporation 82540EM Gigabit >> Ethernet Controller >> +-1f.0 Intel Corporation 5 Series Chipset LPC Interface >> Controller >> +-1f.2 Intel Corporation 5 Series/3400 Series Chipset 6 port >> SATA AHCI Controller >> \-1f.3 Intel Corporation 5 Series/3400 Series Chipset SMBus >> Controller >> >> Why is "pci_attach_device" not able to attach the device on bus 7 (marked >> with ####...) ??? >> >> Regards >> >> --Armin >> >> >> >> >> >> _______________________________________________ >> >> Networking Drivers >> http://community.qnx.com/sf/go/post101289 >> To cancel your subscription to this discussion, please e-mail >> drivers-networking-unsubscribe@community.qnx.com > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post101291 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Fri, 10 May 2013 12:36:10 GMT http://community.qnx.com/sf/go/post101293 Armin Steinhoff 2013-05-10T12:36:10Z http://community.qnx.com/sf/go/post101291 Please supply the output from 'pci -vv' so that I can see all the information. On 2013-05-10 5:50 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote: >pci_attach_problem on bus 7 > >This is the PCI bus tree of an ASUS P7P55D motherboard: > >-[0000:00]-+-00.0 Intel Corporation Core Processor DMI > +-03.0-[01]----00.0 nVidia Corporation G96 [GeForce 9500 GT] > +-08.0 Intel Corporation Core Processor System Management >Registers > +-08.1 Intel Corporation Core Processor Semaphore and >Scratchpad Registers > +-08.2 Intel Corporation Core Processor System Control and >Status Registers > +-08.3 Intel Corporation Core Processor Miscellaneous >Registers > +-10.0 Intel Corporation Core Processor QPI Link > +-10.1 Intel Corporation Core Processor QPI Routing and >Protocol Registers > +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 >Enhanced Host Controller > +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High >Definition Audio > +-1c.0-[06]-- > +-1c.4-[05]-- > +-1c.5-[04]-- > +-1c.6-[03]-- > +-1c.7-[02]----00.0 Realtek Semiconductor Co., Ltd. >RTL8111/8168B PCI Express Gigabit Ethernet controller > +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 >Enhanced Host Controller > +-1e.0-[07]--+-01.0 Siemens Nixdorf AG Device 4036 >############################################### > | \-02.0 Intel Corporation 82540EM Gigabit >Ethernet Controller > +-1f.0 Intel Corporation 5 Series Chipset LPC Interface >Controller > +-1f.2 Intel Corporation 5 Series/3400 Series Chipset 6 port >SATA AHCI Controller > \-1f.3 Intel Corporation 5 Series/3400 Series Chipset SMBus >Controller > >Why is "pci_attach_device" not able to attach the device on bus 7 (marked >with ####...) ??? > >Regards > >--Armin > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post101289 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Fri, 10 May 2013 11:26:32 GMT http://community.qnx.com/sf/go/post101291 Hugh Brown 2013-05-10T11:26:32Z http://community.qnx.com/sf/go/post101289 pci_attach_problem on bus 7 This is the PCI bus tree of an ASUS P7P55D motherboard: -[0000:00]-+-00.0 Intel Corporation Core Processor DMI +-03.0-[01]----00.0 nVidia Corporation G96 [GeForce 9500 GT] +-08.0 Intel Corporation Core Processor System Management Registers +-08.1 Intel Corporation Core Processor Semaphore and Scratchpad Registers +-08.2 Intel Corporation Core Processor System Control and Status Registers +-08.3 Intel Corporation Core Processor Miscellaneous Registers +-10.0 Intel Corporation Core Processor QPI Link +-10.1 Intel Corporation Core Processor QPI Routing and Protocol Registers +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High Definition Audio +-1c.0-[06]-- +-1c.4-[05]-- +-1c.5-[04]-- +-1c.6-[03]-- +-1c.7-[02]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller +-1e.0-[07]--+-01.0 Siemens Nixdorf AG Device 4036 ############################################### | \-02.0 Intel Corporation 82540EM Gigabit Ethernet Controller +-1f.0 Intel Corporation 5 Series Chipset LPC Interface Controller +-1f.2 Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller \-1f.3 Intel Corporation 5 Series/3400 Series Chipset SMBus Controller Why is "pci_attach_device" not able to attach the device on bus 7 (marked with ####...) ??? Regards --Armin Fri, 10 May 2013 09:50:35 GMT http://community.qnx.com/sf/go/post101289 Armin Steinhoff 2013-05-10T09:50:35Z http://community.qnx.com/sf/go/post101234 setsockopt(s, SOL_SOCKET, SO_RCVBUF, ,) Sent from my BlackBerry 10 smartphone on the Rogers network. From: Abhay Ravi Chandran Sent: Tuesday, May 7, 2013 12:19 PM To: drivers-networking Reply To: drivers-networking@community.qnx.com Subject: Re: TCP Window size How do I change the TCP window size in QNX 6.5.0 SP1 to 256KB ? _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post101233 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Tue, 07 May 2013 16:24:50 GMT http://community.qnx.com/sf/go/post101234 Sean Boudreau 2013-05-07T16:24:50Z http://community.qnx.com/sf/go/post101233 How do I change the TCP window size in QNX 6.5.0 SP1 to 256KB ? Tue, 07 May 2013 16:19:56 GMT http://community.qnx.com/sf/go/post101233 Abhay Ravi Chandran 2013-05-07T16:19:56Z http://community.qnx.com/sf/go/post101230 Yes, it's handled by the network stack, just like on every other OS out there. Various window sizes are supported. On Tue, May 07, 2013 at 10:57:41AM -0400, Abhay Ravi Chandran wrote: > I tried to change the window size using the -w option but it gives a warning saying window size requested is 256 KB but current window size is 32 KB. Some research on the internet led me to the conclusion that the TCP window size is dependent on the network stack. I wanted to know what is the TCP window size supported by the QNX network stack? > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post101224 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Tue, 07 May 2013 15:37:36 GMT http://community.qnx.com/sf/go/post101230 Sean Boudreau 2013-05-07T15:37:36Z http://community.qnx.com/sf/go/post101224 I tried to change the window size using the -w option but it gives a warning saying window size requested is 256 KB but current window size is 32 KB. Some research on the internet led me to the conclusion that the TCP window size is dependent on the network stack. I wanted to know what is the TCP window size supported by the QNX network stack? Tue, 07 May 2013 14:57:41 GMT http://community.qnx.com/sf/go/post101224 Abhay Ravi Chandran 2013-05-07T14:57:41Z http://community.qnx.com/sf/go/post101194 There's an iperf option to vary this. Sent from my BlackBerry 10 smartphone on the Rogers network. From: Abhay Ravi Chandran Sent: Monday, May 6, 2013 6:00 PM To: drivers-networking Reply To: drivers-networking@community.qnx.com Subject: TCP Window size Hi, I was trying to run iperf with a TCP window size of 256 KB but find that the default window size is limited to 32 KB. Is there any way to change this or is the NetBSD stack limiting the TCP window size to 32 KB. Thanks Regards Abhay _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post101193 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Mon, 06 May 2013 22:06:49 GMT http://community.qnx.com/sf/go/post101194 Sean Boudreau 2013-05-06T22:06:49Z http://community.qnx.com/sf/go/post101193 Hi, I was trying to run iperf with a TCP window size of 256 KB but find that the default window size is limited to 32 KB. Is there any way to change this or is the NetBSD stack limiting the TCP window size to 32 KB. Thanks Regards Abhay Mon, 06 May 2013 22:00:12 GMT http://community.qnx.com/sf/go/post101193 Abhay Ravi Chandran 2013-05-06T22:00:12Z http://community.qnx.com/sf/go/post100765 Hi, Did you find solution for this problem? I have a similar setup like you except, I only have a single instance of io-pkt. And in the kernel trace I can clearly see the interrupt is coming, but the io-pkt is blocked for about 3 ms at times from the previous interrupt. Sun, 21 Apr 2013 11:17:43 GMT http://community.qnx.com/sf/go/post100765 Suganthan Subramaniam 2013-04-21T11:17:43Z http://community.qnx.com/sf/go/post100403 Thanks for prompt reply. My post was a kind of a reminder, that this file should be updated in "released version". I have already updated it myself. Regards, PKY > Here is the updated net file. > > > > On 2013-04-09 7:43 AM, "Pavol Kycina" <community-noreply@qnx.com> wrote: > > >Hello, > > > >It seems that successor to this driver made it into latest release. But > >it seems to me that ../enum/devices/net hasn't been updated to start this > >driver for 8086:1502 device. > > > >PKY > > > >> Here is an updated driver. > >> > >> -- > >> Hugh Brown > >> QNX Software Systems Limited > >> 1001 Farrar Rd., > >> Ottawa. ON. K2K 0B3. > >> Telephone: 613-591-0931 > >> > >> > >> > >> > >> > >> > >> > >> On 12-02-23 4:52 AM, "Praveen Kumar P.S." <community-noreply@qnx.com> > >> wrote: > >> > >> >Hi, > >> > > >> > I'm a beginner @ Qnx, trying to explore Qnx build environment and > >> >networking. > >> >When I installed Neutrino OS 6.5.0 on my dell optiplex 990, I'm not > >>able > >> >to bring up the network interface. I have no issues when running the > >> >image from VM (same QNX .iso). > >> >After some reading and searching I found that my NIC card is intel > >>82579M > >> > > >> >devid= 1502 and vendor id = 8086 > >> > > >> >Can some one help in providing the driver for this device? > >> > > >> >I tried using devnp-e1000.so available in other forums but not > >>successful. > >> >Thanks. > >> > > >> >Rgds, > >> >Praveen. > >> > > >> > > >> > > >> >_______________________________________________ > >> > > >> >Networking Drivers > >> >http://community.qnx.com/sf/go/post91729 > >> > > >> > > > > > > > > > > > > > >_______________________________________________ > > > >Networking Drivers > >http://community.qnx.com/sf/go/post100398 > >To cancel your subscription to this discussion, please e-mail > >drivers-networking-unsubscribe@community.qnx.com > Tue, 09 Apr 2013 13:21:01 GMT http://community.qnx.com/sf/go/post100403 Pavol Kycina 2013-04-09T13:21:01Z http://community.qnx.com/sf/go/post100400 Here is the updated net file. On 2013-04-09 7:43 AM, "Pavol Kycina" <community-noreply@qnx.com> wrote: >Hello, > >It seems that successor to this driver made it into latest release. But >it seems to me that ../enum/devices/net hasn't been updated to start this >driver for 8086:1502 device. > >PKY > >> Here is an updated driver. >> >> -- >> Hugh Brown >> QNX Software Systems Limited >> 1001 Farrar Rd., >> Ottawa. ON. K2K 0B3. >> Telephone: 613-591-0931 >> >> >> >> >> >> >> >> On 12-02-23 4:52 AM, "Praveen Kumar P.S." <community-noreply@qnx.com> >> wrote: >> >> >Hi, >> > >> > I'm a beginner @ Qnx, trying to explore Qnx build environment and >> >networking. >> >When I installed Neutrino OS 6.5.0 on my dell optiplex 990, I'm not >>able >> >to bring up the network interface. I have no issues when running the >> >image from VM (same QNX .iso). >> >After some reading and searching I found that my NIC card is intel >>82579M >> > >> >devid= 1502 and vendor id = 8086 >> > >> >Can some one help in providing the driver for this device? >> > >> >I tried using devnp-e1000.so available in other forums but not >>successful. >> >Thanks. >> > >> >Rgds, >> >Praveen. >> > >> > >> > >> >_______________________________________________ >> > >> >Networking Drivers >> >http://community.qnx.com/sf/go/post91729 >> > >> > > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post100398 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 09 Apr 2013 12:14:57 GMT http://community.qnx.com/sf/go/post100400 Hugh Brown 2013-04-09T12:14:57Z http://community.qnx.com/sf/go/post100398 Hello, It seems that successor to this driver made it into latest release. But it seems to me that ../enum/devices/net hasn't been updated to start this driver for 8086:1502 device. PKY > Here is an updated driver. > > -- > Hugh Brown > QNX Software Systems Limited > 1001 Farrar Rd., > Ottawa. ON. K2K 0B3. > Telephone: 613-591-0931 > > > > > > > > On 12-02-23 4:52 AM, "Praveen Kumar P.S." <community-noreply@qnx.com> > wrote: > > >Hi, > > > > I'm a beginner @ Qnx, trying to explore Qnx build environment and > >networking. > >When I installed Neutrino OS 6.5.0 on my dell optiplex 990, I'm not able > >to bring up the network interface. I have no issues when running the > >image from VM (same QNX .iso). > >After some reading and searching I found that my NIC card is intel 82579M > > > >devid= 1502 and vendor id = 8086 > > > >Can some one help in providing the driver for this device? > > > >I tried using devnp-e1000.so available in other forums but not successful. > >Thanks. > > > >Rgds, > >Praveen. > > > > > > > >_______________________________________________ > > > >Networking Drivers > >http://community.qnx.com/sf/go/post91729 > > > Tue, 09 Apr 2013 11:43:47 GMT http://community.qnx.com/sf/go/post100398 Pavol Kycina 2013-04-09T11:43:47Z http://community.qnx.com/sf/go/post100366 No, we don't support this chipset. The driver that we have for the other chipsets is a ported NetBSD driver. On 2013-04-03 2:43 PM, "Martin Gagnon" <community-noreply@qnx.com> wrote: >I'm evaluating the Advantech TREK-753 for mobile application and it has a >Ralink RT3091 WiFi PCI card. >I see QNX currently support Ralink 2500 and 2600 series, any chance to >see support for this one? >PCI output: >Class = Network (Other) >Vendor ID = 1814h, RaLink >Device ID = 3091h, RT3091 Wireless 802.11n 1T/2R PCIe >PCI index = 0h >BAR - 0 [Mem] = fdcf0000h enabled >PCI Int Pin = INT A >Interrupt line = 6 >CPU Interrupt = 6h > >Thank you > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post100292 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Mon, 08 Apr 2013 11:30:51 GMT http://community.qnx.com/sf/go/post100366 Hugh Brown 2013-04-08T11:30:51Z http://community.qnx.com/sf/go/post100298 Thank you sir, this is what I was looking for. Thu, 04 Apr 2013 12:03:29 GMT http://community.qnx.com/sf/go/post100298 Robert Murrell 2013-04-04T12:03:29Z http://community.qnx.com/sf/go/post100295 IFM_STATUS_DESC(ifms, bit) in net/if_media.h should do what you need. And the ioctl you need is SIOCGIFMEDIA. On 04/03/2013 03:50 PM, Robert Murrell wrote: > How do I programmatically detect if the Ethernet cable has been unplugged? I tried the ioctl SIOCGIFFLAGS command to look at the IFF_UP and IFF_RUNNING flags, but these are always set. ifconfig seems to know because when the cable is plugged in, it displays: > > status: active > > Since the source code is nearly impossible to access, I can't see how it knows. Does anyone know the magic function to determine this? > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post100294 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Wed, 03 Apr 2013 20:14:48 GMT http://community.qnx.com/sf/go/post100295 Khaled Mously 2013-04-03T20:14:48Z http://community.qnx.com/sf/go/post100294 How do I programmatically detect if the Ethernet cable has been unplugged? I tried the ioctl SIOCGIFFLAGS command to look at the IFF_UP and IFF_RUNNING flags, but these are always set. ifconfig seems to know because when the cable is plugged in, it displays: status: active Since the source code is nearly impossible to access, I can't see how it knows. Does anyone know the magic function to determine this? Wed, 03 Apr 2013 19:50:49 GMT http://community.qnx.com/sf/go/post100294 Robert Murrell 2013-04-03T19:50:49Z http://community.qnx.com/sf/go/post100292 I'm evaluating the Advantech TREK-753 for mobile application and it has a Ralink RT3091 WiFi PCI card. I see QNX currently support Ralink 2500 and 2600 series, any chance to see support for this one? PCI output: Class = Network (Other) Vendor ID = 1814h, RaLink Device ID = 3091h, RT3091 Wireless 802.11n 1T/2R PCIe PCI index = 0h BAR - 0 [Mem] = fdcf0000h enabled PCI Int Pin = INT A Interrupt line = 6 CPU Interrupt = 6h Thank you Wed, 03 Apr 2013 18:43:50 GMT http://community.qnx.com/sf/go/post100292 Martin Gagnon 2013-04-03T18:43:50Z http://community.qnx.com/sf/go/post100103 Hi, We're in need of getting the data/info about what was the current/past data xfer rate, tx/rx on different interfaces, as wifi, cellular etc. Is there a way to find that information, without much complications.... I see on my Laguna device, that there are regular notifications, saying x kB transferred in last 4 hrs, so I assume something like what we need is available already. Pls help. Pinku Bhatnagar - CDMA PDT2 Dallas. Fri, 22 Mar 2013 16:09:14 GMT http://community.qnx.com/sf/go/post100103 Pinku Bhatnagar 2013-03-22T16:09:14Z http://community.qnx.com/sf/go/post99955 There have been multiple changes to the 8169 driver, especially to the PHY firmware for the different devices. -- Hugh Brown QNX Software Systems Limited 1001 Farrar Rd., Ottawa. ON. K2K 0B3. Telephone: 613-591-0931 On 2013-03-11 3:00 PM, "Tao Zhang" <community-noreply@qnx.com> wrote: >Hi Hugh, > >Thanks for the attachment, it solved my issue. Here is what happened: >- Our devices uses QNX 6.5.0, with RealTek NIC. >- Our ifconfig media was set to 100baseT/duplex, which is sufficient for >our need. >- I uses iperf to push over 80Mbps UDP to our device. For a few seconds, >our device network will crash or hung, power cycle will be needed to >bring its network back. > >I used your attachment for devnp-rtl8169.so, it solves the problem. I can >pump over 400Mbps to device, and device can realize 90Mpbs on iperf >server. > >Can you elaborate for what is change on devnp-rtl8169.so? I am guessing >may be in the area of loadshedding or traffic control at MAC layer. > >Thanks, > >Tao > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post99789 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Mon, 18 Mar 2013 11:49:00 GMT http://community.qnx.com/sf/go/post99955 Hugh Brown 2013-03-18T11:49:00Z http://community.qnx.com/sf/go/post99848 Thank You Jim for your help. Regards, Marcin. Wed, 13 Mar 2013 10:48:46 GMT http://community.qnx.com/sf/go/post99848 Marcin Morawski 2013-03-13T10:48:46Z http://community.qnx.com/sf/go/post99840 Hi Marcin: I believe you have to contact qnx support directly, I'm not current with their list of usb wifi dongle products. Hope it helps. :) B/R Jim On Tue, Mar 12, 2013 at 11:07 PM, Marcin Morawski <community-noreply@qnx.com > wrote: > Hi Jim, > > Thank You for quick reply. I think I'll take Your advice. > Do you know any USB WiFi dongles that QNX supports . > I'm planning to add WiFi functionality to my Pico ITX SBC and ther's no > other way to do it than by USB dongle. > > Thanks again, > > Regards, > Marcin. > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post99829 > To cancel your subscription to this discussion, please e-mail > drivers-networking-unsubscribe@community.qnx.com > Wed, 13 Mar 2013 02:10:40 GMT http://community.qnx.com/sf/go/post99840 Jim Tan 2013-03-13T02:10:40Z http://community.qnx.com/sf/go/post99829 Hi Jim, Thank You for quick reply. I think I'll take Your advice. Do you know any USB WiFi dongles that QNX supports . I'm planning to add WiFi functionality to my Pico ITX SBC and ther's no other way to do it than by USB dongle. Thanks again, Regards, Marcin. Tue, 12 Mar 2013 15:07:04 GMT http://community.qnx.com/sf/go/post99829 Marcin Morawski 2013-03-12T15:07:04Z http://community.qnx.com/sf/go/post99796 Hi Marcin: A straight port of the urtwn driver source from NetBSD to QNX doesn't work. I had to do a raw port using the linux driver instead. Then ran into issues with device power-on initialization. Unsure if my embedded hardware is incapable of supporting module or a timing problem with codes. Realtek vendor support non-existent. Recommendation: Unless you really need some capability of these new dongles, otherwise it might be just faster to go with devices that qnx already supports or opt for a linux distro instead. These new dongles work great on traditional windows and ubuntu... fyi: I am no longer working on this problem anymore, my contract has already lapsed. Hope it helps. B/R Jim On Mon, Mar 11, 2013 at 9:10 PM, Marcin Morawski <community-noreply@qnx.com>wrote: > Hi Jim, > > Did You succeed with porting this RTL8192CU driver on QNX? > I have similar problem with WiFi USB dongle that runs on RTL8188CU QNX > driver i couldn't find anywhere. I've finally stuck on your post and i > thought Your experience in this matter might be helpfull. On netBSD page > You've mentioned there is RTL8188CU driver added so this ported driver > might work for me as well. > > I would be gratefull for any help. > > Regards, > Marcin. > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post99785 > To cancel your subscription to this discussion, please e-mail > drivers-networking-unsubscribe@community.qnx.com > Tue, 12 Mar 2013 01:31:34 GMT http://community.qnx.com/sf/go/post99796 Jim Tan 2013-03-12T01:31:34Z http://community.qnx.com/sf/go/post99789 Hi Hugh, Thanks for the attachment, it solved my issue. Here is what happened: - Our devices uses QNX 6.5.0, with RealTek NIC. - Our ifconfig media was set to 100baseT/duplex, which is sufficient for our need. - I uses iperf to push over 80Mbps UDP to our device. For a few seconds, our device network will crash or hung, power cycle will be needed to bring its network back. I used your attachment for devnp-rtl8169.so, it solves the problem. I can pump over 400Mbps to device, and device can realize 90Mpbs on iperf server. Can you elaborate for what is change on devnp-rtl8169.so? I am guessing may be in the area of loadshedding or traffic control at MAC layer. Thanks, Tao Mon, 11 Mar 2013 19:00:56 GMT http://community.qnx.com/sf/go/post99789 Tao Zhang 2013-03-11T19:00:56Z http://community.qnx.com/sf/go/post99786 I think VersaLogic has provided one for TomCat IPC Mon, 11 Mar 2013 14:51:08 GMT http://community.qnx.com/sf/go/post99786 Madjid Jafari 2013-03-11T14:51:08Z http://community.qnx.com/sf/go/post99785 Hi Jim, Did You succeed with porting this RTL8192CU driver on QNX? I have similar problem with WiFi USB dongle that runs on RTL8188CU QNX driver i couldn't find anywhere. I've finally stuck on your post and i thought Your experience in this matter might be helpfull. On netBSD page You've mentioned there is RTL8188CU driver added so this ported driver might work for me as well. I would be gratefull for any help. Regards, Marcin. Mon, 11 Mar 2013 13:10:34 GMT http://community.qnx.com/sf/go/post99785 Marcin Morawski 2013-03-11T13:10:34Z http://community.qnx.com/sf/go/post99194 Hello, I have a relatively a old platform with: Host processor: Jacinto with ARM9 OS. QNX 6.4.0. I need to find a Wifi usb dongle (802.11g) and the appropriate driver for it. I would appreciate if anyone can give me some information on where I can find a dongle and the driver for this configuration. Regards, RS. Sat, 09 Feb 2013 06:30:13 GMT http://community.qnx.com/sf/go/post99194 Reza Salehi 2013-02-09T06:30:13Z http://community.qnx.com/sf/go/post99193 does anyone have solution? i run into similar problem; in my case the driver works only if mac address set as default 00-00-60-00-00-01; once i use mac option to change address nic doesn't reply to ping from external and nothing works. drivers attached in this discussion have same issue. thanks ed Sat, 09 Feb 2013 01:32:55 GMT http://community.qnx.com/sf/go/post99193 Eduard Kromskoy 2013-02-09T01:32:55Z http://community.qnx.com/sf/go/post99067 I will address your questions via the support ticket you opened (ref# 00123260). On 02/05/2013 05:32 AM, Santhosh A wrote: > Hello, > > I am using p1020 bsp and I am using BPF techniques to send the raw ethernet packets. I have two P1020 directly connected. If i send a custom raw ethernet packet with the ethernet mac address from one board to another with destination as MAC address of second board ethernet port, the packets were not getting transmitted from first p1020 ethernet port. > > At the same time, all multicast messages and some other mac addresses which is not of those two ethernet ports are sent without issues. the problem is only with unicast mac address as destination which is there in the network. > > Is there any configuration need to be done to io-pkt for the same? > > Please guide me to solve this problem. > > Thanks. > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post99059 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Tue, 05 Feb 2013 13:35:45 GMT http://community.qnx.com/sf/go/post99067 Gervais Mulongoy 2013-02-05T13:35:45Z http://community.qnx.com/sf/go/post99059 Hello, I am using p1020 bsp and I am using BPF techniques to send the raw ethernet packets. I have two P1020 directly connected. If i send a custom raw ethernet packet with the ethernet mac address from one board to another with destination as MAC address of second board ethernet port, the packets were not getting transmitted from first p1020 ethernet port. At the same time, all multicast messages and some other mac addresses which is not of those two ethernet ports are sent without issues. the problem is only with unicast mac address as destination which is there in the network. Is there any configuration need to be done to io-pkt for the same? Please guide me to solve this problem. Thanks. Tue, 05 Feb 2013 10:32:15 GMT http://community.qnx.com/sf/go/post99059 Santhosh A 2013-02-05T10:32:15Z http://community.qnx.com/sf/go/post99002 Hi, Sean, Yes. The thread 2 is always RUNNING and the CPU usage is 100% when this problem happens. Following your instruction, we got backtrace in gdb as below: (showing both thread 2 and thread 4). Could you tell us what the culprit that we got into this situation? [New pid 204821 tid 1] [New pid 204821 tid 2] [New pid 204821 tid 3] [New pid 204821 tid 4] #0 0x0103c67c in SignalWaitinfo () from libc.so.3 (gdb) thread 2 [Switching to thread 2 (pid 204821 tid 2)]#0 0x0018f12c in softclock () (gdb) bt #0 0x0018f12c in softclock () #1 0x0018aeac in hardclock () #2 0x001ab6b8 in receive_loop_multi () #3 0x0019f9a8 in thread_init () #4 0x0101f9f0 in timer_settime () from libc.so.3 Backtrace stopped: frame did not save the PC (gdb) thread 4 [Switching to thread 4 (pid 204821 tid 4)]#0 0x0103c778 in SyncMutexLock_r () from libc.so.3 (gdb) bt #0 0x0103c778 in SyncMutexLock_r () from libc.so.3 #1 0x0019f8c8 in exclusion_lock_mp () #2 0x0018eb10 in callout_reset () #3 0x0018ec30 in callout_msec () #4 0x7801ecdc in woal_ioctl_get_bss_resp () from devnp-mrvl_wlan-sdiorm.so Backtrace stopped: frame did not save the PC Thanks, Yurong Fri, 01 Feb 2013 18:22:34 GMT http://community.qnx.com/sf/go/post99002 Yurong Sun 2013-02-01T18:22:34Z http://community.qnx.com/sf/go/post98969 So instead of using the timestamp, I'm testing timing between calls of my callback function from pcap_loop using CLOCK_REALTIME and getting strange results still. The shortest time between packets is 0 (which happens for many packets), and then 0.019 ms (this makes sense as my tick size is set to be 20us). However, no packets are close to 4ms apart (as I know they should be). There are also plenty of packets that are very far apart, as far as 1.5 seconds apart. The average time between packets is close to 4ms so I think its a matter of when the function is being called. I've also boosted the priority of this program so I'm not really sure what else I can do. Have you seen behavior like this? Or have some idea about the kind of thing I may be missing? It is nice to be reading these packets though! Fri, 01 Feb 2013 04:44:30 GMT http://community.qnx.com/sf/go/post98969 Adam Barber 2013-02-01T04:44:30Z http://community.qnx.com/sf/go/post98968 Hi, We observed strange mutex blocking problem related to callout_* for our WiFi driver timer. We used our driver as AP mode. and basically we have 3 types of timers: 1. control timer: for controlling Tx flow 2. data timer: for flush out Rx packet if timeout. One per each WiFi Station connected. 3. command timer: for command timeout We have control timer on io-pkt thread, the other 2 types of timer on our work thread, created by nw_pthread_create(). Depending on the conditions, the 3 timers are frequently start/stop or created on the fly (for new WiFi client, e.g). Our observation is that when we running stress test with one AP against 2 WiFi stations, we have mutex lock up issue when calling callout_msec(..) or callout_stop(..). Our log shows the line before we call the callout_** function, but never returns. We believe the mutex being blocked is from TCP/IP stack of QNX and we would like to know why this issue happens. The pidin shows: #pidin 1036304 1 /boot/io-pkt-v4-hc 21r SIGWAITINFO 1036304 2 /boot/io-pkt-v4-hc 25r RUNNING 1036304 3 /boot/io-pkt-v4-hc 21r RECEIVE 24 1036304 4 /boot/io-pkt-v4-hc 25r MUTEX (0x20b670) 1036304-02 #0 Thanks, Yurong Fri, 01 Feb 2013 04:30:22 GMT http://community.qnx.com/sf/go/post98968 Yurong Sun 2013-02-01T04:30:22Z http://community.qnx.com/sf/go/post98967 Alright, I'll have to look into bpf. Thank you for the help, I'm fairly new to networking. Fri, 01 Feb 2013 03:41:07 GMT http://community.qnx.com/sf/go/post98967 Adam Barber 2013-02-01T03:41:07Z http://community.qnx.com/sf/go/post98966 recvfrom isn't timer driven. tcpdump is receiving them faster than that as well via bpf, they're just timestamped at that granularity. There's no linux PF_PACKET in QNX so you can't get all packets via recvfrom, you have to use bpf / libpcap. On Thu, Jan 31, 2013 at 09:59:43PM -0500, Adam Barber wrote: > So that makes sense, but then why was I able to read packets faster than that using "recvfrom"? I'm guessing because maybe it isn't interrupt driven? > > If that isn't interrupt driven, how can I use that function (or recv) to read packets promiscuously? > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98965 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Fri, 01 Feb 2013 03:17:09 GMT http://community.qnx.com/sf/go/post98966 Sean Boudreau 2013-02-01T03:17:09Z http://community.qnx.com/sf/go/post98965 So that makes sense, but then why was I able to read packets faster than that using "recvfrom"? I'm guessing because maybe it isn't interrupt driven? If that isn't interrupt driven, how can I use that function (or recv) to read packets promiscuously? Fri, 01 Feb 2013 02:59:43 GMT http://community.qnx.com/sf/go/post98965 Adam Barber 2013-02-01T02:59:43Z http://community.qnx.com/sf/go/post98962 8.4 ms is the granularity of the timestamp in io-pkt. The packets aren't actually received at that interval since everything is interrupt driven. On Thu, Jan 31, 2013 at 09:22:12PM -0500, Adam Barber wrote: > So even after doing this, I am unable to read packets in my program. I have UDP packets being sent to another device, and then using port mirroring on my switch I have those ports also showing up on the QNX port. I know QNX can see them because tcpdump shows them. In fact, tcpdump can read them whether I set the adaptor into promiscuous mode on my own or not. > > However, I can't figure out how to read them in my code. Everything I've found online that seems like it would offer a solution in another linux/unix environment is not available in 6.5. > > I got it to work somewhat with the pcap library, the problem here is that there is some sort of timing issue. On the real receiver, I see that the packets are ~4ms apart as I expect, but using the pcap library (or tcpdump, which is based on the pcap library) the packets are either ~8ms apart or 0ms apart. They average out to the same period between packets but the timing is important for my application. > > I've done another test, where I direct packets to my QNX machine with a 4ms period and I can read those using the standard socket calls very easily and the timing is right. This leads me to believe there is something going on with the pcap functions, and I'm hoping someone can help me figure out how to read packets promiscuously another way. > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98961 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Fri, 01 Feb 2013 02:26:19 GMT http://community.qnx.com/sf/go/post98962 Sean Boudreau 2013-02-01T02:26:19Z http://community.qnx.com/sf/go/post98961 So even after doing this, I am unable to read packets in my program. I have UDP packets being sent to another device, and then using port mirroring on my switch I have those ports also showing up on the QNX port. I know QNX can see them because tcpdump shows them. In fact, tcpdump can read them whether I set the adaptor into promiscuous mode on my own or not. However, I can't figure out how to read them in my code. Everything I've found online that seems like it would offer a solution in another linux/unix environment is not available in 6.5. I got it to work somewhat with the pcap library, the problem here is that there is some sort of timing issue. On the real receiver, I see that the packets are ~4ms apart as I expect, but using the pcap library (or tcpdump, which is based on the pcap library) the packets are either ~8ms apart or 0ms apart. They average out to the same period between packets but the timing is important for my application. I've done another test, where I direct packets to my QNX machine with a 4ms period and I can read those using the standard socket calls very easily and the timing is right. This leads me to believe there is something going on with the pcap functions, and I'm hoping someone can help me figure out how to read packets promiscuously another way. Fri, 01 Feb 2013 02:22:12 GMT http://community.qnx.com/sf/go/post98961 Adam Barber 2013-02-01T02:22:12Z http://community.qnx.com/sf/go/post98973 Is thread 2 always in state RUNNING? Force a core with 'dumper -p <io-pkt pid>' and get a back trace of thread 2 with gdb. Sent from my BlackBerry 10 smartphone. From: Yurong Sun Sent: Thursday, January 31, 2013 6:00 PM To: drivers-networking Reply To: drivers-networking@community.qnx.com Cc: yurong@marvell.com Subject: network driver timer lock up issue Hi, We observed strange mutex blocking problem related to callout_* for our WiFi driver timer. We used our driver as AP mode. and basically we have 3 types of timers: 1. control timer: for controlling Tx flow 2. data timer: for flush out Rx packet if timeout. One per each WiFi Station connected. 3. command timer: for command timeout We have control timer on io-pkt thread, the other 2 types of timer on our work thread, created by nw_pthread_create(). Depending on the conditions, the 3 timers are frequently start/stop or created on the fly (for new WiFi client, e.g). Our observation is that when we running stress test with one AP against 2 WiFi stations, we have mutex lock up issue when calling callout_msec(..) or callout_stop(..). Our log shows the line before we call the callout_** function, but never returns. We believe the mutex being blocked is from TCP/IP stack of QNX and we would like to know why this issue happens. The pidin shows: #pidin 1036304 1 /boot/io-pkt-v4-hc 21r SIGWAITINFO 1036304 2 /boot/io-pkt-v4-hc 25r RUNNING 1036304 3 /boot/io-pkt-v4-hc 21r RECEIVE 24 1036304 4 /boot/io-pkt-v4-hc 25r MUTEX (0x20b670) 1036304-02 #0 Thanks, Yurong _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post98968 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Fri, 01 Feb 2013 02:01:56 GMT http://community.qnx.com/sf/go/post98973 Sean Boudreau 2013-02-01T02:01:56Z http://community.qnx.com/sf/go/post98929 Can you ping another machine with "ping -s40 ip.address"? If not, please post the output from "pci -v" on your machine with the 8139 controller. On 2013-01-31 7:57 AM, "Fei Su" <community-noreply@qnx.com> wrote: >Thx , I wonder that there are some bugs in the rtl8139 driver. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post98928 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 31 Jan 2013 13:33:52 GMT http://community.qnx.com/sf/go/post98929 Hugh Brown 2013-01-31T13:33:52Z http://community.qnx.com/sf/go/post98928 Thx , I wonder that there are some bugs in the rtl8139 driver. Thu, 31 Jan 2013 12:57:52 GMT http://community.qnx.com/sf/go/post98928 Fei Su 2013-01-31T12:57:52Z http://community.qnx.com/sf/go/post98926 I'll take a look at this. On 2013-01-30 9:57 PM, "Fei Su" <community-noreply@qnx.com> wrote: >Hi , > I'm using bpf to send and receive the EtherCat frame,but there are >something strange than when I send a broadcast ECAT frame and this frame >is less then 60 bytes,I can't receive the frame form the slave, but I add >a command 'nop' to fill the frame size over 60 bytes ,I can receive from >slave. I am using QNX6.5 and the ethernet card rtl8139. And also when I >use rtl8169,there is no problem like this. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post98913 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 31 Jan 2013 12:26:26 GMT http://community.qnx.com/sf/go/post98926 Hugh Brown 2013-01-31T12:26:26Z http://community.qnx.com/sf/go/post98913 Hi , I'm using bpf to send and receive the EtherCat frame,but there are something strange than when I send a broadcast ECAT frame and this frame is less then 60 bytes,I can't receive the frame form the slave, but I add a command 'nop' to fill the frame size over 60 bytes ,I can receive from slave. I am using QNX6.5 and the ethernet card rtl8139. And also when I use rtl8169,there is no problem like this. Thu, 31 Jan 2013 02:57:42 GMT http://community.qnx.com/sf/go/post98913 Fei Su 2013-01-31T02:57:42Z http://community.qnx.com/sf/go/post98867 No problem. On 2013-01-29 11:16 AM, "Adam Barber" <community-noreply@qnx.com> wrote: >I hadn't, but I think that worked! > >Thanks so much, I had tried to slay just io-pkt-v4, not -hc, and thats >what I needed to slay. > >I very much appreciate your help. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post98866 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 29 Jan 2013 16:17:53 GMT http://community.qnx.com/sf/go/post98867 Hugh Brown 2013-01-29T16:17:53Z http://community.qnx.com/sf/go/post98866 I hadn't, but I think that worked! Thanks so much, I had tried to slay just io-pkt-v4, not -hc, and thats what I needed to slay. I very much appreciate your help. Tue, 29 Jan 2013 16:16:44 GMT http://community.qnx.com/sf/go/post98866 Adam Barber 2013-01-29T16:16:44Z http://community.qnx.com/sf/go/post98865 Have you tried 'slay io-pkt-v4 io-pkt-v4-hc' and then re-starting the driver? On 2013-01-29 10:38 AM, "Adam Barber" <community-noreply@qnx.com> wrote: >I am running 6.5.0. > >My guess is that the driver is being loaded somewhere before I'm trying >to, and I don't know where. I may be wrong about this also. > >I haven't tried devnp yet, as it doesn't seem to have a promiscuous >option in the documentation. > >The weird thing is that after I try the devn command, en0 no longer >appears under ifconfig, so somehow calling the driver command is doing >something to remove my ability to see en0. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post98864 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 29 Jan 2013 16:06:58 GMT http://community.qnx.com/sf/go/post98865 Hugh Brown 2013-01-29T16:06:58Z http://community.qnx.com/sf/go/post98864 I am running 6.5.0. My guess is that the driver is being loaded somewhere before I'm trying to, and I don't know where. I may be wrong about this also. I haven't tried devnp yet, as it doesn't seem to have a promiscuous option in the documentation. The weird thing is that after I try the devn command, en0 no longer appears under ifconfig, so somehow calling the driver command is doing something to remove my ability to see en0. Tue, 29 Jan 2013 15:38:57 GMT http://community.qnx.com/sf/go/post98864 Adam Barber 2013-01-29T15:38:57Z http://community.qnx.com/sf/go/post98854 I have tested both devn-speedo.so and devnp-speedo.so under 6.5.0 SP1 and they both accept the promiscuous command line argument. What version of the O/S are you running? On 2013-01-28 6:55 PM, "Adam Barber" <community-noreply@qnx.com> wrote: >I'm using an Intel 82559 ethernet adapter and I want to get it into >promiscuous mode to monitor traffic. > >The adapter has been working for me fine, and I can do things like change >the ip address with commands such as: >ifconfig en0 192.168.1.10 > >Pinging other devices on the network works fine, and directed traffic >works fine. > >However, I've been trying to put the adapter into promiscuous mode, and >it seems that I need to do it when loading the driver. I'm not sure if >there's a boot script somewhere that is doing that already (I haven't >been able to find it) but when I try the command: >io-pkt-v4 -d /lib/dll/devn-speedo.so promiscuous > >and then run ifconfig en0 I get: >"ifconfig: SIOCGIFFLAGS en0: No such device or address" so somehow that >command is destroying my ability to access en0 and I can no longer do >anything on the network. > >I'm pretty lost as to what the problem is here, and I can't seem to find >anyone else who has experienced this issue. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post98844 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 29 Jan 2013 13:35:36 GMT http://community.qnx.com/sf/go/post98854 Hugh Brown 2013-01-29T13:35:36Z http://community.qnx.com/sf/go/post98851 If you want to monitor network traffic, you can use the tcpdump utility, as this will place the adapter in promiscuous mode. I don't know why you are getting the error message when you try to set promiscuous on the command line, so I will take a look at this. I see that you are running devn-speedo.so, but have you tried devnp-speedo.so? On 2013-01-28 6:55 PM, "Adam Barber" <community-noreply@qnx.com> wrote: >I'm using an Intel 82559 ethernet adapter and I want to get it into >promiscuous mode to monitor traffic. > >The adapter has been working for me fine, and I can do things like change >the ip address with commands such as: >ifconfig en0 192.168.1.10 > >Pinging other devices on the network works fine, and directed traffic >works fine. > >However, I've been trying to put the adapter into promiscuous mode, and >it seems that I need to do it when loading the driver. I'm not sure if >there's a boot script somewhere that is doing that already (I haven't >been able to find it) but when I try the command: >io-pkt-v4 -d /lib/dll/devn-speedo.so promiscuous > >and then run ifconfig en0 I get: >"ifconfig: SIOCGIFFLAGS en0: No such device or address" so somehow that >command is destroying my ability to access en0 and I can no longer do >anything on the network. > >I'm pretty lost as to what the problem is here, and I can't seem to find >anyone else who has experienced this issue. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post98844 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 29 Jan 2013 13:12:52 GMT http://community.qnx.com/sf/go/post98851 Hugh Brown 2013-01-29T13:12:52Z http://community.qnx.com/sf/go/post98844 I'm using an Intel 82559 ethernet adapter and I want to get it into promiscuous mode to monitor traffic. The adapter has been working for me fine, and I can do things like change the ip address with commands such as: ifconfig en0 192.168.1.10 Pinging other devices on the network works fine, and directed traffic works fine. However, I've been trying to put the adapter into promiscuous mode, and it seems that I need to do it when loading the driver. I'm not sure if there's a boot script somewhere that is doing that already (I haven't been able to find it) but when I try the command: io-pkt-v4 -d /lib/dll/devn-speedo.so promiscuous and then run ifconfig en0 I get: "ifconfig: SIOCGIFFLAGS en0: No such device or address" so somehow that command is destroying my ability to access en0 and I can no longer do anything on the network. I'm pretty lost as to what the problem is here, and I can't seem to find anyone else who has experienced this issue. Mon, 28 Jan 2013 23:55:18 GMT http://community.qnx.com/sf/go/post98844 Adam Barber 2013-01-28T23:55:18Z http://community.qnx.com/sf/go/post98585 > or was the IRQ 9 disabled for lots > of us ? How I can figure out this???????? > Is the IRQ 2 used ? If yes, you shouldn't use IRQ 9 ... No. I don't use IRQ 2. Tue, 15 Jan 2013 17:50:03 GMT http://community.qnx.com/sf/go/post98585 Oleg Gopov 2013-01-15T17:50:03Z http://community.qnx.com/sf/go/post98574 Oleg Gopov wrote: > Armin, I prepare some sweets))))))) > > Please see to attachment. > > Armin, what you say?????????? Interesting ! Are there any hardware related delays or was the IRQ 9 disabled for lots of us ? Is the IRQ 2 used ? If yes, you shouldn't use IRQ 9 ... --Armin > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98571 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Tue, 15 Jan 2013 15:41:46 GMT http://community.qnx.com/sf/go/post98574 Armin Steinhoff 2013-01-15T15:41:46Z http://community.qnx.com/sf/go/post98571 Armin, I prepare some sweets))))))) Please see to attachment. Armin, what you say?????????? Tue, 15 Jan 2013 15:11:42 GMT http://community.qnx.com/sf/go/post98571 Oleg Gopov 2013-01-15T15:11:42Z http://community.qnx.com/sf/go/post98566 > Do you have a corrupted keyboard ?????????????????????????????? Keyboard work properly. Tue, 15 Jan 2013 12:26:44 GMT http://community.qnx.com/sf/go/post98566 Oleg Gopov 2013-01-15T12:26:44Z http://community.qnx.com/sf/go/post98564 Oleg Gopov wrote: > Hello Armin. Our investigation is continue)))))))))))) > Please, what you say??????? > >> Reasons: an other PCI device blocks the PCI bus or the bus request for >> more than 50us or the PCI slot doesn't support bus mastering ! > Where you take 50us from???????????? Should be specified by the PCI standard. > What is the time?????????????? tineout for requesting as a master the bus. Do you have a corrupted keyboard ?????????????????????????????? > > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98560 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Tue, 15 Jan 2013 11:00:35 GMT http://community.qnx.com/sf/go/post98564 Armin Steinhoff 2013-01-15T11:00:35Z http://community.qnx.com/sf/go/post98560 Hello Armin. Our investigation is continue)))))))))))) Please, what you say??????? > Reasons: an other PCI device blocks the PCI bus or the bus request for > more than 50us or the PCI slot doesn't support bus mastering ! Where you take 50us from???????????? What is the time?????????????? Tue, 15 Jan 2013 03:49:54 GMT http://community.qnx.com/sf/go/post98560 Oleg Gopov 2013-01-15T03:49:54Z http://community.qnx.com/sf/go/post98448 > You know it ? > > http://www.tldp.org/HOWTO/VME-HOWTO.html#toc4 > I already learn this linux driver for vme bridge. I try some things after holidays and write to this topic. Tue, 08 Jan 2013 23:11:59 GMT http://community.qnx.com/sf/go/post98448 Oleg Gopov 2013-01-08T23:11:59Z http://community.qnx.com/sf/go/post98438 > OK. > Could this be helpful? > http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion. > bsp.topc3672?_pagenum=1 One thing I may write that this post is not my case. Our system work for years and we don't have problems with allocating Tundra base address. All more difficult. Only one board (vp7) with only one NIC (amd pcnet32) cause problem as I wrote on the first post. Tue, 08 Jan 2013 14:45:30 GMT http://community.qnx.com/sf/go/post98438 Oleg Gopov 2013-01-08T14:45:30Z http://community.qnx.com/sf/go/post98437 Thanks Armin. I will study info under links you suggest and surely write results to this post. Tue, 08 Jan 2013 14:27:57 GMT http://community.qnx.com/sf/go/post98437 Oleg Gopov 2013-01-08T14:27:57Z http://community.qnx.com/sf/go/post98409 Oleg Gopov wrote: >> Oleg, >> >> I hope you are not using QNX6.5 ... it well known for its esoteric PCI >> problems ! >> > I point in the first post , that I use 6.4.0 version OK. Could this be helpful? http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.bsp.topc3672?_pagenum=1 > > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98402 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Mon, 07 Jan 2013 09:33:42 GMT http://community.qnx.com/sf/go/post98409 Armin Steinhoff 2013-01-07T09:33:42Z http://community.qnx.com/sf/go/post98408 You know it ? http://www.tldp.org/HOWTO/VME-HOWTO.html#toc4 Oleg Gopov wrote: >> ... and the IRQ 7 isn't shared by an other device ? > There is no devices , that shared IRQ 7 >> That means all VME device are trigering the IRQ 11 ? > I think YES. > >> Is it really the pci2vme bridge or is it an other PCI device ?? > Yes. It is realy pci2vme bridge - Tundra Universe II. > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98400 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Mon, 07 Jan 2013 09:13:55 GMT http://community.qnx.com/sf/go/post98408 Armin Steinhoff 2013-01-07T09:13:55Z http://community.qnx.com/sf/go/post98402 > > Oleg, > > I hope you are not using QNX6.5 ... it well known for its esoteric PCI > problems ! > I point in the first post , that I use 6.4.0 version Sun, 06 Jan 2013 13:09:34 GMT http://community.qnx.com/sf/go/post98402 Oleg Gopov 2013-01-06T13:09:34Z http://community.qnx.com/sf/go/post98401 Oleg, I hope you are not using QNX6.5 ... it well known for its esoteric PCI problems ! Oleg Gopov wrote: >> ... and the IRQ 7 isn't shared by an other device ? > There is no devices , that shared IRQ 7 >> That means all VME device are trigering the IRQ 11 ? > I think YES. > >> Is it really the pci2vme bridge or is it an other PCI device ?? > Yes. It is realy pci2vme bridge - Tundra Universe II. > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98400 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Sun, 06 Jan 2013 12:12:27 GMT http://community.qnx.com/sf/go/post98401 Armin Steinhoff 2013-01-06T12:12:27Z http://community.qnx.com/sf/go/post98400 > ... and the IRQ 7 isn't shared by an other device ? There is no devices , that shared IRQ 7 > That means all VME device are trigering the IRQ 11 ? I think YES. > Is it really the pci2vme bridge or is it an other PCI device ?? Yes. It is realy pci2vme bridge - Tundra Universe II. Sun, 06 Jan 2013 02:20:16 GMT http://community.qnx.com/sf/go/post98400 Oleg Gopov 2013-01-06T02:20:16Z http://community.qnx.com/sf/go/post98399 Oleg Gopov wrote: >> Reasons: an other PCI device blocks the PCI bus or the bus request for >> more than 50us or the PCI slot doesn't support bus mastering ! > I want to mention , that BIOS distribute to PCNET NIC -> IRQ 7, ... and the IRQ 7 isn't shared by an other device ? > PCI2VME BRIDGE - IRQ 11. That means all VME device are trigering the IRQ 11 ? > > One moment bothers me, how write/read action to pci2vme bridge cause interrupt generation on my nic driver. I don't understant. Is it really the pci2vme bridge or is it an other PCI device ?? --Armin > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98397 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Sat, 05 Jan 2013 17:15:06 GMT http://community.qnx.com/sf/go/post98399 Armin Steinhoff 2013-01-05T17:15:06Z http://community.qnx.com/sf/go/post98398 Because "pcnet memory error" generate in interrupt handler of pcnet driver. I am right????????? Sat, 05 Jan 2013 15:05:44 GMT http://community.qnx.com/sf/go/post98398 Oleg Gopov 2013-01-05T15:05:44Z http://community.qnx.com/sf/go/post98397 > Reasons: an other PCI device blocks the PCI bus or the bus request for > more than 50us or the PCI slot doesn't support bus mastering ! I want to mention , that BIOS distribute to PCNET NIC -> IRQ 7, PCI2VME BRIDGE - IRQ 11. One moment bothers me, how write/read action to pci2vme bridge cause interrupt generation on my nic driver. I don't understant. Sat, 05 Jan 2013 15:03:23 GMT http://community.qnx.com/sf/go/post98397 Oleg Gopov 2013-01-05T15:03:23Z http://community.qnx.com/sf/go/post98372 > is the bridge "Tundra Iniverse II" fully supported ? No , I wrote myself this driver. Fri, 04 Jan 2013 10:55:52 GMT http://community.qnx.com/sf/go/post98372 Oleg Gopov 2013-01-04T10:55:52Z http://community.qnx.com/sf/go/post98369 Hello Oleg, all the best in 2013 ! is the bridge "Tundra Iniverse II" fully supported ? --Armin Oleg Gopov wrote: > Hello Armin. Happy New Year. Thanks for answers. > > > I locate a problem. My Application work with pci-to-vme bridge Tundra Universe II. > "pcnet memory error" occur when I try read/write to no-exist address on vme bus. (my applicatoin act as pci target) > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98367 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Fri, 04 Jan 2013 08:35:59 GMT http://community.qnx.com/sf/go/post98369 Armin Steinhoff 2013-01-04T08:35:59Z http://community.qnx.com/sf/go/post98367 Hello Armin. Happy New Year. Thanks for answers. I locate a problem. My Application work with pci-to-vme bridge Tundra Universe II. "pcnet memory error" occur when I try read/write to no-exist address on vme bus. (my applicatoin act as pci target) Fri, 04 Jan 2013 01:59:27 GMT http://community.qnx.com/sf/go/post98367 Oleg Gopov 2013-01-04T01:59:27Z http://community.qnx.com/sf/go/post98336 Oleg Gopov wrote: LINUX: if (csr0 & LE_C0_MERR) { printk("%s: *Bus master arbitration failure*, status %4.4x.\n", dev->name, csr0); /* Restart the chip. */ WRITERDP(lp, LE_C0_STRT); } Reasons: an other PCI device blocks the PCI bus or the bus request for more than 50us or the PCI slot doesn't support bus mastering ! > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98334 > To cancel your subscription to this discussion, please e-maildrivers-networking-unsubscribe@community.qnx.com > Mon, 31 Dec 2012 11:33:55 GMT http://community.qnx.com/sf/go/post98336 Armin Steinhoff 2012-12-31T11:33:55Z http://community.qnx.com/sf/go/post98335 Oleg Gopov wrote: > I find excerpt of pcnet driver > > /* > * pcn_intr: > * > * Interrupt service routine. > */ > static int > pcn_intr(void *arg) > { > struct pcn_softc *sc = arg; > struct ifnet *ifp = &sc->sc_ethercom.ec_if; > uint32_t csr0; > int wantinit, handled = 0; > > for (wantinit = 0; wantinit == 0;) { > csr0 = pcn_csr_read(sc, LE_CSR0); > if ((csr0 & LE_C0_INTR) == 0) > break; > > #if NRND > 0 > if (RND_ENABLED(&sc->rnd_source)) > rnd_add_uint32(&sc->rnd_source, csr0); > #endif > > /* ACK the bits and re-enable interrupts. */ > pcn_csr_write(sc, LE_CSR0, csr0 & > (LE_C0_INEA|LE_C0_BABL|LE_C0_MISS|LE_C0_MERR|LE_C0_RINT| > LE_C0_TINT|LE_C0_IDON)); > > handled = 1; > > if (csr0 & LE_C0_RINT) { > PCN_EVCNT_INCR(&sc->sc_ev_rxintr); > wantinit = pcn_rxintr(sc); > } > > if (csr0 & LE_C0_TINT) { > PCN_EVCNT_INCR(&sc->sc_ev_txintr); > pcn_txintr(sc); > } > > if (csr0 & LE_C0_ERR) { > if (csr0 & LE_C0_BABL) { > PCN_EVCNT_INCR(&sc->sc_ev_babl); > ifp->if_oerrors++; > } > if (csr0 & LE_C0_MISS) { > PCN_EVCNT_INCR(&sc->sc_ev_miss); > ifp->if_ierrors++; > } > if (csr0 & LE_C0_MERR) { > PCN_EVCNT_INCR(&sc->sc_ev_merr); > printf("%s: memory error\n", > sc->sc_dev.dv_xname); > wantinit = 1; > break; > } > } > > if ((csr0 & LE_C0_RXON) == 0) { > printf("%s: receiver disabled\n", > sc->sc_dev.dv_xname); > ifp->if_ierrors++; > wantinit = 1; > } > > if ((csr0 & LE_C0_TXON) == 0) { > printf("%s: transmitter disabled\n", > sc->sc_dev.dv_xname); > ifp->if_oerrors++; > wantinit = 1; > } > } > > if (handled) { > if (wantinit) > pcn_init(ifp); > > /* Try to get more packets going. */ > #ifdef __QNXNTO__ > NW_SIGLOCK(&ifp->if_snd_ex, iopkt_selfp); > #endif > pcn_start(ifp); > } > > return (handled); > } > > > > > ******************************************************* > There is place in driver when "pcnet memory error" occur > > if (csr0 & LE_C0_MERR) { > PCN_EVCNT_INCR(&sc->sc_ev_merr); > printf("%s: memory error\n", > sc->sc_dev.dv_xname); > wantinit = 1; > break; > } > LINUX: if (csr0 & LE_C0_MERR) { printk("%s: *Bus master arbitration failure*, status %4.4x.\n", dev->name, csr0); /* Restart the chip. */ WRITERDP(lp, LE_C0_STRT); } > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98334 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Mon, 31 Dec 2012 11:12:00 GMT http://community.qnx.com/sf/go/post98335 Armin Steinhoff 2012-12-31T11:12:00Z http://community.qnx.com/sf/go/post98334 I find excerpt of pcnet driver /* * pcn_intr: * * Interrupt service routine. */ static int pcn_intr(void *arg) { struct pcn_softc *sc = arg; struct ifnet *ifp = &sc->sc_ethercom.ec_if; uint32_t csr0; int wantinit, handled = 0; for (wantinit = 0; wantinit == 0;) { csr0 = pcn_csr_read(sc, LE_CSR0); if ((csr0 & LE_C0_INTR) == 0) break; #if NRND > 0 if (RND_ENABLED(&sc->rnd_source)) rnd_add_uint32(&sc->rnd_source, csr0); #endif /* ACK the bits and re-enable interrupts. */ pcn_csr_write(sc, LE_CSR0, csr0 & (LE_C0_INEA|LE_C0_BABL|LE_C0_MISS|LE_C0_MERR|LE_C0_RINT| LE_C0_TINT|LE_C0_IDON)); handled = 1; if (csr0 & LE_C0_RINT) { PCN_EVCNT_INCR(&sc->sc_ev_rxintr); wantinit = pcn_rxintr(sc); } if (csr0 & LE_C0_TINT) { PCN_EVCNT_INCR(&sc->sc_ev_txintr); pcn_txintr(sc); } if (csr0 & LE_C0_ERR) { if (csr0 & LE_C0_BABL) { PCN_EVCNT_INCR(&sc->sc_ev_babl); ifp->if_oerrors++; } if (csr0 & LE_C0_MISS) { PCN_EVCNT_INCR(&sc->sc_ev_miss); ifp->if_ierrors++; } if (csr0 & LE_C0_MERR) { PCN_EVCNT_INCR(&sc->sc_ev_merr); printf("%s: memory error\n", sc->sc_dev.dv_xname); wantinit = 1; break; } } if ((csr0 & LE_C0_RXON) == 0) { printf("%s: receiver disabled\n", sc->sc_dev.dv_xname); ifp->if_ierrors++; wantinit = 1; } if ((csr0 & LE_C0_TXON) == 0) { printf("%s: transmitter disabled\n", sc->sc_dev.dv_xname); ifp->if_oerrors++; wantinit = 1; } } if (handled) { if (wantinit) pcn_init(ifp); /* Try to get more packets going. */ #ifdef __QNXNTO__ NW_SIGLOCK(&ifp->if_snd_ex, iopkt_selfp); #endif pcn_start(ifp); } return (handled); } ******************************************************* There is place in driver when "pcnet memory error" occur if (csr0 & LE_C0_MERR) { PCN_EVCNT_INCR(&sc->sc_ev_merr); printf("%s: memory error\n", sc->sc_dev.dv_xname); wantinit = 1; break; } Mon, 31 Dec 2012 03:56:59 GMT http://community.qnx.com/sf/go/post98334 Oleg Gopov 2012-12-31T03:56:59Z http://community.qnx.com/sf/go/post98321 Hello Armin. I use native OS. There is neither host OS nor guest OS. I try to "slay io-usb", there is no effect. Wed, 26 Dec 2012 14:19:24 GMT http://community.qnx.com/sf/go/post98321 Oleg Gopov 2012-12-26T14:19:24Z http://community.qnx.com/sf/go/post98320 Oleg Gopov wrote: >> IRQ >> >> 0: IO-APIC-*edge* timer >> 1: IO-APIC-*edge* i8042 > Hello Armin. Please say, where you get this. In /proc ????????? These are the interrupts of my host OS (Suse 12.1/ 32bit) mapped to the interrupts of QNX 6.5) (-> *virtualized version* 6.5SP1 as provided by QSS !! What *host OS* are you using ? Could it be that the UDP packets are lost by the host OS ? ( Windows ?) Are you using NAT or bridging with your guest OS (QNX) ? Here are my results after a ftp transfer from the host to the guest: # nicinfo en0: *AMD PCNET-32 Ethernet Controller* Physical Node ID ........................... 000C29 794934 Current Physical Node ID ................... 000C29 794934 Current Operation Rate ..................... 10.00 Mb/s Active Interface Type ...................... UTP Maximum Transmittable data Unit ............ 1514 Maximum Receivable data Unit ............... 1514 Hardware Interrupt ......................... 0xa I/O Aperture ............................... 0x2000 - 0x207f Memory Aperture ............................ 0x0 Promiscuous Mode ........................... Off Multicast Support .......................... Enabled Packets Transmitted OK ..................... 99 Bytes Transmitted OK ....................... 8003 Memory Allocation Failures on Transmit ..... 0 Packets Received OK ........................ 603 Bytes Received OK .......................... 251077 Memory Allocation Failures on Receive ...... 0 Single Collisions on Transmit .............. 0 Deferred Transmits ......................... 0 Late Collision on Transmit errors .......... 0 Transmits aborted (excessive collisions) ... 0 Transmit Underruns ......................... 0 No Carrier on Transmit ..................... 0 Receive Alignment errors ................... 0 Received packets with CRC errors ........... 0 Packets Dropped on receive ................. 0 No errors at all ... Wed, 26 Dec 2012 13:07:30 GMT http://community.qnx.com/sf/go/post98320 Armin Steinhoff 2012-12-26T13:07:30Z http://community.qnx.com/sf/go/post98318 > IRQ > > 0: IO-APIC-*edge* timer > 1: IO-APIC-*edge* i8042 Hello Armin. Please say, where you get this. In /proc ????????? Wed, 26 Dec 2012 01:45:57 GMT http://community.qnx.com/sf/go/post98318 Oleg Gopov 2012-12-26T01:45:57Z http://community.qnx.com/sf/go/post98314 Oleg Gopov wrote: >> Seems so that io-usb is using InterruptAttachEvent ?? > As you remember, USB subsystem is not interrupt-driven. Poll engine is the base of USB. AFAIK ... every UHCI controller works interrupt based! > Io-usb simply wake up every 100 ms (as say tracebuffer.kev) and all. And I have no usb devices inserted to my computer. >> Is your Ethernet board broken ???????????? > Yes of course. "Pcnet memory error" message just overload (3 times in second) my slog. Therefore I lost packets. > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98312 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Mon, 24 Dec 2012 15:07:39 GMT http://community.qnx.com/sf/go/post98314 Armin Steinhoff 2012-12-24T15:07:39Z http://community.qnx.com/sf/go/post98312 > Seems so that io-usb is using InterruptAttachEvent ?? As you remember, USB subsystem is not interrupt-driven. Poll engine is the base of USB. Io-usb simply wake up every 100 ms (as say tracebuffer.kev) and all. And I have no usb devices inserted to my computer. > Is your Ethernet board broken ???????????? Yes of course. "Pcnet memory error" message just overload (3 times in second) my slog. Therefore I lost packets. Mon, 24 Dec 2012 03:46:25 GMT http://community.qnx.com/sf/go/post98312 Oleg Gopov 2012-12-24T03:46:25Z http://community.qnx.com/sf/go/post98311 Oleg Gopov wrote: > Armin, What is IRQ that shared???? I don't understand. In tracelog that you present I see that trigger IRQ 0 ( timer ) and scheduler change state of io-usb to RUNNING. Seems so that io-usb is using InterruptAttachEvent ?? > And all. IRQ 0: IO-APIC-*edge* timer 1: IO-APIC-*edge* i8042 Only these interupts are active in your kernel trace ... I don't see any real PCI interrupts! Is your Ethernet board broken ???????????? One of the shared interrupts is just the IRQ 0 .... > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98310 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Sun, 23 Dec 2012 16:31:03 GMT http://community.qnx.com/sf/go/post98311 Armin Steinhoff 2012-12-23T16:31:03Z http://community.qnx.com/sf/go/post98310 Armin, What is IRQ that shared???? I don't understand. In tracelog that you present I see that trigger IRQ 0 ( timer ) and scheduler change state of io-usb to RUNNING. And all. Sun, 23 Dec 2012 14:45:41 GMT http://community.qnx.com/sf/go/post98310 Oleg Gopov 2012-12-23T14:45:41Z http://community.qnx.com/sf/go/post98309 Oleg Gopov wrote: >> Using the CPU has nothing to with a false handling of the interrupt !!!! >> A disabled interrupt remains disabled if you use the CPU ot not ... >> >> Yes, USB is not very active in your case ... but what about the error >> messages related to the hardware of ethernet board ???? >> Isn't it criminal ?? > Ok. Then, How you conclude that io-usb share interrupt with network driver????????? t:0xe875a9f0 CPU:00 INT_ENTR:0x00000000 (0) IP:0xf007dbd6 t:0xe875ab69 CPU:00 INT_HANDLER_ENTR:0x00000000 (0) pkt-mgr IP:0x080b7a34 AREA:0x0812baa0 t:0xe875af0f CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE t:0xe875b1b2 CPU:00 INT_HANDLER_ENTR:0x00000000 (0) PID:1 IP:0xf0052620 AREA:0x00000000 t:0xe875b545 CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE t:0xe875b82e CPU:00 INT_EXIT:0x00000000 (0) inkernel:0x00000001 t:0xe87d4ed9 CPU:00 INT_ENTR:0x00000000 (0) IP:0xf007dbd6 t:0xe87d4ff7 CPU:00 INT_HANDLER_ENTR:0x00000000 (0) pkt-mgr IP:0x080b7a34 AREA:0x0812baa0 t:0xe87d52e5 CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE t:0xe87d5527 CPU:00 INT_HANDLER_ENTR:0x00000000 (0) PID:1 IP:0xf0052620 AREA:0x00000000 t:0xe87d597e CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE t:0xe87d5c2d CPU:00 INT_EXIT:0x00000000 (0) inkernel:0x00000001 t:0xe87d6313 CPU:00 THREAD :THRUNNING io-usb tid:5 t:0xe87d6468 CPU:00 THREAD :THREADY pid:1 tid:1 t:0xe87d8885 CPU:00 KER_CALL:TIMER_TIMEOUT/75 timeout_flags:0x00001000 ntime(sec):0 t:0xe87d8b05 CPU:00 THREAD :THNANOSLEEP io-usb tid:5 t:0xe87d8e4b CPU:00 THREAD :THRUNNING pid:1 tid:1 t:0xe884f46d CPU:00 INT_ENTR:0x00000000 (0) IP:0xf007dbd6 t:0xe884f5e3 CPU:00 INT_HANDLER_ENTR:0x00000000 (0) pkt-mgr IP:0x080b7a34 AREA:0x0812baa0 t:0xe884f90c CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE t:0xe884fb6c CPU:00 INT_HANDLER_ENTR:0x00000000 (0) PID:1 IP:0xf0052620 AREA:0x00000000 t:0xe8850138 CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE t:0xe8850419 CPU:00 INT_EXIT:0x00000000 (0) inkernel:0x00000001 > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98307 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Sun, 23 Dec 2012 14:05:50 GMT http://community.qnx.com/sf/go/post98309 Armin Steinhoff 2012-12-23T14:05:50Z http://community.qnx.com/sf/go/post98308 Oleg Gopov wrote: >> You have a corrupted board sharing the same IRQ with io-usb -> that's >> the best wayto loose interrupts. >> io-usb is known for blocking/disabling its (shared) interrupt for a >> longer time ! >> >> --Armin >> > But, Armin. How You conclude this??? You find out issue in tracebuffer.kev file?????????? Yes ... you can see that io-usb is sharing the same interrupt ... that means in all cases of an active interrupt is the ISR of io-usb active!!!! > I analyze tracelog and see that io-usb thread eat processor time only ~ 30us. Nothing criminal in that. Handling - that means disabling/enabling - of interrupts are normally done in the ISR! Should be critical enough .... even if there is no data traffic. --Armin > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98305 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Sun, 23 Dec 2012 13:22:53 GMT http://community.qnx.com/sf/go/post98308 Armin Steinhoff 2012-12-23T13:22:53Z http://community.qnx.com/sf/go/post98307 > Using the CPU has nothing to with a false handling of the interrupt !!!! > A disabled interrupt remains disabled if you use the CPU ot not ... > > Yes, USB is not very active in your case ... but what about the error > messages related to the hardware of ethernet board ???? > Isn't it criminal ?? Ok. Then, How you conclude that io-usb share interrupt with network driver????????? Sun, 23 Dec 2012 11:47:57 GMT http://community.qnx.com/sf/go/post98307 Oleg Gopov 2012-12-23T11:47:57Z http://community.qnx.com/sf/go/post98306 Oleg Gopov wrote: >> You have a corrupted board sharing the same IRQ with io-usb -> that's >> the best wayto loose interrupts. >> io-usb is known for blocking/disabling its (shared) interrupt for a >> longer time ! >> >> --Armin >> > But, Armin. How You conclude this??? You find out issue in tracebuffer.kev file?????????? > I analyze tracelog and see that io-usb thread eat processor time only ~ 30us. Using the CPU has nothing to with a false handling of the interrupt !!!! A disabled interrupt remains disabled if you use the CPU ot not ... Yes, USB is not very active in your case ... but what about the error messages related to the hardware of ethernet board ???? Isn't it criminal ?? > Nothing criminal in that. > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98305 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Sun, 23 Dec 2012 09:41:46 GMT http://community.qnx.com/sf/go/post98306 Armin Steinhoff 2012-12-23T09:41:46Z http://community.qnx.com/sf/go/post98305 > You have a corrupted board sharing the same IRQ with io-usb -> that's > the best wayto loose interrupts. > io-usb is known for blocking/disabling its (shared) interrupt for a > longer time ! > > --Armin > But, Armin. How You conclude this??? You find out issue in tracebuffer.kev file?????????? I analyze tracelog and see that io-usb thread eat processor time only ~ 30us. Nothing criminal in that. Sun, 23 Dec 2012 03:42:00 GMT http://community.qnx.com/sf/go/post98305 Oleg Gopov 2012-12-23T03:42:00Z http://community.qnx.com/sf/go/post98304 Lichun Zhu wrote: > Where do you get the information that io-usb disable interrupt for long time(how long), as far as I remember there was some host controller driver making lots delay, but that only on initalization. We have seen it in the context of an active io-usb ... there was the shared interrupt disabled for round about 8ms (visible in a kernel trace) Also other (professional) customers did reporting it ! --Armin > Sent from BlackBerry > > ----- Original Message ----- > From: Armin Steinhoff [mailto:community-noreply@qnx.com] > Sent: Friday, December 21, 2012 05:03 PM > To: drivers-networking@community.qnx.com <drivers-networking@community.qnx.com> > Cc: Info System - IS Automated Notifications; Info System - IS Automated Notifications > Subject: Re: Two instances of io-pkt interfering with each other > > Mark Dowdy wrote: >> Ah, forgot to mention that. We are running 6.5.0 SP1. We can't move back to 6.4.1 because we have a new multicore machine that we're about to deploy and the NIC in that machine (Intel 82576, device id 10c9h) isn't supported in 6.4.1. > OK ... be careful if you use APIC/MSI. > An other critical point is the PCI interrupt if it is shared with io-usb > ... the resource manager of io-usb seems to disable/block that shared > interrupt for a longer time. > > --Armin > >> We're using the devnp-e1000 driver from SP1 (see below), I'll try the driver Dennis referenced to see if it makes any difference. >> >> # use -i /lib/dll/devnp-e1000.so >> NAME=devnp-e1000.so >> DESCRIPTION=Driver for Intel 82544 Gigabit Ethernet controllers >> DATE=2012/06/20-13:37:46-EDT >> STATE=stable >> HOST=gusbuild4 >> USER=builder >> VERSION=6.5.0 >> TAGID=650SP1-166 >> >> Thanks. >> >> Mark >> >> >> >> _______________________________________________ >> >> Networking Drivers >> http://community.qnx.com/sf/go/post98293 >> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com >> > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98295 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98296 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Sat, 22 Dec 2012 10:11:36 GMT http://community.qnx.com/sf/go/post98304 Armin Steinhoff 2012-12-22T10:11:36Z http://community.qnx.com/sf/go/post98303 Oleg Gopov wrote: > Ok, Armin. I will try to "slay io-usb" or disable usb from bios. I will write results to this post. Yes, this would be very interesting ! --Armin > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98301 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Sat, 22 Dec 2012 10:07:09 GMT http://community.qnx.com/sf/go/post98303 Armin Steinhoff 2012-12-22T10:07:09Z http://community.qnx.com/sf/go/post98301 Ok, Armin. I will try to "slay io-usb" or disable usb from bios. I will write results to this post. Sat, 22 Dec 2012 03:13:50 GMT http://community.qnx.com/sf/go/post98301 Oleg Gopov 2012-12-22T03:13:50Z http://community.qnx.com/sf/go/post98300 They're real cores, none of that hyperthreading nonsense that Intel tried to pass off as multicore. # pidin info CPU:X86 Release:6.5.0 FreeMem:838Mb/1023Mb BootTime:Dec 19 09:45:50 PST 2012 Processes: 51, Threads: 106 Processor1: 66222 Core 2 Extreme/Xeon Stepping 10 2835MHz FPU Processor2: 66222 Core 2 Extreme/Xeon Stepping 10 2834MHz FPU Processor3: 66222 Core 2 Extreme/Xeon Stepping 10 2835MHz FPU Processor4: 66222 Core 2 Extreme/Xeon Stepping 10 2835MHz FPU Fri, 21 Dec 2012 23:43:53 GMT http://community.qnx.com/sf/go/post98300 Mark Dowdy 2012-12-21T23:43:53Z http://community.qnx.com/sf/go/post98299 Are they real core or 1 core plus hyperthreading ? > -----Message d'origine----- > De : Mark Dowdy [mailto:community-noreply@qnx.com] > Envoyé : 21 décembre 2012 15:17 > À : drivers-networking@community.qnx.com > Objet : Two instances of io-pkt interfering with each other > > First some background. We're running two instances of io-pkt in our system, > one for 'normal' network traffic (i.e. TCP/IP, UDP/IP, management, Qnet, > Photon (that's another story), etc.) and a second for time critical traffic (data > extracted/injected via BPF, no IP address configured, Qnet not started on this > interface). These are x86 machines, one multicore and 2 or 3 single core. On > the multicore machine, we're using the devnp-e1000 driver on both interfaces > (NIC device ID 1096h); on the single core machines we're running the devnp- > speedo driver on the 'normal' network (NIC device ID 1209h) and the devnp- > e1000 driver on the time critical network (NIC device ID 1076h). Time critical > system control traffic is sent using the second io-pkt instance every ms. > > Using an internally developed traffic test program, we observe time critical > data flowing from a single core machine to the multicore machine and then > from the multicore machine back to the single core with a best case round trip > time of ~290 µsec. In some cases, however, this round trip time increases to > ~450 µsec. You may be asking "what's 160 µsec between friends?" but we use > this time critical channel for motor control data and when we use our full > system (multiple single core machines sending data with our full motor control > algorithms and other system functions), the problem magnifies to the point that > we see traffic that doesn't make it back before the next cycle starts 1 ms later. > > So, we took to looking at what was going on using the System Profiler (i.e. > kernel trace) and observed that traffic on the time critical network (2nd io-pkt > instance) slowed down when there was action on the management network (1st > io-pkt instance). That was unexpected since the reason we started two > instances of io-pkt was to avoid exactly that scenario, regular traffic negatively > impacting time critical traffic. The second io-pkt instance is started with higher > priority (see below). The kernel trace only gives us exposure to task activity, not > NIC driver execution, so it's hard to say when network data actually "hits the > wire". What could be going on in io-pkt that could be causing this type of > adverse interaction? On the single core machine, it looks like the first io-pkt > instance is running and delaying the driver from putting data on the wire. With > two instances of io-pkt using devnp-e1000 on the multicore machine, could the > shared driver object be 'binding' the two io-pkt instances and altering > performance? > > Thanks. > > First io-pkt instance start-up (i.e. 'normal' network on multicore machine) io- > pkt-v4-hc -ptcpip mount -Tio-pkt -opci=0,vid=0x8086,did=0x1096 /lib/dll/devnp- > e1000.so > > Second io-pkt instance start-up (i.e. time critical network on multicore > machine) io-pkt-v4-hc -i1 -ptcpip prefix=/alt mount -Tio-pkt1 - > opci=1,vid=0x8086,did=0x1096,priority=32,receive=512,transmit=4096 > /lib/dll/devnp-e1000.so > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98289 > To cancel your subscription to this discussion, please e-mail drivers-networking- > unsubscribe@community.qnx.com Fri, 21 Dec 2012 23:29:34 GMT http://community.qnx.com/sf/go/post98299 Mario Charest 2012-12-21T23:29:34Z http://community.qnx.com/sf/go/post98298 There are some shared interrupts but not with io-usb. # pci PCI version = 3.00 Class = Mass Storage (IDE) Vendor ID = 8086h, Intel Corporation Device ID = 2680h, 631xESB/632xESB/3100 Chipset SATA IDE Controller PCI index = 0h BAR - 0 [I/O] = 0h enabled BAR - 1 [I/O] = 0h enabled BAR - 2 [I/O] = 0h enabled BAR - 3 [I/O] = 0h enabled BAR - 4 [I/O] = 1870h enabled PCI Int Pin = INT B Interrupt line = no connection Class = Network (Ethernet) Vendor ID = 8086h, Intel Corporation Device ID = 1096h, 80003ES2LAN Gigabit Ethernet Controller (Copper) PCI index = 0h BAR - 0 [Mem] = d8020000h enabled BAR - 1 [Mem] = d8000000h enabled BAR - 2 [I/O] = 2000h enabled PCI Expansion ROM = 0h disabled PCI Int Pin = INT A Interrupt line = 11 CPU Interrupt = bh Class = Network (Ethernet) Vendor ID = 8086h, Intel Corporation Device ID = 1096h, 80003ES2LAN Gigabit Ethernet Controller (Copper) PCI index = 1h BAR - 0 [Mem] = d8060000h enabled BAR - 1 [Mem] = d8040000h enabled BAR - 2 [I/O] = 2020h enabled PCI Expansion ROM = 0h disabled PCI Int Pin = INT B Interrupt line = 10 CPU Interrupt = ah Class = Display (VGA) Vendor ID = 1002h, ATI Technologies Inc Device ID = 515eh, ES1000 PCI index = 0h BAR - 0 [Mem] = d0000000h enabled BAR - 1 [I/O] = 3000h enabled BAR - 2 [Mem] = d8200000h enabled PCI Expansion ROM = 0h disabled PCI Int Pin = INT A Interrupt line = 11 CPU Interrupt = bh Fri, 21 Dec 2012 23:04:48 GMT http://community.qnx.com/sf/go/post98298 Mark Dowdy 2012-12-21T23:04:48Z http://community.qnx.com/sf/go/post98297 When the timer interrupt fires, io-pkt is not scheduled. From the kernel trace: Interrupt 0x0, Entry, who procnto-instr - CPU 1 idle interrupt 0x0 ip 0xf00879ae Interrupt 0x0 Process 1, Handler Entry, pid 1 interrupt 0x0 ip 0xf005a430 area 0x0 process procnto-instr Interrupt 0x0 Process 1, Handler Exit, interrupt 0x0 sigev_notify 0 Interrupt 0x0, Exit, interrupt 0x0 flags 0x81 <no Sigevent like other interrupts> Yes, we use "priority=32" when mounting the e1000 driver on the second stack. This is reflected in the priority labels in the kernel trace (we ran wide mode to verify thread priorities). Mark Fri, 21 Dec 2012 23:01:25 GMT http://community.qnx.com/sf/go/post98297 Mark Dowdy 2012-12-21T23:01:25Z http://community.qnx.com/sf/go/post98296 Where do you get the information that io-usb disable interrupt for long time(how long), as far as I remember there was some host controller driver making lots delay, but that only on initalization. Sent from BlackBerry ----- Original Message ----- From: Armin Steinhoff [mailto:community-noreply@qnx.com] Sent: Friday, December 21, 2012 05:03 PM To: drivers-networking@community.qnx.com <drivers-networking@community.qnx.com> Cc: Info System - IS Automated Notifications; Info System - IS Automated Notifications Subject: Re: Two instances of io-pkt interfering with each other Mark Dowdy wrote: > Ah, forgot to mention that. We are running 6.5.0 SP1. We can't move back to 6.4.1 because we have a new multicore machine that we're about to deploy and the NIC in that machine (Intel 82576, device id 10c9h) isn't supported in 6.4.1. OK ... be careful if you use APIC/MSI. An other critical point is the PCI interrupt if it is shared with io-usb ... the resource manager of io-usb seems to disable/block that shared interrupt for a longer time. --Armin > > We're using the devnp-e1000 driver from SP1 (see below), I'll try the driver Dennis referenced to see if it makes any difference. > > # use -i /lib/dll/devnp-e1000.so > NAME=devnp-e1000.so > DESCRIPTION=Driver for Intel 82544 Gigabit Ethernet controllers > DATE=2012/06/20-13:37:46-EDT > STATE=stable > HOST=gusbuild4 > USER=builder > VERSION=6.5.0 > TAGID=650SP1-166 > > Thanks. > > Mark > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98293 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post98295 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Fri, 21 Dec 2012 22:08:13 GMT http://community.qnx.com/sf/go/post98296 Lichun Zhu 2012-12-21T22:08:13Z http://community.qnx.com/sf/go/post98295 Mark Dowdy wrote: > Ah, forgot to mention that. We are running 6.5.0 SP1. We can't move back to 6.4.1 because we have a new multicore machine that we're about to deploy and the NIC in that machine (Intel 82576, device id 10c9h) isn't supported in 6.4.1. OK ... be careful if you use APIC/MSI. An other critical point is the PCI interrupt if it is shared with io-usb ... the resource manager of io-usb seems to disable/block that shared interrupt for a longer time. --Armin > > We're using the devnp-e1000 driver from SP1 (see below), I'll try the driver Dennis referenced to see if it makes any difference. > > # use -i /lib/dll/devnp-e1000.so > NAME=devnp-e1000.so > DESCRIPTION=Driver for Intel 82544 Gigabit Ethernet controllers > DATE=2012/06/20-13:37:46-EDT > STATE=stable > HOST=gusbuild4 > USER=builder > VERSION=6.5.0 > TAGID=650SP1-166 > > Thanks. > > Mark > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98293 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Fri, 21 Dec 2012 22:04:48 GMT http://community.qnx.com/sf/go/post98295 Armin Steinhoff 2012-12-21T22:04:48Z http://community.qnx.com/sf/go/post98294 Mark- You an look at at a system trace and make sure io-pkt has not InterruptAttach() to the system timer. (Sounds like you already have this change.) Hopefully, no other shared interrupts. I assume you are already raising the priority of your critical stack higher than the non-critical? Fri, 21 Dec 2012 22:00:13 GMT http://community.qnx.com/sf/go/post98294 Dennis Kellly 2012-12-21T22:00:13Z http://community.qnx.com/sf/go/post98293 Ah, forgot to mention that. We are running 6.5.0 SP1. We can't move back to 6.4.1 because we have a new multicore machine that we're about to deploy and the NIC in that machine (Intel 82576, device id 10c9h) isn't supported in 6.4.1. We're using the devnp-e1000 driver from SP1 (see below), I'll try the driver Dennis referenced to see if it makes any difference. # use -i /lib/dll/devnp-e1000.so NAME=devnp-e1000.so DESCRIPTION=Driver for Intel 82544 Gigabit Ethernet controllers DATE=2012/06/20-13:37:46-EDT STATE=stable HOST=gusbuild4 USER=builder VERSION=6.5.0 TAGID=650SP1-166 Thanks. Mark Fri, 21 Dec 2012 21:55:50 GMT http://community.qnx.com/sf/go/post98293 Mark Dowdy 2012-12-21T21:55:50Z http://community.qnx.com/sf/go/post98292 >>>Did change SP1 anything with the e-1000 driver ? Not that I am aware of. The latest e1000 driver is on this page: http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/ExperimentalDriversAndUtilities Apparently the io-pkt patch I referenced is already rolled up in SP1. Fri, 21 Dec 2012 21:13:47 GMT http://community.qnx.com/sf/go/post98292 Dennis Kellly 2012-12-21T21:13:47Z http://community.qnx.com/sf/go/post98291 Dennis Kellly wrote: > Are you using this patch? > > http://www.qnx.com/download/feature.html?programid=23666 Did change SP1 anything with the e-1000 driver ? I would bypassing io-pkt and devn-e1000 with a specialized resource manager w/o dependency to the QSS network implementation. Regarding to the negative experiences with the PCI support of QNX 6.5 it's recommended to go back to QNX 6.4.1. Regards --Armin > > Without it, the timer interrupt would be attached to both stacks - this may be somehow serializing the processing for the two stacks? > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post98290 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Fri, 21 Dec 2012 21:01:29 GMT http://community.qnx.com/sf/go/post98291 Armin Steinhoff 2012-12-21T21:01:29Z http://community.qnx.com/sf/go/post98290 Are you using this patch? http://www.qnx.com/download/feature.html?programid=23666 Without it, the timer interrupt would be attached to both stacks - this may be somehow serializing the processing for the two stacks? Fri, 21 Dec 2012 20:25:54 GMT http://community.qnx.com/sf/go/post98290 Dennis Kellly 2012-12-21T20:25:54Z http://community.qnx.com/sf/go/post98289 First some background. We're running two instances of io-pkt in our system, one for 'normal' network traffic (i.e. TCP/IP, UDP/IP, management, Qnet, Photon (that's another story), etc.) and a second for time critical traffic (data extracted/injected via BPF, no IP address configured, Qnet not started on this interface). These are x86 machines, one multicore and 2 or 3 single core. On the multicore machine, we're using the devnp-e1000 driver on both interfaces (NIC device ID 1096h); on the single core machines we're running the devnp-speedo driver on the 'normal' network (NIC device ID 1209h) and the devnp-e1000 driver on the time critical network (NIC device ID 1076h). Time critical system control traffic is sent using the second io-pkt instance every ms. Using an internally developed traffic test program, we observe time critical data flowing from a single core machine to the multicore machine and then from the multicore machine back to the single core with a best case round trip time of ~290 µsec. In some cases, however, this round trip time increases to ~450 µsec. You may be asking "what's 160 µsec between friends?" but we use this time critical channel for motor control data and when we use our full system (multiple single core machines sending data with our full motor control algorithms and other system functions), the problem magnifies to the point that we see traffic that doesn't make it back before the next cycle starts 1 ms later. So, we took to looking at what was going on using the System Profiler (i.e. kernel trace) and observed that traffic on the time critical network (2nd io-pkt instance) slowed down when there was action on the management network (1st io-pkt instance). That was unexpected since the reason we started two instances of io-pkt was to avoid exactly that scenario, regular traffic negatively impacting time critical traffic. The second io-pkt instance is started with higher priority (see below). The kernel trace only gives us exposure to task activity, not NIC driver execution, so it's hard to say when network data actually "hits the wire". What could be going on in io-pkt that could be causing this type of adverse interaction? On the single core machine, it looks like the first io-pkt instance is running and delaying the driver from putting data on the wire. With two instances of io-pkt using devnp-e1000 on the multicore machine, could the shared driver object be 'binding' the two io-pkt instances and altering performance? Thanks. First io-pkt instance start-up (i.e. 'normal' network on multicore machine) io-pkt-v4-hc -ptcpip mount -Tio-pkt -opci=0,vid=0x8086,did=0x1096 /lib/dll/devnp-e1000.so Second io-pkt instance start-up (i.e. time critical network on multicore machine) io-pkt-v4-hc -i1 -ptcpip prefix=/alt mount -Tio-pkt1 -opci=1,vid=0x8086,did=0x1096,priority=32,receive=512,transmit=4096 /lib/dll/devnp-e1000.so Fri, 21 Dec 2012 20:19:33 GMT http://community.qnx.com/sf/go/post98289 Mark Dowdy 2012-12-21T20:19:33Z http://community.qnx.com/sf/go/post98284 Oleg Gopov wrote: > I had write kernel log. I attach tracebuffer.kev file. > > I noticed another feature. If I invoke "sloginfo -w -c" then I have three times in second > message -> "pcnet memory error" You have a corrupted board sharing the same IRQ with io-usb -> that's the best wayto loose interrupts. io-usb is known for blocking/disabling its (shared) interrupt for a longer time ! --Armin Fri, 21 Dec 2012 17:24:49 GMT http://community.qnx.com/sf/go/post98284 Armin Steinhoff 2012-12-21T17:24:49Z http://community.qnx.com/sf/go/post98282 Dear All, Could you please let me know if there is a driver for the product which can be seen from below link; http://www.mikroe.com/click/wifi-plus/ I am looking forward to your quick response. Best regards, Fri, 21 Dec 2012 15:21:35 GMT http://community.qnx.com/sf/go/post98282 Seyfettin Sünger 2012-12-21T15:21:35Z http://community.qnx.com/sf/go/post98237 I invoke "top" command and see that 28M of memory are available. Wed, 19 Dec 2012 17:23:36 GMT http://community.qnx.com/sf/go/post98237 Oleg Gopov 2012-12-19T17:23:36Z http://community.qnx.com/sf/go/post98236 Maybe someone have pcnet32 network adapter sources. What is the case when "pcnet memory error" message generated?????? Wed, 19 Dec 2012 17:19:45 GMT http://community.qnx.com/sf/go/post98236 Oleg Gopov 2012-12-19T17:19:45Z http://community.qnx.com/sf/go/post98234 I had write kernel log. I attach tracebuffer.kev file. I noticed another feature. If I invoke "sloginfo -w -c" then I have three times in second message -> "pcnet memory error" Wed, 19 Dec 2012 17:08:46 GMT http://community.qnx.com/sf/go/post98234 Oleg Gopov 2012-12-19T17:08:46Z http://community.qnx.com/sf/go/post98204 Oleg Gopov wrote: >> How I can make kernel trace????? Please, suggest. Please RTFM -> tracelogger ->http://www.qnx.com/developers/docs/6.4.1/neutrino/utilities/t/tracelogger.html --Armin Tue, 18 Dec 2012 14:37:18 GMT http://community.qnx.com/sf/go/post98204 Armin Steinhoff 2012-12-18T14:37:18Z http://community.qnx.com/sf/go/post98196 > > Oleg, > > please provide a kernel trace showing the status of the interrupt used > by the ethernet driver (and probably shared by other devices). > > --Armin > > > > Oleg Gopov wrote: > > And our network traffic is light > > > > > > > > _______________________________________________ > > > > Networking Drivers > > http://community.qnx.com/sf/go/post97595 > > To cancel your subscription to this discussion, please e-mail drivers- > networking-unsubscribe@community.qnx.com > > > How I can make kernel trace????? Please, suggest. Tue, 18 Dec 2012 12:33:17 GMT http://community.qnx.com/sf/go/post98196 Oleg Gopov 2012-12-18T12:33:17Z http://community.qnx.com/sf/go/post98139 The latest driver and enumeration file can be found here http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/Experimental DriversAndUtilities On 2012-12-14 9:23 AM, "Paolo Gussago" <community-noreply@qnx.com> wrote: >The O/S version is 6.5.0 >Here is the output of pci -v : > >PCI version = 3.00 > >Class = Bridge (Host/PCI) >Vendor ID = 8086h, Intel Corporation >Device ID = 104h, Sandy Bridge DRAM Controller >PCI index = 0h >Class Codes = 060000h >Revision ID = 9h >Bus number = 0 >Device number = 0 >Function num = 0 >Status Reg = 2090h >Command Reg = 6h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 0h >Subsystem Vendor ID = 8086h >Subsystem ID = 104h >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = NC >Interrupt line = 0 >CPU Interrupt = 0h >Capabilities Pointer = e0h >Capability ID = 9h - Vendor Specific >Capabilities = 10ch - a0806196h > >Class = Bridge (PCI/PCI) >Vendor ID = 8086h, Intel Corporation >Device ID = 101h, Sandy Bridge PCI Express Root Port >PCI index = 0h >Class Codes = 060400h >Revision ID = 9h >Bus number = 0 >Device number = 1 >Function num = 0 >Status Reg = 10h >Command Reg = 7h >Header type = 1h Multi-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 10h un-cacheable >Primary Bus Number = 0 >Secondary Bus Number = 1 >Subordinate Bus Number = 1 >Secondary Latency Timer = 0h >I/O Base = f0h >I/O Limit = 0h >Secondary Status = 0h >Memory Base = fff0h >Memory Limit = 0h >Prefetchable Memory Base = fff1h >Prefetchable Memory Limit= 1h >Prefetchable Base Upper 32 Bits = 0h >Prefetchable Limit Upper 32 Bits = 0h >I/O Base Upper 16 Bits = 0h >I/O Limit Upper 16 Bits = 0h >Bridge Control = 10h >PCI Int Pin = INT A >Interrupt line = 11 >CPU Interrupt = bh >Capabilities Pointer = 88h >Capability ID = dh - PCI Bridge Subsystem Vendor ID >Capabilities = 0h - 1018086h >Capability ID = 1h - Power Management >Capabilities = c803h - 8h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 0h - 0h >Capability ID = 10h - PCI Express >Capabilities = 142h - 8000h > >Class = Bridge (PCI/PCI) >Vendor ID = 8086h, Intel Corporation >Device ID = 109h, Sandy Bridge PCI Express Root Port >PCI index = 0h >Class Codes = 060400h >Revision ID = 9h >Bus number = 0 >Device number = 1 >Function num = 2 >Status Reg = 10h >Command Reg = 7h >Header type = 1h Multi-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 10h un-cacheable >Primary Bus Number = 0 >Secondary Bus Number = 2 >Subordinate Bus Number = 2 >Secondary Latency Timer = 0h >I/O Base = f0h >I/O Limit = 0h >Secondary Status = 0h >Memory Base = fff0h >Memory Limit = 0h >Prefetchable Memory Base = fff1h >Prefetchable Memory Limit= 1h >Prefetchable Base Upper 32 Bits = 0h >Prefetchable Limit Upper 32 Bits = 0h >I/O Base Upper 16 Bits = 0h >I/O Limit Upper 16 Bits = 0h >Bridge Control = 10h >PCI Int Pin = INT A >Interrupt line = 11 >CPU Interrupt = bh >Capabilities Pointer = 88h >Capability ID = dh - PCI Bridge Subsystem Vendor ID >Capabilities = 0h - 1098086h >Capability ID = 1h - Power Management >Capabilities = c803h - 8h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 0h - 0h >Capability ID = 10h - PCI Express >Capabilities = 142h - 8000h > >Class = Display (VGA) >Vendor ID = 8086h, Intel Corporation >Device ID = 106h, Sandy Bridge Integrated Graphics Controller >PCI index = 0h >Class Codes = 030000h >Revision ID = 9h >Bus number = 0 >Device number = 2 >Function num = 0 >Status Reg = 90h >Command Reg = 7h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 0h >BAR - 0 [Mem] = f5400000h 64bit length 4194304 enabled >BAR - 2 [Mem] = e0000000h prefetchable 64bit length 268435456 enabled >BAR - 4 [I/O] = f000h length 64 enabled >Subsystem Vendor ID = 8086h >Subsystem ID = 2010h >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT A >Interrupt line = 11 >CPU Interrupt = bh >Capabilities Pointer = 90h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 0h - 0h >Capability ID = 1h - Power Management >Capabilities = 22h - 0h >Capability ID = 13h - Unknown >Capabilities = 306h - 0h > >Class = Serial Bus (Universal Serial Bus) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c2dh, Cougar Point USB Enhanced Host Controller #2 >PCI index = 0h >Class Codes = 0c0320h >Revision ID = 5h >Bus number = 0 >Device number = 26 >Function num = 0 >Status Reg = 290h >Command Reg = 6h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 0h >BAR - 0 [Mem] = f7d07000h 32bit length 1024 enabled >Subsystem Vendor ID = 8086h >Subsystem ID = 1c2dh >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT A >Interrupt line = 11 >CPU Interrupt = bh >Capabilities Pointer = 50h >Capability ID = 1h - Power Management >Capabilities = c9c2h - 0h >Capability ID = ah - Debug Port >Capabilities = 20a0h - 0h >Capability ID = 13h - Unknown >Capabilities = 306h - 0h > >Class = Multimedia (RAM) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c20h, Cougar Point High Definition Audio Controller >PCI index = 0h >Class Codes = 040300h >Revision ID = 5h >Bus number = 0 >Device number = 27 >Function num = 0 >Status Reg = 10h >Command Reg = 6h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 10h un-cacheable >BAR - 0 [Mem] = f7d00000h 64bit length 16384 enabled >Subsystem Vendor ID = 8086h >Subsystem ID = 1c20h >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT A >Interrupt line = 5 >CPU Interrupt = 5h >Capabilities Pointer = 50h >Capability ID = 1h - Power Management >Capabilities = c842h - 0h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 80h - 0h >Capability ID = 10h - PCI Express >Capabilities = 91h - 10000000h > >Class = Bridge (PCI/PCI) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c10h, Cougar Point PCI Express Root Port 1 >PCI index = 0h >Class Codes = 060400h >Revision ID = b5h >Bus number = 0 >Device number = 28 >Function num = 0 >Status Reg = 10h >Command Reg = 7h >Header type = 1h Multi-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 10h un-cacheable >Primary Bus Number = 0 >Secondary Bus Number = 3 >Subordinate Bus Number = 3 >Secondary Latency Timer = 0h >I/O Base = e0h >I/O Limit = e0h >Secondary Status = 2000h >Memory Base = f730h >Memory Limit = f7c0h >Prefetchable Memory Base = f1b1h >Prefetchable Memory Limit= f241h >Prefetchable Base Upper 32 Bits = 0h >Prefetchable Limit Upper 32 Bits = 0h >I/O Base Upper 16 Bits = 0h >I/O Limit Upper 16 Bits = 0h >Bridge Control = 10h >PCI Int Pin = INT A >Interrupt line = 11 >CPU Interrupt = bh >Capabilities Pointer = 40h >Capability ID = 10h - PCI Express >Capabilities = 142h - 8000h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 0h - 0h >Capability ID = dh - PCI Bridge Subsystem Vendor ID >Capabilities = 0h - 1c108086h >Capability ID = 1h - Power Management >Capabilities = c802h - 0h > >Class = Bridge (PCI/PCI) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c12h, Cougar Point PCI Express Root Port 2 >PCI index = 0h >Class Codes = 060400h >Revision ID = b5h >Bus number = 0 >Device number = 28 >Function num = 1 >Status Reg = 10h >Command Reg = 7h >Header type = 1h Multi-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 10h un-cacheable >Primary Bus Number = 0 >Secondary Bus Number = 4 >Subordinate Bus Number = 4 >Secondary Latency Timer = 0h >I/O Base = d0h >I/O Limit = d0h >Secondary Status = 2000h >Memory Base = f690h >Memory Limit = f720h >Prefetchable Memory Base = f111h >Prefetchable Memory Limit= f1a1h >Prefetchable Base Upper 32 Bits = 0h >Prefetchable Limit Upper 32 Bits = 0h >I/O Base Upper 16 Bits = 0h >I/O Limit Upper 16 Bits = 0h >Bridge Control = 10h >PCI Int Pin = INT B >Interrupt line = 11 >CPU Interrupt = bh >Capabilities Pointer = 40h >Capability ID = 10h - PCI Express >Capabilities = 142h - 8000h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 0h - 0h >Capability ID = dh - PCI Bridge Subsystem Vendor ID >Capabilities = 0h - 1c128086h >Capability ID = 1h - Power Management >Capabilities = c802h - 0h > >Class = Bridge (PCI/PCI) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c1ch, Cougar Point PCI Express Root Port 7 >PCI index = 0h >Class Codes = 060400h >Revision ID = b5h >Bus number = 0 >Device number = 28 >Function num = 6 >Status Reg = 10h >Command Reg = 7h >Header type = 1h Multi-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 10h un-cacheable >Primary Bus Number = 0 >Secondary Bus Number = 5 >Subordinate Bus Number = 6 >Secondary Latency Timer = 0h >I/O Base = b0h >I/O Limit = c0h >Secondary Status = 2000h >Memory Base = f580h >Memory Limit = f680h >Prefetchable Memory Base = f001h >Prefetchable Memory Limit= f101h >Prefetchable Base Upper 32 Bits = 0h >Prefetchable Limit Upper 32 Bits = 0h >I/O Base Upper 16 Bits = 0h >I/O Limit Upper 16 Bits = 0h >Bridge Control = 10h >PCI Int Pin = INT C >Interrupt line = 10 >CPU Interrupt = ah >Capabilities Pointer = 40h >Capability ID = 10h - PCI Express >Capabilities = 142h - 8000h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 0h - 0h >Capability ID = dh - PCI Bridge Subsystem Vendor ID >Capabilities = 0h - 1c1c8086h >Capability ID = 1h - Power Management >Capabilities = c802h - 0h > >Class = Serial Bus (Universal Serial Bus) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c26h, Cougar Point USB Enhanced Host Controller #1 >PCI index = 0h >Class Codes = 0c0320h >Revision ID = 5h >Bus number = 0 >Device number = 29 >Function num = 0 >Status Reg = 290h >Command Reg = 6h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 0h >BAR - 0 [Mem] = f7d06000h 32bit length 1024 enabled >Subsystem Vendor ID = 8086h >Subsystem ID = 1c26h >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT A >Interrupt line = 5 >CPU Interrupt = 5h >Capabilities Pointer = 50h >Capability ID = 1h - Power Management >Capabilities = c9c2h - 0h >Capability ID = ah - Debug Port >Capabilities = 20a0h - 0h >Capability ID = 13h - Unknown >Capabilities = 306h - 0h > >Class = Bridge (PCI/ISA) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c49h, Cougar Point LPC Controller >PCI index = 0h >Class Codes = 060100h >Revision ID = 5h >Bus number = 0 >Device number = 31 >Function num = 0 >Status Reg = 210h >Command Reg = 7h >Header type = 0h Multi-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 0h >Subsystem Vendor ID = 8086h >Subsystem ID = 1c49h >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = NC >Interrupt line = 0 >CPU Interrupt = 0h >Capabilities Pointer = e0h >Capability ID = 9h - Vendor Specific >Capabilities = 100ch - 0h > >Class = Mass Storage (IDE) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c01h, Cougar Point 4 port SATA IDE Controller >PCI index = 0h >Class Codes = 01018fh >Revision ID = 5h >Bus number = 0 >Device number = 31 >Function num = 2 >Status Reg = 2b0h >Command Reg = 7h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 0h >BAR - 0 [I/O] = f110h length 8 enabled >BAR - 1 [I/O] = f100h length 4 enabled >BAR - 2 [I/O] = f0f0h length 8 enabled >BAR - 3 [I/O] = f0e0h length 4 enabled >BAR - 4 [I/O] = f0d0h length 16 enabled >BAR - 5 [I/O] = f0c0h length 16 enabled >Subsystem Vendor ID = 8086h >Subsystem ID = 1c01h >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT B >Interrupt line = 10 >CPU Interrupt = ah >Capabilities Pointer = 70h >Capability ID = 1h - Power Management >Capabilities = 3h - 8h >Capability ID = 13h - Unknown >Capabilities = 306h - 0h > >Class = Serial Bus (SMBus) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c22h, Cougar Point SMBus Controller >PCI index = 0h >Class Codes = 0c0500h >Revision ID = 5h >Bus number = 0 >Device number = 31 >Function num = 3 >Status Reg = 280h >Command Reg = 3h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 0h >BAR - 0 [Mem] = f7d05000h 64bit length 256 enabled >BAR - 4 [I/O] = f040h length 32 enabled >Subsystem Vendor ID = 8086h >Subsystem ID = 1c22h >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT C >Interrupt line = 10 >CPU Interrupt = ah > >Class = Mass Storage (IDE) >Vendor ID = 8086h, Intel Corporation >Device ID = 1c09h, Cougar Point 2 port SATA IDE Controller >PCI index = 0h >Class Codes = 010185h >Revision ID = 5h >Bus number = 0 >Device number = 31 >Function num = 5 >Status Reg = 2b0h >Command Reg = 5h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 0h >BAR - 0 [I/O] = f0b0h length 8 enabled >BAR - 1 [I/O] = f0a0h length 4 enabled >BAR - 2 [I/O] = f090h length 8 enabled >BAR - 3 [I/O] = f080h length 4 enabled >BAR - 4 [I/O] = f070h length 16 enabled >BAR - 5 [I/O] = f060h length 16 enabled >Subsystem Vendor ID = 8086h >Subsystem ID = 1c09h >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT B >Interrupt line = 10 >CPU Interrupt = ah >Capabilities Pointer = 70h >Capability ID = 1h - Power Management >Capabilities = 3h - 8h >Capability ID = 13h - Unknown >Capabilities = 306h - 0h > >Class = Network (Ethernet) >Vendor ID = 8086h, Intel Corporation >Device ID = 10d3h, 82574L Gigabit Network Connection >PCI index = 0h >Class Codes = 020000h >Revision ID = 0h >Bus number = 3 >Device number = 0 >Function num = 0 >Status Reg = 10h >Command Reg = 7h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 10h un-cacheable >BAR - 0 [Mem] = f7300000h 32bit length 131072 enabled >BAR - 2 [I/O] = e000h length 32 enabled >BAR - 3 [Mem] = f7320000h 32bit length 16384 enabled >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT A >Interrupt line = 11 >CPU Interrupt = bh >Capabilities Pointer = c8h >Capability ID = 1h - Power Management >Capabilities = c822h - f002000h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 80h - 0h >Capability ID = 10h - PCI Express >Capabilities = 1h - 8cc1h >Capability ID = 11h - MSI-X >Capabilities = 2h - 3h > >Class = Network (Ethernet) >Vendor ID = 8086h, Intel Corporation >Device ID = 10d3h, 82574L Gigabit Network Connection >PCI index = 1h >Class Codes = 020000h >Revision ID = 0h >Bus number = 4 >Device number = 0 >Function num = 0 >Status Reg = 10h >Command Reg = 7h >Header type = 0h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 10h un-cacheable >BAR - 0 [Mem] = f6900000h 32bit length 131072 enabled >BAR - 2 [I/O] = d000h length 32 enabled >BAR - 3 [Mem] = f6920000h 32bit length 16384 enabled >Max Lat = 0ns >Min Gnt = 0ns >PCI Int Pin = INT A >Interrupt line = 11 >CPU Interrupt = bh >Capabilities Pointer = c8h >Capability ID = 1h - Power Management >Capabilities = c822h - f002000h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 80h - 0h >Capability ID = 10h - PCI Express >Capabilities = 1h - 8cc1h >Capability ID = 11h - MSI-X >Capabilities = 2h - 3h > >Class = Bridge (PCI/PCI) >Vendor ID = 10b5h, PLX Technology, Inc. >Device ID = 8112h, PEX8112 x1 Lane PCI Express-to-PCI Bridge >PCI index = 0h >Class Codes = 060400h >Revision ID = aah >Bus number = 5 >Device number = 0 >Function num = 0 >Status Reg = 10h >Command Reg = 7h >Header type = 1h Single-function >BIST = 0h Build-in-self-test not supported >Latency Timer = 0h >Cache Line Size= 10h un-cacheable >Primary Bus Number = 5 >Secondary Bus Number = 6 >Subordinate Bus Number = 6 >Secondary Latency Timer = 20h >I/O Base = f0h >I/O Limit = 0h >Secondary Status = 2220h >Memory Base = fff0h >Memory Limit = 0h >Prefetchable Memory Base = fff0h >Prefetchable Memory Limit= 0h >Prefetchable Base Upper 32 Bits = 0h >Prefetchable Limit Upper 32 Bits = 0h >I/O Base Upper 16 Bits = 0h >I/O Limit Upper 16 Bits = 0h >Bridge Control = 10h >PCI Int Pin = INT A >Interrupt line = 10 >CPU Interrupt = ah >Capabilities Pointer = 40h >Capability ID = 1h - Power Management >Capabilities = 5a02h - 0h >Capability ID = 5h - Message Signaled Interrupts >Capabilities = 80h - 0h >Capability ID = 10h - PCI Express >Capabilities = 71h - 5900000h > >Thanks, >Paolo > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post98138 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Fri, 14 Dec 2012 14:43:12 GMT http://community.qnx.com/sf/go/post98139 Hugh Brown 2012-12-14T14:43:12Z http://community.qnx.com/sf/go/post98138 The O/S version is 6.5.0 Here is the output of pci -v : PCI version = 3.00 Class = Bridge (Host/PCI) Vendor ID = 8086h, Intel Corporation Device ID = 104h, Sandy Bridge DRAM Controller PCI index = 0h Class Codes = 060000h Revision ID = 9h Bus number = 0 Device number = 0 Function num = 0 Status Reg = 2090h Command Reg = 6h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 0h Subsystem Vendor ID = 8086h Subsystem ID = 104h Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = NC Interrupt line = 0 CPU Interrupt = 0h Capabilities Pointer = e0h Capability ID = 9h - Vendor Specific Capabilities = 10ch - a0806196h Class = Bridge (PCI/PCI) Vendor ID = 8086h, Intel Corporation Device ID = 101h, Sandy Bridge PCI Express Root Port PCI index = 0h Class Codes = 060400h Revision ID = 9h Bus number = 0 Device number = 1 Function num = 0 Status Reg = 10h Command Reg = 7h Header type = 1h Multi-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 10h un-cacheable Primary Bus Number = 0 Secondary Bus Number = 1 Subordinate Bus Number = 1 Secondary Latency Timer = 0h I/O Base = f0h I/O Limit = 0h Secondary Status = 0h Memory Base = fff0h Memory Limit = 0h Prefetchable Memory Base = fff1h Prefetchable Memory Limit= 1h Prefetchable Base Upper 32 Bits = 0h Prefetchable Limit Upper 32 Bits = 0h I/O Base Upper 16 Bits = 0h I/O Limit Upper 16 Bits = 0h Bridge Control = 10h PCI Int Pin = INT A Interrupt line = 11 CPU Interrupt = bh Capabilities Pointer = 88h Capability ID = dh - PCI Bridge Subsystem Vendor ID Capabilities = 0h - 1018086h Capability ID = 1h - Power Management Capabilities = c803h - 8h Capability ID = 5h - Message Signaled Interrupts Capabilities = 0h - 0h Capability ID = 10h - PCI Express Capabilities = 142h - 8000h Class = Bridge (PCI/PCI) Vendor ID = 8086h, Intel Corporation Device ID = 109h, Sandy Bridge PCI Express Root Port PCI index = 0h Class Codes = 060400h Revision ID = 9h Bus number = 0 Device number = 1 Function num = 2 Status Reg = 10h Command Reg = 7h Header type = 1h Multi-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 10h un-cacheable Primary Bus Number = 0 Secondary Bus Number = 2 Subordinate Bus Number = 2 Secondary Latency Timer = 0h I/O Base = f0h I/O Limit = 0h Secondary Status = 0h Memory Base = fff0h Memory Limit = 0h Prefetchable Memory Base = fff1h Prefetchable Memory Limit= 1h Prefetchable Base Upper 32 Bits = 0h Prefetchable Limit Upper 32 Bits = 0h I/O Base Upper 16 Bits = 0h I/O Limit Upper 16 Bits = 0h Bridge Control = 10h PCI Int Pin = INT A Interrupt line = 11 CPU Interrupt = bh Capabilities Pointer = 88h Capability ID = dh - PCI Bridge Subsystem Vendor ID Capabilities = 0h - 1098086h Capability ID = 1h - Power Management Capabilities = c803h - 8h Capability ID = 5h - Message Signaled Interrupts Capabilities = 0h - 0h Capability ID = 10h - PCI Express Capabilities = 142h - 8000h Class = Display (VGA) Vendor ID = 8086h, Intel Corporation Device ID = 106h, Sandy Bridge Integrated Graphics Controller PCI index = 0h Class Codes = 030000h Revision ID = 9h Bus number = 0 Device number = 2 Function num = 0 Status Reg = 90h Command Reg = 7h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 0h BAR - 0 [Mem] = f5400000h 64bit length 4194304 enabled BAR - 2 [Mem] = e0000000h prefetchable 64bit length 268435456 enabled BAR - 4 [I/O] = f000h length 64 enabled Subsystem Vendor ID = 8086h Subsystem ID = 2010h Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT A Interrupt line = 11 CPU Interrupt = bh Capabilities Pointer = 90h Capability ID = 5h - Message Signaled Interrupts Capabilities = 0h - 0h Capability ID = 1h - Power Management Capabilities = 22h - 0h Capability ID = 13h - Unknown Capabilities = 306h - 0h Class = Serial Bus (Universal Serial Bus) Vendor ID = 8086h, Intel Corporation Device ID = 1c2dh, Cougar Point USB Enhanced Host Controller #2 PCI index = 0h Class Codes = 0c0320h Revision ID = 5h Bus number = 0 Device number = 26 Function num = 0 Status Reg = 290h Command Reg = 6h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 0h BAR - 0 [Mem] = f7d07000h 32bit length 1024 enabled Subsystem Vendor ID = 8086h Subsystem ID = 1c2dh Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT A Interrupt line = 11 CPU Interrupt = bh Capabilities Pointer = 50h Capability ID = 1h - Power Management Capabilities = c9c2h - 0h Capability ID = ah - Debug Port Capabilities = 20a0h - 0h Capability ID = 13h - Unknown Capabilities = 306h - 0h Class = Multimedia (RAM) Vendor ID = 8086h, Intel Corporation Device ID = 1c20h, Cougar Point High Definition Audio Controller PCI index = 0h Class Codes = 040300h Revision ID = 5h Bus number = 0 Device number = 27 Function num = 0 Status Reg = 10h Command Reg = 6h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 10h un-cacheable BAR - 0 [Mem] = f7d00000h 64bit length 16384 enabled Subsystem Vendor ID = 8086h Subsystem ID = 1c20h Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT A Interrupt line = 5 CPU Interrupt = 5h Capabilities Pointer = 50h Capability ID = 1h - Power Management Capabilities = c842h - 0h Capability ID = 5h - Message Signaled Interrupts Capabilities = 80h - 0h Capability ID = 10h - PCI Express Capabilities = 91h - 10000000h Class = Bridge (PCI/PCI) Vendor ID = 8086h, Intel Corporation Device ID = 1c10h, Cougar Point PCI Express Root Port 1 PCI index = 0h Class Codes = 060400h Revision ID = b5h Bus number = 0 Device number = 28 Function num = 0 Status Reg = 10h Command Reg = 7h Header type = 1h Multi-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 10h un-cacheable Primary Bus Number = 0 Secondary Bus Number = 3 Subordinate Bus Number = 3 Secondary Latency Timer = 0h I/O Base = e0h I/O Limit = e0h Secondary Status = 2000h Memory Base = f730h Memory Limit = f7c0h Prefetchable Memory Base = f1b1h Prefetchable Memory Limit= f241h Prefetchable Base Upper 32 Bits = 0h Prefetchable Limit Upper 32 Bits = 0h I/O Base Upper 16 Bits = 0h I/O Limit Upper 16 Bits = 0h Bridge Control = 10h PCI Int Pin = INT A Interrupt line = 11 CPU Interrupt = bh Capabilities Pointer = 40h Capability ID = 10h - PCI Express Capabilities = 142h - 8000h Capability ID = 5h - Message Signaled Interrupts Capabilities = 0h - 0h Capability ID = dh - PCI Bridge Subsystem Vendor ID Capabilities = 0h - 1c108086h Capability ID = 1h - Power Management Capabilities = c802h - 0h Class = Bridge (PCI/PCI) Vendor ID = 8086h, Intel Corporation Device ID = 1c12h, Cougar Point PCI Express Root Port 2 PCI index = 0h Class Codes = 060400h Revision ID = b5h Bus number = 0 Device number = 28 Function num = 1 Status Reg = 10h Command Reg = 7h Header type = 1h Multi-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 10h un-cacheable Primary Bus Number = 0 Secondary Bus Number = 4 Subordinate Bus Number = 4 Secondary Latency Timer = 0h I/O Base = d0h I/O Limit = d0h Secondary Status = 2000h Memory Base = f690h Memory Limit = f720h Prefetchable Memory Base = f111h Prefetchable Memory Limit= f1a1h Prefetchable Base Upper 32 Bits = 0h Prefetchable Limit Upper 32 Bits = 0h I/O Base Upper 16 Bits = 0h I/O Limit Upper 16 Bits = 0h Bridge Control = 10h PCI Int Pin = INT B Interrupt line = 11 CPU Interrupt = bh Capabilities Pointer = 40h Capability ID = 10h - PCI Express Capabilities = 142h - 8000h Capability ID = 5h - Message Signaled Interrupts Capabilities = 0h - 0h Capability ID = dh - PCI Bridge Subsystem Vendor ID Capabilities = 0h - 1c128086h Capability ID = 1h - Power Management Capabilities = c802h - 0h Class = Bridge (PCI/PCI) Vendor ID = 8086h, Intel Corporation Device ID = 1c1ch, Cougar Point PCI Express Root Port 7 PCI index = 0h Class Codes = 060400h Revision ID = b5h Bus number = 0 Device number = 28 Function num = 6 Status Reg = 10h Command Reg = 7h Header type = 1h Multi-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 10h un-cacheable Primary Bus Number = 0 Secondary Bus Number = 5 Subordinate Bus Number = 6 Secondary Latency Timer = 0h I/O Base = b0h I/O Limit = c0h Secondary Status = 2000h Memory Base = f580h Memory Limit = f680h Prefetchable Memory Base = f001h Prefetchable Memory Limit= f101h Prefetchable Base Upper 32 Bits = 0h Prefetchable Limit Upper 32 Bits = 0h I/O Base Upper 16 Bits = 0h I/O Limit Upper 16 Bits = 0h Bridge Control = 10h PCI Int Pin = INT C Interrupt line = 10 CPU Interrupt = ah Capabilities Pointer = 40h Capability ID = 10h - PCI Express Capabilities = 142h - 8000h Capability ID = 5h - Message Signaled Interrupts Capabilities = 0h - 0h Capability ID = dh - PCI Bridge Subsystem Vendor ID Capabilities = 0h - 1c1c8086h Capability ID = 1h - Power Management Capabilities = c802h - 0h Class = Serial Bus (Universal Serial Bus) Vendor ID = 8086h, Intel Corporation Device ID = 1c26h, Cougar Point USB Enhanced Host Controller #1 PCI index = 0h Class Codes = 0c0320h Revision ID = 5h Bus number = 0 Device number = 29 Function num = 0 Status Reg = 290h Command Reg = 6h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 0h BAR - 0 [Mem] = f7d06000h 32bit length 1024 enabled Subsystem Vendor ID = 8086h Subsystem ID = 1c26h Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT A Interrupt line = 5 CPU Interrupt = 5h Capabilities Pointer = 50h Capability ID = 1h - Power Management Capabilities = c9c2h - 0h Capability ID = ah - Debug Port Capabilities = 20a0h - 0h Capability ID = 13h - Unknown Capabilities = 306h - 0h Class = Bridge (PCI/ISA) Vendor ID = 8086h, Intel Corporation Device ID = 1c49h, Cougar Point LPC Controller PCI index = 0h Class Codes = 060100h Revision ID = 5h Bus number = 0 Device number = 31 Function num = 0 Status Reg = 210h Command Reg = 7h Header type = 0h Multi-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 0h Subsystem Vendor ID = 8086h Subsystem ID = 1c49h Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = NC Interrupt line = 0 CPU Interrupt = 0h Capabilities Pointer = e0h Capability ID = 9h - Vendor Specific Capabilities = 100ch - 0h Class = Mass Storage (IDE) Vendor ID = 8086h, Intel Corporation Device ID = 1c01h, Cougar Point 4 port SATA IDE Controller PCI index = 0h Class Codes = 01018fh Revision ID = 5h Bus number = 0 Device number = 31 Function num = 2 Status Reg = 2b0h Command Reg = 7h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 0h BAR - 0 [I/O] = f110h length 8 enabled BAR - 1 [I/O] = f100h length 4 enabled BAR - 2 [I/O] = f0f0h length 8 enabled BAR - 3 [I/O] = f0e0h length 4 enabled BAR - 4 [I/O] = f0d0h length 16 enabled BAR - 5 [I/O] = f0c0h length 16 enabled Subsystem Vendor ID = 8086h Subsystem ID = 1c01h Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT B Interrupt line = 10 CPU Interrupt = ah Capabilities Pointer = 70h Capability ID = 1h - Power Management Capabilities = 3h - 8h Capability ID = 13h - Unknown Capabilities = 306h - 0h Class = Serial Bus (SMBus) Vendor ID = 8086h, Intel Corporation Device ID = 1c22h, Cougar Point SMBus Controller PCI index = 0h Class Codes = 0c0500h Revision ID = 5h Bus number = 0 Device number = 31 Function num = 3 Status Reg = 280h Command Reg = 3h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 0h BAR - 0 [Mem] = f7d05000h 64bit length 256 enabled BAR - 4 [I/O] = f040h length 32 enabled Subsystem Vendor ID = 8086h Subsystem ID = 1c22h Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT C Interrupt line = 10 CPU Interrupt = ah Class = Mass Storage (IDE) Vendor ID = 8086h, Intel Corporation Device ID = 1c09h, Cougar Point 2 port SATA IDE Controller PCI index = 0h Class Codes = 010185h Revision ID = 5h Bus number = 0 Device number = 31 Function num = 5 Status Reg = 2b0h Command Reg = 5h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 0h BAR - 0 [I/O] = f0b0h length 8 enabled BAR - 1 [I/O] = f0a0h length 4 enabled BAR - 2 [I/O] = f090h length 8 enabled BAR - 3 [I/O] = f080h length 4 enabled BAR - 4 [I/O] = f070h length 16 enabled BAR - 5 [I/O] = f060h length 16 enabled Subsystem Vendor ID = 8086h Subsystem ID = 1c09h Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT B Interrupt line = 10 CPU Interrupt = ah Capabilities Pointer = 70h Capability ID = 1h - Power Management Capabilities = 3h - 8h Capability ID = 13h - Unknown Capabilities = 306h - 0h Class = Network (Ethernet) Vendor ID = 8086h, Intel Corporation Device ID = 10d3h, 82574L Gigabit Network Connection PCI index = 0h Class Codes = 020000h Revision ID = 0h Bus number = 3 Device number = 0 Function num = 0 Status Reg = 10h Command Reg = 7h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 10h un-cacheable BAR - 0 [Mem] = f7300000h 32bit length 131072 enabled BAR - 2 [I/O] = e000h length 32 enabled BAR - 3 [Mem] = f7320000h 32bit length 16384 enabled Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT A Interrupt line = 11 CPU Interrupt = bh Capabilities Pointer = c8h Capability ID = 1h - Power Management Capabilities = c822h - f002000h Capability ID = 5h - Message Signaled Interrupts Capabilities = 80h - 0h Capability ID = 10h - PCI Express Capabilities = 1h - 8cc1h Capability ID = 11h - MSI-X Capabilities = 2h - 3h Class = Network (Ethernet) Vendor ID = 8086h, Intel Corporation Device ID = 10d3h, 82574L Gigabit Network Connection PCI index = 1h Class Codes = 020000h Revision ID = 0h Bus number = 4 Device number = 0 Function num = 0 Status Reg = 10h Command Reg = 7h Header type = 0h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 10h un-cacheable BAR - 0 [Mem] = f6900000h 32bit length 131072 enabled BAR - 2 [I/O] = d000h length 32 enabled BAR - 3 [Mem] = f6920000h 32bit length 16384 enabled Max Lat = 0ns Min Gnt = 0ns PCI Int Pin = INT A Interrupt line = 11 CPU Interrupt = bh Capabilities Pointer = c8h Capability ID = 1h - Power Management Capabilities = c822h - f002000h Capability ID = 5h - Message Signaled Interrupts Capabilities = 80h - 0h Capability ID = 10h - PCI Express Capabilities = 1h - 8cc1h Capability ID = 11h - MSI-X Capabilities = 2h - 3h Class = Bridge (PCI/PCI) Vendor ID = 10b5h, PLX Technology, Inc. Device ID = 8112h, PEX8112 x1 Lane PCI Express-to-PCI Bridge PCI index = 0h Class Codes = 060400h Revision ID = aah Bus number = 5 Device number = 0 Function num = 0 Status Reg = 10h Command Reg = 7h Header type = 1h Single-function BIST = 0h Build-in-self-test not supported Latency Timer = 0h Cache Line Size= 10h un-cacheable Primary Bus Number = 5 Secondary Bus Number = 6 Subordinate Bus Number = 6 Secondary Latency Timer = 20h I/O Base = f0h I/O Limit = 0h Secondary Status = 2220h Memory Base = fff0h Memory Limit = 0h Prefetchable Memory Base = fff0h Prefetchable Memory Limit= 0h Prefetchable Base Upper 32 Bits = 0h Prefetchable Limit Upper 32 Bits = 0h I/O Base Upper 16 Bits = 0h I/O Limit Upper 16 Bits = 0h Bridge Control = 10h PCI Int Pin = INT A Interrupt line = 10 CPU Interrupt = ah Capabilities Pointer = 40h Capability ID = 1h - Power Management Capabilities = 5a02h - 0h Capability ID = 5h - Message Signaled Interrupts Capabilities = 80h - 0h Capability ID = 10h - PCI Express Capabilities = 71h - 5900000h Thanks, Paolo Fri, 14 Dec 2012 14:23:24 GMT http://community.qnx.com/sf/go/post98138 Paolo Gussago 2012-12-14T14:23:24Z http://community.qnx.com/sf/go/post98116 What version of the O/S are you running? Also, please post the output of 'pci -v'. Thanks. On 2012-12-14 6:00 AM, "Paolo Gussago" <community-noreply@qnx.com> wrote: >I'm using a motherboard with 2 82754 chips. The first run fine, but the >second doesn't work. >The driver seems to be devn-e1000.so. >Is there an updated release of this driver ? >Where can I download it ? >Thank you >Paolo > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post98114 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Fri, 14 Dec 2012 12:21:49 GMT http://community.qnx.com/sf/go/post98116 Hugh Brown 2012-12-14T12:21:49Z http://community.qnx.com/sf/go/post98114 I'm using a motherboard with 2 82754 chips. The first run fine, but the second doesn't work. The driver seems to be devn-e1000.so. Is there an updated release of this driver ? Where can I download it ? Thank you Paolo Fri, 14 Dec 2012 11:00:47 GMT http://community.qnx.com/sf/go/post98114 Paolo Gussago 2012-12-14T11:00:47Z http://community.qnx.com/sf/go/post97831 Hi Hugh, I need the driver for Intel 82583V ethernet controller device id 0x150C. thanks, Barry Wed, 05 Dec 2012 18:17:03 GMT http://community.qnx.com/sf/go/post97831 Barry Ju 2012-12-05T18:17:03Z http://community.qnx.com/sf/go/post97832 This device is supported by the devnp-e1000.so driver under 6.5.0 SP1. On 2012-12-05 1:17 PM, "Barry Ju" <community-noreply@qnx.com> wrote: >Hi Hugh, > >I need the driver for Intel 82583V ethernet controller device id 0x150C. > >thanks, > >Barry > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post97831 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Wed, 05 Dec 2012 18:15:59 GMT http://community.qnx.com/sf/go/post97832 Hugh Brown 2012-12-05T18:15:59Z http://community.qnx.com/sf/go/post97819 You can use tcpdump for this. Sent from my BlackBerry device on the Rogers Wireless network. From: Chandramani . Sent: Wednesday, December 5, 2012 10:14 AM To: drivers-networking Reply To: drivers-networking@community.qnx.com Subject: Network packet analyzer utility / method in QNX Hi, I used "netstat" utility in QNX to analyze the network packets. But, there is no option to see the timestamp, source address, destination address, ack packets while using the netstat utility. I wanted to get the timestamp value, source & destination address, ack info etc for the network packets being exchanged on a given network interface in QNX, as we can get all this info in LINUX. Is there any utility available in QNX for this purpose? Or, is it possible to force network driver to print logs giving these info? (I tried verbose option for driver, but did not get any info) Kindly advice. Thanking you in advance. Regards, Chandramani _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post97818 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Wed, 05 Dec 2012 15:21:01 GMT http://community.qnx.com/sf/go/post97819 Sean Boudreau 2012-12-05T15:21:01Z http://community.qnx.com/sf/go/post97818 Hi, I used "netstat" utility in QNX to analyze the network packets. But, there is no option to see the timestamp, source address, destination address, ack packets while using the netstat utility. I wanted to get the timestamp value, source & destination address, ack info etc for the network packets being exchanged on a given network interface in QNX, as we can get all this info in LINUX. Is there any utility available in QNX for this purpose? Or, is it possible to force network driver to print logs giving these info? (I tried verbose option for driver, but did not get any info) Kindly advice. Thanking you in advance. Regards, Chandramani Wed, 05 Dec 2012 15:16:17 GMT http://community.qnx.com/sf/go/post97818 Chandramani . 2012-12-05T15:16:17Z http://community.qnx.com/sf/go/post97743 Hello, I am using P1020RDB evk and qnx 6.5.0. I have two interfaces tsec0 and tsec2. I have opened two instances of bpf0, one for tsec0 and another for tsec2. The packets i receive in tsec0 will be processed and if required will be send to tsec2. I receive the packets in tsec0 using bpf instance 1 and write to bpf instance 2 for tsec2. But when i send through tsec2, it is getting transmitted in tsec 0 also by default. Please let me know whether it is a correct behavior. if it is correct, how to disable this behaviour. Please suggest a solution. Thanks and warm regards, Santhosh. A Tue, 04 Dec 2012 07:11:48 GMT http://community.qnx.com/sf/go/post97743 Santhosh A 2012-12-04T07:11:48Z http://community.qnx.com/sf/go/post97657 Oleg, please provide a kernel trace showing the status of the interrupt used by the ethernet driver (and probably shared by other devices). --Armin Oleg Gopov wrote: > And our network traffic is light > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post97595 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Thu, 29 Nov 2012 22:47:18 GMT http://community.qnx.com/sf/go/post97657 Armin Steinhoff 2012-11-29T22:47:18Z http://community.qnx.com/sf/go/post97652 We have an e1000 driver for 6.3.0, but what device ID do you have? On 2012-11-29 2:04 PM, "Barry Ju" <community-noreply@qnx.com> wrote: >Has QNX ported e1000 driver to work with QNX6.3.0? > >thanks, > >Barry > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post97649 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 29 Nov 2012 19:31:25 GMT http://community.qnx.com/sf/go/post97652 Hugh Brown 2012-11-29T19:31:25Z http://community.qnx.com/sf/go/post97649 Has QNX ported e1000 driver to work with QNX6.3.0? thanks, Barry Thu, 29 Nov 2012 19:04:57 GMT http://community.qnx.com/sf/go/post97649 Barry Ju 2012-11-29T19:04:57Z http://community.qnx.com/sf/go/post97610 If you are running this under a VM, then it is quite easy to lose packets. On 2012-11-29 12:23 AM, "Oleg Gopov" <community-noreply@qnx.com> wrote: >I see nicinfo output - > pcnet32 network adapter work in half-duplex. How >I can lost packets??? I don't understand. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post97593 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 29 Nov 2012 12:23:28 GMT http://community.qnx.com/sf/go/post97610 Hugh Brown 2012-11-29T12:23:28Z http://community.qnx.com/sf/go/post97602 Oleg, UDP is a unsecure protocol ... that means when the driver is loosing interrupts it will loose packets. This can happen if the interrupt is shared by other devices and one of these device driver is disabling the shared interrupt for a longer time. We had a similar problem with a CAN communication ( similar to UDP communication) and there was interrupt disabled for ~8ms !! Best Regards Armin Steinhoff http://www.steinhoff-automation.com Oleg Gopov wrote: > I see nicinfo output - > pcnet32 network adapter work in half-duplex. How I can lost packets??? I don't understand. > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post97593 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com > Thu, 29 Nov 2012 09:00:16 GMT http://community.qnx.com/sf/go/post97602 Armin Steinhoff 2012-11-29T09:00:16Z http://community.qnx.com/sf/go/post97595 And our network traffic is light Thu, 29 Nov 2012 05:28:47 GMT http://community.qnx.com/sf/go/post97595 Oleg Gopov 2012-11-29T05:28:47Z http://community.qnx.com/sf/go/post97594 And out traffic is light. Thu, 29 Nov 2012 05:27:55 GMT http://community.qnx.com/sf/go/post97594 Oleg Gopov 2012-11-29T05:27:55Z http://community.qnx.com/sf/go/post97593 I see nicinfo output - > pcnet32 network adapter work in half-duplex. How I can lost packets??? I don't understand. Thu, 29 Nov 2012 05:23:50 GMT http://community.qnx.com/sf/go/post97593 Oleg Gopov 2012-11-29T05:23:50Z http://community.qnx.com/sf/go/post97548 The devnp-shim.so is required for the pcnet driver as is is an io-net driver. The e1000 driver is an io-pkt driver and doesn't require the shim. The pcnet driver is a 10/100 driver, so if you are trying to push lots of UDP packets through it, you could quite easily drop packets. On 2012-11-27 9:35 PM, "Oleg Gopov" <community-noreply@qnx.com> wrote: >Hello Friends. > >I had very strange issue recently. I have two embedded computers (vp7 and >vp9). Vp9 machine have intel i82544 network adapter , on the vp7 machine >- pcnet32. >Qnx version 6.4.0. > >On the vp9 machine I don't lost udp packets, but on vp7 I regulary lost >packets. > >If I invoke "pidin -p io-pkt-v4-hc mem" I see , that pcnet32 network >driver (devn-pcnet.so) is work via devnp-shim.so. But on vp9 machine >network adapter (devnp-i82544.so) work without devnp-shim.so. May be this >is a core of the problem??? And how I can play with network adapter >options?????????? > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post97532 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Wed, 28 Nov 2012 12:35:40 GMT http://community.qnx.com/sf/go/post97548 Hugh Brown 2012-11-28T12:35:40Z http://community.qnx.com/sf/go/post97532 Hello Friends. I had very strange issue recently. I have two embedded computers (vp7 and vp9). Vp9 machine have intel i82544 network adapter , on the vp7 machine - pcnet32. Qnx version 6.4.0. On the vp9 machine I don't lost udp packets, but on vp7 I regulary lost packets. If I invoke "pidin -p io-pkt-v4-hc mem" I see , that pcnet32 network driver (devn-pcnet.so) is work via devnp-shim.so. But on vp9 machine network adapter (devnp-i82544.so) work without devnp-shim.so. May be this is a core of the problem??? And how I can play with network adapter options?????????? Wed, 28 Nov 2012 02:35:42 GMT http://community.qnx.com/sf/go/post97532 Oleg Gopov 2012-11-28T02:35:42Z http://community.qnx.com/sf/go/post97326 I hope to get your reply, Thank you very much. Wed, 21 Nov 2012 01:13:44 GMT http://community.qnx.com/sf/go/post97326 liang alvin 2012-11-21T01:13:44Z http://community.qnx.com/sf/go/post97302 I am trying to contact Broadcom with regard to your question, as our driver is a port of the Broadcom source. On 2012-11-20 6:09 AM, "liang alvin" <community-noreply@qnx.com> wrote: >Hi, > I am testing the Broadcom wireless(vid=0x14e4, did=0x4311) on QNX6.5, it >is builded on the pcie card, i check from the QNX database, it should >support it already(using devnp-bcm43xx.so), but i get error(follow is >the error message): > >Nov 20 19:04:31 5 14 0 tcpip starting >Nov 20 19:04:31 3 14 0 Using pseudo random generator. See >"random" option >Nov 20 19:04:31 5 14 0 initializing IPsec... done >Nov 20 19:04:31 5 14 0 IPsec: Initialized Security Association >Processing. >Nov 20 19:04:31 5 14 0 bcm43xx_detect >Nov 20 19:04:31 5 14 0 devn-bcm43xx: Vendor Id.=0x14e4 Device >Id.=0x4311 pci index=0x0000 Irq=0x000b >Nov 20 19:04:31 2 14 0 >/home/builder/hudson/6.5.x_milestone/svn/lib/io-pkt/sys/dev_nda/bcm43xx/bc >m/shrd/sbutils.c 301 > >Nov 20 19:04:31 5 14 0 bc0sb_doattach: unrecognized device id >0x4311 >Nov 20 19:04:31 5 14 0 wl0: wlc_attach: sb_attach failed >Nov 20 19:04:31 2 14 0 wlc_attach failed - error 11 >Nov 20 19:04:31 2 14 0 Unable to init >/lib/dll/devnp-bcm43xx.so: No such process > > >Any help would be greatly appreciated. >Thanks. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post97296 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 20 Nov 2012 13:25:54 GMT http://community.qnx.com/sf/go/post97302 Hugh Brown 2012-11-20T13:25:54Z http://community.qnx.com/sf/go/post97296 Hi, I am testing the Broadcom wireless(vid=0x14e4, did=0x4311) on QNX6.5, it is builded on the pcie card, i check from the QNX database, it should support it already(using devnp-bcm43xx.so), but i get error(follow is the error message): Nov 20 19:04:31 5 14 0 tcpip starting Nov 20 19:04:31 3 14 0 Using pseudo random generator. See "random" option Nov 20 19:04:31 5 14 0 initializing IPsec... done Nov 20 19:04:31 5 14 0 IPsec: Initialized Security Association Processing. Nov 20 19:04:31 5 14 0 bcm43xx_detect Nov 20 19:04:31 5 14 0 devn-bcm43xx: Vendor Id.=0x14e4 Device Id.=0x4311 pci index=0x0000 Irq=0x000b Nov 20 19:04:31 2 14 0 /home/builder/hudson/6.5.x_milestone/svn/lib/io-pkt/sys/dev_nda/bcm43xx/bcm/shrd/sbutils.c 301 Nov 20 19:04:31 5 14 0 bc0sb_doattach: unrecognized device id 0x4311 Nov 20 19:04:31 5 14 0 wl0: wlc_attach: sb_attach failed Nov 20 19:04:31 2 14 0 wlc_attach failed - error 11 Nov 20 19:04:31 2 14 0 Unable to init /lib/dll/devnp-bcm43xx.so: No such process Any help would be greatly appreciated. Thanks. Tue, 20 Nov 2012 11:09:32 GMT http://community.qnx.com/sf/go/post97296 liang alvin 2012-11-20T11:09:32Z http://community.qnx.com/sf/go/post97032 I used following command and it worked - # io-pkt-v4-hc -d ncm pnp verbose & or you can specify path i.e. #io-pkt-v4-hc -d ncm pnp path=/lib/dll/devnp-ncm.so verbose & But make sure the sequence. It matters. If you give "pnp" after "path" then it will not work. Fri, 09 Nov 2012 10:38:50 GMT http://community.qnx.com/sf/go/post97032 DIPANKAR SAHA 2012-11-09T10:38:50Z http://community.qnx.com/sf/go/post96943 You can use either method, but regarding method 1, check the usage messages for the ncm driver as it provides instructions on how to load it when you start io-pkt: # use /lib/dll/devnp-ncm.so Also check the output of sloginfo after you try to load the driver as it will indicate initialization errors. Wed, 07 Nov 2012 12:53:25 GMT http://community.qnx.com/sf/go/post96943 Gervais Mulongoy 2012-11-07T12:53:25Z http://community.qnx.com/sf/go/post96940 I am running QNX OS (650SP1) in VMplayer. I would like to load devnp-ncm.so driver. I have tried following things - 1) # io-pkt-v4-hc -d /lib/dll/devnp-ncm.so path=/dev/io-usb/io-usb -ptcpip verbose & 2) # io-pkt-v4-hc & # mount -T io-pkt devnp-ncm.so Please give me some suggestion how to load it. Wed, 07 Nov 2012 11:29:09 GMT http://community.qnx.com/sf/go/post96940 DIPANKAR SAHA 2012-11-07T11:29:09Z http://community.qnx.com/sf/go/post96881 Not at QNX AFAIK. On 2012-11-06 1:56 AM, "Andy Rhind" <community-noreply@qnx.com> wrote: >I'm also interested. Does anyone have plans for this driver in QNX6? > >Thanks, >Andy > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post96876 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 06 Nov 2012 12:31:49 GMT http://community.qnx.com/sf/go/post96881 Hugh Brown 2012-11-06T12:31:49Z http://community.qnx.com/sf/go/post96876 I'm also interested. Does anyone have plans for this driver in QNX6? Thanks, Andy Tue, 06 Nov 2012 06:56:49 GMT http://community.qnx.com/sf/go/post96876 Andy Rhind 2012-11-06T06:56:49Z http://community.qnx.com/sf/go/post96327 OK, Thanks for the reply Mon, 15 Oct 2012 13:22:34 GMT http://community.qnx.com/sf/go/post96327 RANJITH THAVAMANI 2012-10-15T13:22:34Z http://community.qnx.com/sf/go/post96326 I don't work on USB and this is the wrong forum for USB. This forum is for network drivers. On 2012-10-15 8:37 AM, "RANJITH THAVAMANI" <community-noreply@qnx.com> wrote: >Hi Hugh, > >I have installed qnx 6.4.0 into the same dell machine, but it looks like >USB devices(Keyboard, mouse and mass storage devices) are not detected, >Can you help on this? > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post96323 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Mon, 15 Oct 2012 13:17:08 GMT http://community.qnx.com/sf/go/post96326 Hugh Brown 2012-10-15T13:17:08Z http://community.qnx.com/sf/go/post96323 Hi Hugh, I have installed qnx 6.4.0 into the same dell machine, but it looks like USB devices(Keyboard, mouse and mass storage devices) are not detected, Can you help on this? Mon, 15 Oct 2012 12:37:50 GMT http://community.qnx.com/sf/go/post96323 RANJITH THAVAMANI 2012-10-15T12:37:50Z http://community.qnx.com/sf/go/post96259 I guess that leaves a few options: 1. My dongle is bad 2. There are board differences (like in the USB system) that is breaking something 3. There is something wrong with my overall QNX installation. I'll check the dongle on a windows box to see if it works there. Thanks for the help, Rob -----Original Message----- From: Hugh Brown [mailto:community-noreply@qnx.com] Sent: Thursday, October 11, 2012 11:52 AM To: drivers-networking@community.qnx.com Subject: Re: USB Ethernet Dongle with ASIX chipset - traffic goes to localhost I have run the driver on armv7 and it works just fine with the same device that you have (0xb95 0x1780). Hugh. On 2012-10-11 11:18 AM, "Rob Coker" <community-noreply@qnx.com> wrote: >That loaded a lot better! I'm still having the same problem - can't >get ping to work. When I do verbose, it says destination host >unreachable and seems to be sending through 127.0.0.1. Is there a way >to determine whether this is a driver problem or whether the problem is >somewhere else? > >I'm puzzled that nicinfo reports packets transmitted & received. I'm >also puzzled that "route show" shows correct MAC addresses for the >hosts on my network. So, the device is obviously getting some data through it. > >Rob > >-----Original Message----- >From: Hugh Brown [mailto:community-noreply@qnx.com] >Sent: Thursday, October 11, 2012 9:19 AM >To: drivers-networking@community.qnx.com >Subject: Re: USB Ethernet Dongle with ASIX chipset - traffic goes to >localhost > >It would help if I sent you the correct driver! I sent you the x86 >version, so here is the armv7 version. > >Hugh. > > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post96245 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post96253 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Thu, 11 Oct 2012 17:28:58 GMT http://community.qnx.com/sf/go/post96259 Rob Coker 2012-10-11T17:28:58Z http://community.qnx.com/sf/go/post96253 I have run the driver on armv7 and it works just fine with the same device that you have (0xb95 0x1780). Hugh. On 2012-10-11 11:18 AM, "Rob Coker" <community-noreply@qnx.com> wrote: >That loaded a lot better! I'm still having the same problem - can't get >ping to work. When I do verbose, it says destination host unreachable and >seems to be sending through 127.0.0.1. Is there a way to determine >whether >this is a driver problem or whether the problem is somewhere else? > >I'm puzzled that nicinfo reports packets transmitted & received. I'm also >puzzled that "route show" shows correct MAC addresses for the hosts on my >network. So, the device is obviously getting some data through it. > >Rob > >-----Original Message----- >From: Hugh Brown [mailto:community-noreply@qnx.com] >Sent: Thursday, October 11, 2012 9:19 AM >To: drivers-networking@community.qnx.com >Subject: Re: USB Ethernet Dongle with ASIX chipset - traffic goes to >localhost > >It would help if I sent you the correct driver! I sent you the x86 >version, >so here is the armv7 version. > >Hugh. > > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post96245 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 11 Oct 2012 16:55:17 GMT http://community.qnx.com/sf/go/post96253 Hugh Brown 2012-10-11T16:55:17Z http://community.qnx.com/sf/go/post96251 I'll have to try the driver on ARM. The driver runs fine on x86. On 2012-10-11 11:18 AM, "Rob Coker" <community-noreply@qnx.com> wrote: >That loaded a lot better! I'm still having the same problem - can't get >ping to work. When I do verbose, it says destination host unreachable and >seems to be sending through 127.0.0.1. Is there a way to determine >whether >this is a driver problem or whether the problem is somewhere else? > >I'm puzzled that nicinfo reports packets transmitted & received. I'm also >puzzled that "route show" shows correct MAC addresses for the hosts on my >network. So, the device is obviously getting some data through it. > >Rob > >-----Original Message----- >From: Hugh Brown [mailto:community-noreply@qnx.com] >Sent: Thursday, October 11, 2012 9:19 AM >To: drivers-networking@community.qnx.com >Subject: Re: USB Ethernet Dongle with ASIX chipset - traffic goes to >localhost > >It would help if I sent you the correct driver! I sent you the x86 >version, >so here is the armv7 version. > >Hugh. > > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post96245 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 11 Oct 2012 16:33:49 GMT http://community.qnx.com/sf/go/post96251 Hugh Brown 2012-10-11T16:33:49Z http://community.qnx.com/sf/go/post96245 That loaded a lot better! I'm still having the same problem - can't get ping to work. When I do verbose, it says destination host unreachable and seems to be sending through 127.0.0.1. Is there a way to determine whether this is a driver problem or whether the problem is somewhere else? I'm puzzled that nicinfo reports packets transmitted & received. I'm also puzzled that "route show" shows correct MAC addresses for the hosts on my network. So, the device is obviously getting some data through it. Rob -----Original Message----- From: Hugh Brown [mailto:community-noreply@qnx.com] Sent: Thursday, October 11, 2012 9:19 AM To: drivers-networking@community.qnx.com Subject: Re: USB Ethernet Dongle with ASIX chipset - traffic goes to localhost It would help if I sent you the correct driver! I sent you the x86 version, so here is the armv7 version. Hugh. Thu, 11 Oct 2012 15:20:44 GMT http://community.qnx.com/sf/go/post96245 Rob Coker 2012-10-11T15:20:44Z http://community.qnx.com/sf/go/post96240 It would help if I sent you the correct driver! I sent you the x86 version, so here is the armv7 version. Hugh. On 2012-10-11 10:09 AM, "Rob Coker" <community-noreply@qnx.com> wrote: >Hugh, > >Thanks for sending the new driver, but I'm wondering if I did something >wrong. I'm getting a huge number or unknown relocation type errors when I >try to run io-pkt-v4 (list is attached). It looks like this driver is not >detecting libc.so.3. I have no idea why. > >Rob > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post96238 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 11 Oct 2012 14:21:11 GMT http://community.qnx.com/sf/go/post96240 Hugh Brown 2012-10-11T14:21:11Z http://community.qnx.com/sf/go/post96238 Hugh, Thanks for sending the new driver, but I'm wondering if I did something wrong. I'm getting a huge number or unknown relocation type errors when I try to run io-pkt-v4 (list is attached). It looks like this driver is not detecting libc.so.3. I have no idea why. Rob Thu, 11 Oct 2012 14:11:46 GMT http://community.qnx.com/sf/go/post96238 Rob Coker 2012-10-11T14:11:46Z http://community.qnx.com/sf/go/post96228 You can try the attached driver. On 2012-10-09 11:39 AM, "Rob Coker" <community-noreply@qnx.com> wrote: >I'm using a NovPek i.mx6x board and trying to get ethernet working with a >Plugable USB2-E1000 USB to Ethernet adapter. The behavior is really >strange. I've tried this with the stock devn-asix driver for armle-v7 as >well as the driver from this thread >(http://community.qnx.com/sf/go/topc22380). I've also tried using a >powered hub as mentioned in another thread. > >Here are the results of various investigation attempts: >** USB finds device ** ># usb -v >USB 0 (EHCI) v1.10, v1.01 DDK, v1.01 HCD > Control, Interrupt, Bulk(SG), Isoch(Stream), Low speed, High speed > >USB 1 (EHCI) v1.10, v1.01 DDK, v1.01 HCD > Control, Interrupt, Bulk(SG), Isoch(Stream), Low speed, High speed > >Device Address : 1 >Upstream Host Controller : 1 >Upstream Device Address : 0 >Upstream Port : 0 >Upstream Port Speed : High >Vendor : 0x0409 (NEC) >Product : 0x005a >Device Release : r1.00 >Class : 0x09 (Hub) >Subclass : 0x00 >Protocol : 0x01 >Max PacketSize0 : 64 >Hub Number Ports : 4 >Hub Characteristics : 0x00a9 (Individual power, Individual >over-current) >Hub Power On->Good : 100 ms >Hub Power Requirements : 100 mA >Configurations : 1 > Configuration : 1 > Attributes : 0xe0 (Self-powered, Remote-wakeup) > Max Power : 100 mA > >Device Address : 2 >Upstream Host Controller : 1 >Upstream Device Address : 1 >Upstream Port : 4 >Upstream Port Speed : High >Vendor : 0x0b95 (ASIX Elec. Corp.) >Product : 0x1780 (AX88178 ) >Device Release : r0.01 >Class : 0xff (Vendor-specific) >Subclass : 0xff >Protocol : 0x00 >Max PacketSize0 : 64 >Configurations : 1 > Configuration : 1 (0) > Attributes : 0xa0 (Bus-powered, Remote-wakeup) > Max Power : 450 mA > >** start networking ** ># io-pkt-v4 -d asix -ptcpip ># sloginfo >Time Sev Major Minor Args >Jan 01 00:00:18 5 14 0 tcpip starting >Jan 01 00:00:18 3 14 0 Unable to attach to pci server: No such >file or directory >Jan 01 00:00:18 3 14 0 Using pseudo random generator. See >"random" option >Jan 01 00:00:18 6 10 0 Chipset 88178 >Jan 01 00:00:18 5 14 0 ax_enable_88178: eeprom index 0x17 is >0x1b >Jan 01 00:00:18 5 14 0 GPIO Setting 0x33133383 > >** use dhcp.client - returns immediately only gives 0.0.0.0 ** ># 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: 80:3f:d5:08:3d:ba > media: Ethernet 100baseTX full-duplex > status: active ># dhcp.client & >[1] 40974 ># ifconfig >ifconfig >lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 > inet 127.0.0.1 netmask 0xff000000 >en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> >mtu 1500 > address: 80:3f:d5:08:3d:ba > media: Ethernet 100baseTX full-duplex > status: active > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >[1] + Done dhcp.client > >** nicinfo - device seems to send and receive something ** ># nicinfo >en0: > Asix Ethernet Controller > > Physical Node ID ........................... 803FD5 083DBA > Current Physical Node ID ................... 803FD5 083DBA > Current Operation Rate ..................... 100.00 Mb/s full-duplex > Active Interface Type ...................... MII > Active PHY address ....................... 2 > Maximum Transmittable data Unit ............ 1514 > Maximum Receivable data Unit ............... 1514 > Promiscuous Mode ........................... Off > Multicast Support .......................... Enabled > > Packets Transmitted OK ..................... 4 > Bytes Transmitted OK ....................... 1368 > Broadcast Packets Transmitted OK ........... 4 > Multicast Packets Transmitted OK ........... 0 > > Packets Received OK ........................ 332 > Bytes Received OK .......................... 37672 > Broadcast Packets Received OK .............. 0 > Multicast Packets Received OK .............. 332 > 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 > Transmit Underruns ......................... 0 > No Carrier on Transmit ..................... 0 > Receive Alignment errors ................... 0 > Received packets with CRC errors ........... 0 > Packets Dropped on receive ................. 0 > Short packets .............................. 0 > Total Frames experiencing Collison(s) ...... 0 > >** force address with ifconfig ** ># ifconfig en0 192.168.0.140 netmask 255.255.255.0 ># ifconfig >lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 > inet 127.0.0.1 netmask 0xff000000 >en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> >mtu 1500 > address: 80:3f:d5:08:3d:ba > media: Ethernet 100baseTX full-duplex > status: active > inet 192.168.0.140 netmask 0xffffff00 broadcast 192.168.0.255 > >** try to ping a local computer ** > ping -R -v 192.168.0.129 >PING 192.168.0.129 (192.168.0.129): 56 data bytes >Destination Port Unreachable > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > 4 5 00 4800 2100 0 0000 40 11 0000 127.0.0.1 127.0.0.1 > UDP: from port 65534, to port 53 >Destination Port Unreachable > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > 4 5 00 4800 2300 0 0000 40 11 0000 127.0.0.1 127.0.0.1 > UDP: from port 65533, to port 53 >ping: sendto: Host is down >ping: sendto: Host is down >ping: sendto: Host is down >ping: sendto: Host is down >ping: sendto: Host is down > >So, for some reason, the networking system tries to route it through >localhost even if I try to ping myself. Any help figuring out why this >won't route through en0 would be much appreciated. > >Rob > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post96135 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 11 Oct 2012 11:36:42 GMT http://community.qnx.com/sf/go/post96228 Hugh Brown 2012-10-11T11:36:42Z http://community.qnx.com/sf/go/post96135 I'm using a NovPek i.mx6x board and trying to get ethernet working with a Plugable USB2-E1000 USB to Ethernet adapter. The behavior is really strange. I've tried this with the stock devn-asix driver for armle-v7 as well as the driver from this thread (http://community.qnx.com/sf/go/topc22380). I've also tried using a powered hub as mentioned in another thread. Here are the results of various investigation attempts: ** USB finds device ** # usb -v USB 0 (EHCI) v1.10, v1.01 DDK, v1.01 HCD Control, Interrupt, Bulk(SG), Isoch(Stream), Low speed, High speed USB 1 (EHCI) v1.10, v1.01 DDK, v1.01 HCD Control, Interrupt, Bulk(SG), Isoch(Stream), Low speed, High speed Device Address : 1 Upstream Host Controller : 1 Upstream Device Address : 0 Upstream Port : 0 Upstream Port Speed : High Vendor : 0x0409 (NEC) Product : 0x005a Device Release : r1.00 Class : 0x09 (Hub) Subclass : 0x00 Protocol : 0x01 Max PacketSize0 : 64 Hub Number Ports : 4 Hub Characteristics : 0x00a9 (Individual power, Individual over-current) Hub Power On->Good : 100 ms Hub Power Requirements : 100 mA Configurations : 1 Configuration : 1 Attributes : 0xe0 (Self-powered, Remote-wakeup) Max Power : 100 mA Device Address : 2 Upstream Host Controller : 1 Upstream Device Address : 1 Upstream Port : 4 Upstream Port Speed : High Vendor : 0x0b95 (ASIX Elec. Corp.) Product : 0x1780 (AX88178 ) Device Release : r0.01 Class : 0xff (Vendor-specific) Subclass : 0xff Protocol : 0x00 Max PacketSize0 : 64 Configurations : 1 Configuration : 1 (0) Attributes : 0xa0 (Bus-powered, Remote-wakeup) Max Power : 450 mA ** start networking ** # io-pkt-v4 -d asix -ptcpip # sloginfo Time Sev Major Minor Args Jan 01 00:00:18 5 14 0 tcpip starting Jan 01 00:00:18 3 14 0 Unable to attach to pci server: No such file or directory Jan 01 00:00:18 3 14 0 Using pseudo random generator. See "random" option Jan 01 00:00:18 6 10 0 Chipset 88178 Jan 01 00:00:18 5 14 0 ax_enable_88178: eeprom index 0x17 is 0x1b Jan 01 00:00:18 5 14 0 GPIO Setting 0x33133383 ** use dhcp.client - returns immediately only gives 0.0.0.0 ** # 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: 80:3f:d5:08:3d:ba media: Ethernet 100baseTX full-duplex status: active # dhcp.client & [1] 40974 # ifconfig ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 80:3f:d5:08:3d:ba media: Ethernet 100baseTX full-duplex status: active inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 [1] + Done dhcp.client ** nicinfo - device seems to send and receive something ** # nicinfo en0: Asix Ethernet Controller Physical Node ID ........................... 803FD5 083DBA Current Physical Node ID ................... 803FD5 083DBA Current Operation Rate ..................... 100.00 Mb/s full-duplex Active Interface Type ...................... MII Active PHY address ....................... 2 Maximum Transmittable data Unit ............ 1514 Maximum Receivable data Unit ............... 1514 Promiscuous Mode ........................... Off Multicast Support .......................... Enabled Packets Transmitted OK ..................... 4 Bytes Transmitted OK ....................... 1368 Broadcast Packets Transmitted OK ........... 4 Multicast Packets Transmitted OK ........... 0 Packets Received OK ........................ 332 Bytes Received OK .......................... 37672 Broadcast Packets Received OK .............. 0 Multicast Packets Received OK .............. 332 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 Transmit Underruns ......................... 0 No Carrier on Transmit ..................... 0 Receive Alignment errors ................... 0 Received packets with CRC errors ........... 0 Packets Dropped on receive ................. 0 Short packets .............................. 0 Total Frames experiencing Collison(s) ...... 0 ** force address with ifconfig ** # ifconfig en0 192.168.0.140 netmask 255.255.255.0 # ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 80:3f:d5:08:3d:ba media: Ethernet 100baseTX full-duplex status: active inet 192.168.0.140 netmask 0xffffff00 broadcast 192.168.0.255 ** try to ping a local computer ** ping -R -v 192.168.0.129 PING 192.168.0.129 (192.168.0.129): 56 data bytes Destination Port Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 4800 2100 0 0000 40 11 0000 127.0.0.1 127.0.0.1 UDP: from port 65534, to port 53 Destination Port Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 4800 2300 0 0000 40 11 0000 127.0.0.1 127.0.0.1 UDP: from port 65533, to port 53 ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down So, for some reason, the networking system tries to route it through localhost even if I try to ping myself. Any help figuring out why this won't route through en0 would be much appreciated. Rob Tue, 09 Oct 2012 15:39:47 GMT http://community.qnx.com/sf/go/post96135 Rob Coker 2012-10-09T15:39:47Z http://community.qnx.com/sf/go/post96029 Thanks Hugh Thu, 04 Oct 2012 12:18:00 GMT http://community.qnx.com/sf/go/post96029 antony Lewis 2012-10-04T12:18:00Z http://community.qnx.com/sf/go/post96026 No, there isn't. This driver is over 3 years old. On 2012-10-04 6:35 AM, "antony Lewis" <community-noreply@qnx.com> wrote: >Dear friends > >I need to use devn-ppc405-ep440c.so network driver for QNX 6.4.1 , Is >there newer version of its source code than the one included in following >link package? > >http://community.qnx.com/sf/frs/do/viewRelease/projects.bsp/frs.amcc_ppc44 >0_ep_gr_evk.bsp_nto640_amcc_ppc440ep_gr_evk > >Regards > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post96023 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 04 Oct 2012 11:34:12 GMT http://community.qnx.com/sf/go/post96026 Hugh Brown 2012-10-04T11:34:12Z http://community.qnx.com/sf/go/post96023 Dear friends I need to use devn-ppc405-ep440c.so network driver for QNX 6.4.1 , Is there newer version of its source code than the one included in following link package? http://community.qnx.com/sf/frs/do/viewRelease/projects.bsp/frs.amcc_ppc440_ep_gr_evk.bsp_nto640_amcc_ppc440ep_gr_evk Regards Thu, 04 Oct 2012 10:35:31 GMT http://community.qnx.com/sf/go/post96023 antony Lewis 2012-10-04T10:35:31Z http://community.qnx.com/sf/go/post95994 Thanks! -----Message d'origine----- De : Gervais Mulongoy [mailto:community-noreply@qnx.com] Envoyé : Wednesday, October 03, 2012 8:21 AM À : drivers-networking@community.qnx.com Objet : Re: 10G Not as far as I can tell. _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post95992 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Wed, 03 Oct 2012 13:07:34 GMT http://community.qnx.com/sf/go/post95994 Mario Charest 2012-10-03T13:07:34Z http://community.qnx.com/sf/go/post95992 Not as far as I can tell. Wed, 03 Oct 2012 12:24:24 GMT http://community.qnx.com/sf/go/post95992 Gervais Mulongoy 2012-10-03T12:24:24Z http://community.qnx.com/sf/go/post95991 Here's a write up that I found. The MAC address can be modified by editing the nvs_map.bin file. Any binary editor can be used for this purpose (e.g. HxD - Freeware Hex Editor and Disk Editor). The MAC address field in the nvs_map.bin is defined as follows: nvs_map.bin address offset MAC address 0x3 - 0x6 Local station MAC address LSB 0xA - 0xD Local station MAC address MSB For more details, see: http://processors.wiki.ti.com/index.php/OMAP35x_Wireless_Connectivity_Getti ng_Started_Guide#Setting_up_Ethernet_Address_of_the_EVM For testing I changed our wireless MAC address from 08-00-28-32-e4-59 to 08-00-28-01-02-03. first 16 bytes (MAC: 08-00-28-32-e4-59): 01 6D 54 59 E4 32 28 01 71 54 00 08 00 00 00 00 changed to (MAC: 08-00-28-01-02-03): 01 6D 54 03 02 01 28 01 71 54 00 08 00 00 00 00 The nvs_map.bin file needs to be transferred to QNX target (over network, SD card, USB stick ...) and then linked to specific locations as follows. I copied the nvs_map_cal-mac-01-02-03.bin to NAND flash on J5 which was mounted under /var. On 2012-09-26 5:12 PM, "Boangoat Jarupan" <community-noreply@qnx.com> wrote: >We are trying to dynamically change the MAC address using following >command. > >io-pkt-v4-hc -dti1283-sdc4430 >mac=001122334455,sdio=2,dmatx=47,dmarx=48,irq=1003,gpio=90,irq_gpio=3 > >However, this is not possible. Is there anyway we can change MAC address >through command line option? > >Thank you. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95862 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Wed, 03 Oct 2012 11:29:48 GMT http://community.qnx.com/sf/go/post95991 Hugh Brown 2012-10-03T11:29:48Z http://community.qnx.com/sf/go/post95988 > We don't have a driver at the moment, but are planning to have one available > for the next release. Don't ask when that will be! Otherwise a driver can be > written under CE. > I don`t recall reading anything about this in SP1 release note but did a driver for 10G intel card (82598) make it into SP1. > > On 11-02-24 9:51 AM, "Mario Charest" <community-noreply@qnx.com> wrote: > > > > > I though I read somewhere that there was support for Intel 10G network cards > . > > However can't find any reference to it. Did I have a dream or did the dream > > have me? > > > > > > > > _______________________________________________ > > > > Networking Drivers > > http://community.qnx.com/sf/go/post83459 > > > > -- > Hugh Brown (613) 591-0931 ext. 2209 (voice) > QNX Software Systems Ltd. (613) 591-3579 (fax) > 175 Terence Matthews Cres. email: hsbrown@qnx.com > Kanata, Ontario, Canada. > K2M 1W8 > > Wed, 03 Oct 2012 01:23:07 GMT http://community.qnx.com/sf/go/post95988 Mario Charest 2012-10-03T01:23:07Z http://community.qnx.com/sf/go/post95948 No, the driver doesn't support this. On 2012-09-26 5:12 PM, "Boangoat Jarupan" <community-noreply@qnx.com> wrote: >We are trying to dynamically change the MAC address using following >command. > >io-pkt-v4-hc -dti1283-sdc4430 >mac=001122334455,sdio=2,dmatx=47,dmarx=48,irq=1003,gpio=90,irq_gpio=3 > >However, this is not possible. Is there anyway we can change MAC address >through command line option? > >Thank you. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95862 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Mon, 01 Oct 2012 14:45:48 GMT http://community.qnx.com/sf/go/post95948 Hugh Brown 2012-10-01T14:45:48Z http://community.qnx.com/sf/go/post95862 We are trying to dynamically change the MAC address using following command. io-pkt-v4-hc -dti1283-sdc4430 mac=001122334455,sdio=2,dmatx=47,dmarx=48,irq=1003,gpio=90,irq_gpio=3 However, this is not possible. Is there anyway we can change MAC address through command line option? Thank you. Wed, 26 Sep 2012 21:12:02 GMT http://community.qnx.com/sf/go/post95862 Boangoat Jarupan 2012-09-26T21:12:02Z http://community.qnx.com/sf/go/post95603 Hey there! Occasionally, we have some problems regarding TCP communication from an embedded PPC system (running QNX 6.3.0SP3, but with the io-pkt-v4-hc driver from QNX 6.4) to an industrial PC (running Windows XP Embedded). There are TCP retransmissions occurring from time to time - so far nothing unusual - but in some cases, the error seems to build up, i.e. the number of re-transmissions increases successively. After some time, there are too many TCP retransmissions, so that the ordinary communication (Modbus request -> Modbus response -> Next Modbus request ...) is basically broken. The underlying Ethernet connection is built up in a local area network (without any switches or hubs in between, and with static IP addresses assigned), and is used for Modbus/TCP communication only. Both the PPC and the WinXP systems, as well as the connection cross-cable have already been replaced, so this is almost certainly no hardware issue. Other systems with the same or a similar setup are working fine so far. With this brief description at hand, I expect no one to come up with a satisfying solution. Hence, for now I have only some basic questions (as I am not such a networking expert as others here, who may hopefully read this): 1. If a TCP connection is finally closed (using the ordinary FIN/ACK handshake), shouldn't the still outstanding retransmissions (or any other communication to the remote host with this IP address and TCP port) then be immediately discarded? I'm asking this, because in our case, the retransmission of packets is still ongoing for a while (presumably until a maximum retry count and/or time is reached) after the connection has been closed. In addition, the QNX system also keeps sending RST/ACK requests to the remote system. Again, the answer might be trivial, as I am not a networking expert. But please, even if so, hit me with it. (Otherwise, Wireshark traces could be provided if desired for a more detailed analysis.) 2. Is there any known issue towards using io-pkt-v4-hc on a QNX 6.3.0SP3 system (e.g. known bugs in the TCP stack), which could cause this error? 3. On the QNX system, we use the Packet Filter pseudo-device (pf) as a "firewall". Here's the relevant configuration for pfctl: #################### ### NORMALIZATION scrub in all scrub out all ### INITIAL BLOCK ALL ON ANY ITF block in all block out all ### SERVICE: modbus server pass in quick on en0 proto tcp from any to (en0) port 501 keep state (max-src-conn 10, max-src-conn-rate 5/10) #################### Using this configuration the pf should work "connection-based" and therefore only block network communication if there are too many connection requests within a certain amount of time. However, in our case, there's only one connection which is permanently maintained (unless the connection is manually terminated, in which case the questions 1. and 2. apply). Still: Could it be, that pf is somehow responsible for blocking the outgoing TCP response packets in such a way that the described error is provoked? Thanks in advance for any hints regarding this topic. Regards, Markus Mon, 17 Sep 2012 14:24:00 GMT http://community.qnx.com/sf/go/post95603 Markus Kohler 2012-09-17T14:24:00Z http://community.qnx.com/sf/go/post95502 Good news! The changes that I made to the trunk driver were made after the SP1 release was frozen, so that is why the changes were not in SP1. Thanks, Hugh. On 2012-09-11 10:53 AM, "Mario Charest" <community-noreply@qnx.com> wrote: > >This one work, if you need to do more testing, don`t hesitate, glad I can >help. > >> -----Message d'origine----- >> De : Hugh Brown [mailto:community-noreply@qnx.com] >> Envoyé : 11 septembre 2012 10:23 >> À : drivers-networking@community.qnx.com >> Objet : Re: Intel i350 >> >> How about this one. >> >> Thanks, Hugh. >> >> >> >> >> >> On 2012-09-10 12:45 PM, "Mario Charest" <community-noreply@qnx.com> >> wrote: >> >> > >> >This one doesn't work but nicinfo does show proper link speed with some >> >TX and RX packets, but can't see the network with ping or qnet. >> > >> >Thanks! >> > >> >> -----Message d'origine----- >> >> De : Hugh Brown [mailto:community-noreply@qnx.com] >> >> Envoyé : 10 septembre 2012 11:06 >> >> À : drivers-networking@community.qnx.com >> >> Objet : Re: Intel i350 >> >> >> >> Please try this one. >> >> >> >> Thanks, Hugh. >> >> >> >> >> >> >> >> >> >> On 2012-09-10 9:08 AM, "Mario Charest" <community-noreply@qnx.com> >> >> wrote: >> >> >> >> > >> >> >This one is working! >> >> > >> >> >> -----Message d'origine----- >> >> >> De : Hugh Brown [mailto:community-noreply@qnx.com] >> >> >> Envoyé : 10 septembre 2012 08:25 >> >> >> À : drivers-networking@community.qnx.com >> >> >> Objet : Re: Intel i350 >> >> >> >> >> >> Now the thread shows up again! Please try the attached driver and >> >> >> let me know if it works. >> >> >> >> >> >> On 2012-09-07 3:45 PM, "Mario Charest" <community- >> noreply@qnx.com> >> >> >> wrote: >> >> >> >> >> >> >> Does the attached driver work for you? If not, can you please >> >> >> >> start the driver with "verbose=3" and post the sloginfo output. >> >> >> >> >> >> >> >> >> >> >> >Didn't work. Sloginfo ouput attached. Nicinfo shows incoming >> >>packets. >> >> >> >It's important to note our cisco switch takes around 30 seconds >> >> >> >to auto-negoticate and do some fancy test detection before >> >> >> >showing the port as active. Though I'd mention it in case it >>could be >> related. >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> On 2012-09-07 2:41 PM, "Mario Charest" <community- >> >> noreply@qnx.com> >> >> >> >>wrote: >> >> >> >> >> >> >> >> > >> >> >> >> >At the time this post was written, the latest driver I have on >> >> >> >> >hand ( date is 2012/05/03, experimental ) works on that >> >> >> >> >chipset but the one >> >> >> >>with >> >> >> >> >SP1 doesn't. It detects the NIC but it always reports a speed >> >> >> >> >of >> >> >> >> >0 half duplex. But the SP1 driver is data 2012/06/20. Is it >> >> >> >> >because something go broken or the experimental driver has >> >> >> >> >some changes that didn't make >> >> >> >>it >> >> >> >> >into SP1? >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> >_______________________________________________ >> >> >> >> > >> >> >> >> >Networking Drivers >> >> >> >> >http://community.qnx.com/sf/go/post95454 >> >> >> >> >To cancel your subscription to this discussion, please e-mail >> >> >> >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> >_______________________________________________ >> >> >> > >> >> >> >Networking Drivers >> >> >> >http://community.qnx.com/sf/go/post95456 >> >> >> >To cancel your subscription to this discussion, please e-mail >> >> >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> Networking Drivers >> >> >> http://community.qnx.com/sf/go/post95464 >> >> >> To cancel your subscription to this discussion, please e-mail >> >> >> drivers- networking-unsubscribe@community.qnx.com >> >> > >> >> > >> >> > >> >> > >> >> >_______________________________________________ >> >> > >> >> >Networking Drivers >> >> >http://community.qnx.com/sf/go/post95465 >> >> >To cancel your subscription to this discussion, please e-mail >> >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> Networking Drivers >> >> http://community.qnx.com/sf/go/post95474 >> >> To cancel your subscription to this discussion, please e-mail >> >> drivers- networking-unsubscribe@community.qnx.com >> > >> > >> > >> > >> >_______________________________________________ >> > >> >Networking Drivers >> >http://community.qnx.com/sf/go/post95484 >> >To cancel your subscription to this discussion, please e-mail >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> >> _______________________________________________ >> >> Networking Drivers >> http://community.qnx.com/sf/go/post95499 >> To cancel your subscription to this discussion, please e-mail drivers- >> networking-unsubscribe@community.qnx.com > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95501 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 11 Sep 2012 15:09:45 GMT http://community.qnx.com/sf/go/post95502 Hugh Brown 2012-09-11T15:09:45Z http://community.qnx.com/sf/go/post95501 This one work, if you need to do more testing, don`t hesitate, glad I can help. > -----Message d'origine----- > De : Hugh Brown [mailto:community-noreply@qnx.com] > Envoyé : 11 septembre 2012 10:23 > À : drivers-networking@community.qnx.com > Objet : Re: Intel i350 > > How about this one. > > Thanks, Hugh. > > > > > > On 2012-09-10 12:45 PM, "Mario Charest" <community-noreply@qnx.com> > wrote: > > > > >This one doesn't work but nicinfo does show proper link speed with some > >TX and RX packets, but can't see the network with ping or qnet. > > > >Thanks! > > > >> -----Message d'origine----- > >> De : Hugh Brown [mailto:community-noreply@qnx.com] > >> Envoyé : 10 septembre 2012 11:06 > >> À : drivers-networking@community.qnx.com > >> Objet : Re: Intel i350 > >> > >> Please try this one. > >> > >> Thanks, Hugh. > >> > >> > >> > >> > >> On 2012-09-10 9:08 AM, "Mario Charest" <community-noreply@qnx.com> > >> wrote: > >> > >> > > >> >This one is working! > >> > > >> >> -----Message d'origine----- > >> >> De : Hugh Brown [mailto:community-noreply@qnx.com] > >> >> Envoyé : 10 septembre 2012 08:25 > >> >> À : drivers-networking@community.qnx.com > >> >> Objet : Re: Intel i350 > >> >> > >> >> Now the thread shows up again! Please try the attached driver and > >> >> let me know if it works. > >> >> > >> >> On 2012-09-07 3:45 PM, "Mario Charest" <community- > noreply@qnx.com> > >> >> wrote: > >> >> > >> >> >> Does the attached driver work for you? If not, can you please > >> >> >> start the driver with "verbose=3" and post the sloginfo output. > >> >> >> > >> >> >> > >> >> >Didn't work. Sloginfo ouput attached. Nicinfo shows incoming > >>packets. > >> >> >It's important to note our cisco switch takes around 30 seconds > >> >> >to auto-negoticate and do some fancy test detection before > >> >> >showing the port as active. Though I'd mention it in case it could be > related. > >> >> > > >> >> > > >> >> >> > >> >> >> On 2012-09-07 2:41 PM, "Mario Charest" <community- > >> noreply@qnx.com> > >> >> >>wrote: > >> >> >> > >> >> >> > > >> >> >> >At the time this post was written, the latest driver I have on > >> >> >> >hand ( date is 2012/05/03, experimental ) works on that > >> >> >> >chipset but the one > >> >> >>with > >> >> >> >SP1 doesn't. It detects the NIC but it always reports a speed > >> >> >> >of > >> >> >> >0 half duplex. But the SP1 driver is data 2012/06/20. Is it > >> >> >> >because something go broken or the experimental driver has > >> >> >> >some changes that didn't make > >> >> >>it > >> >> >> >into SP1? > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >_______________________________________________ > >> >> >> > > >> >> >> >Networking Drivers > >> >> >> >http://community.qnx.com/sf/go/post95454 > >> >> >> >To cancel your subscription to this discussion, please e-mail > >> >> >> >drivers-networking-unsubscribe@community.qnx.com > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >_______________________________________________ > >> >> > > >> >> >Networking Drivers > >> >> >http://community.qnx.com/sf/go/post95456 > >> >> >To cancel your subscription to this discussion, please e-mail > >> >> >drivers-networking-unsubscribe@community.qnx.com > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> > >> >> Networking Drivers > >> >> http://community.qnx.com/sf/go/post95464 > >> >> To cancel your subscription to this discussion, please e-mail > >> >> drivers- networking-unsubscribe@community.qnx.com > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> > > >> >Networking Drivers > >> >http://community.qnx.com/sf/go/post95465 > >> >To cancel your subscription to this discussion, please e-mail > >> >drivers-networking-unsubscribe@community.qnx.com > >> > >> > >> > >> > >> > >> _______________________________________________ > >> > >> Networking Drivers > >> http://community.qnx.com/sf/go/post95474 > >> To cancel your subscription to this discussion, please e-mail > >> drivers- networking-unsubscribe@community.qnx.com > > > > > > > > > >_______________________________________________ > > > >Networking Drivers > >http://community.qnx.com/sf/go/post95484 > >To cancel your subscription to this discussion, please e-mail > >drivers-networking-unsubscribe@community.qnx.com > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post95499 > To cancel your subscription to this discussion, please e-mail drivers- > networking-unsubscribe@community.qnx.com Tue, 11 Sep 2012 14:57:39 GMT http://community.qnx.com/sf/go/post95501 Mario Charest 2012-09-11T14:57:39Z http://community.qnx.com/sf/go/post95499 How about this one. Thanks, Hugh. On 2012-09-10 12:45 PM, "Mario Charest" <community-noreply@qnx.com> wrote: > >This one doesn't work but nicinfo does show proper link speed with some >TX and RX packets, but can't see the network with ping or qnet. > >Thanks! > >> -----Message d'origine----- >> De : Hugh Brown [mailto:community-noreply@qnx.com] >> Envoyé : 10 septembre 2012 11:06 >> À : drivers-networking@community.qnx.com >> Objet : Re: Intel i350 >> >> Please try this one. >> >> Thanks, Hugh. >> >> >> >> >> On 2012-09-10 9:08 AM, "Mario Charest" <community-noreply@qnx.com> >> wrote: >> >> > >> >This one is working! >> > >> >> -----Message d'origine----- >> >> De : Hugh Brown [mailto:community-noreply@qnx.com] >> >> Envoyé : 10 septembre 2012 08:25 >> >> À : drivers-networking@community.qnx.com >> >> Objet : Re: Intel i350 >> >> >> >> Now the thread shows up again! Please try the attached driver and let >> >> me know if it works. >> >> >> >> On 2012-09-07 3:45 PM, "Mario Charest" <community-noreply@qnx.com> >> >> wrote: >> >> >> >> >> Does the attached driver work for you? If not, can you please >> >> >> start the driver with "verbose=3" and post the sloginfo output. >> >> >> >> >> >> >> >> >Didn't work. Sloginfo ouput attached. Nicinfo shows incoming >>packets. >> >> >It's important to note our cisco switch takes around 30 seconds to >> >> >auto-negoticate and do some fancy test detection before showing the >> >> >port as active. Though I'd mention it in case it could be related. >> >> > >> >> > >> >> >> >> >> >> On 2012-09-07 2:41 PM, "Mario Charest" <community- >> noreply@qnx.com> >> >> >>wrote: >> >> >> >> >> >> > >> >> >> >At the time this post was written, the latest driver I have on >> >> >> >hand ( date is 2012/05/03, experimental ) works on that chipset >> >> >> >but the one >> >> >>with >> >> >> >SP1 doesn't. It detects the NIC but it always reports a speed of >> >> >> >0 half duplex. But the SP1 driver is data 2012/06/20. Is it >> >> >> >because something go broken or the experimental driver has some >> >> >> >changes that didn't make >> >> >>it >> >> >> >into SP1? >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> >_______________________________________________ >> >> >> > >> >> >> >Networking Drivers >> >> >> >http://community.qnx.com/sf/go/post95454 >> >> >> >To cancel your subscription to this discussion, please e-mail >> >> >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >_______________________________________________ >> >> > >> >> >Networking Drivers >> >> >http://community.qnx.com/sf/go/post95456 >> >> >To cancel your subscription to this discussion, please e-mail >> >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> Networking Drivers >> >> http://community.qnx.com/sf/go/post95464 >> >> To cancel your subscription to this discussion, please e-mail >> >> drivers- networking-unsubscribe@community.qnx.com >> > >> > >> > >> > >> >_______________________________________________ >> > >> >Networking Drivers >> >http://community.qnx.com/sf/go/post95465 >> >To cancel your subscription to this discussion, please e-mail >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> >> _______________________________________________ >> >> Networking Drivers >> http://community.qnx.com/sf/go/post95474 >> To cancel your subscription to this discussion, please e-mail drivers- >> networking-unsubscribe@community.qnx.com > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95484 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 11 Sep 2012 14:26:31 GMT http://community.qnx.com/sf/go/post95499 Hugh Brown 2012-09-11T14:26:31Z http://community.qnx.com/sf/go/post95484 This one doesn't work but nicinfo does show proper link speed with some TX and RX packets, but can't see the network with ping or qnet. Thanks! > -----Message d'origine----- > De : Hugh Brown [mailto:community-noreply@qnx.com] > Envoyé : 10 septembre 2012 11:06 > À : drivers-networking@community.qnx.com > Objet : Re: Intel i350 > > Please try this one. > > Thanks, Hugh. > > > > > On 2012-09-10 9:08 AM, "Mario Charest" <community-noreply@qnx.com> > wrote: > > > > >This one is working! > > > >> -----Message d'origine----- > >> De : Hugh Brown [mailto:community-noreply@qnx.com] > >> Envoyé : 10 septembre 2012 08:25 > >> À : drivers-networking@community.qnx.com > >> Objet : Re: Intel i350 > >> > >> Now the thread shows up again! Please try the attached driver and let > >> me know if it works. > >> > >> On 2012-09-07 3:45 PM, "Mario Charest" <community-noreply@qnx.com> > >> wrote: > >> > >> >> Does the attached driver work for you? If not, can you please > >> >> start the driver with "verbose=3" and post the sloginfo output. > >> >> > >> >> > >> >Didn't work. Sloginfo ouput attached. Nicinfo shows incoming packets. > >> >It's important to note our cisco switch takes around 30 seconds to > >> >auto-negoticate and do some fancy test detection before showing the > >> >port as active. Though I'd mention it in case it could be related. > >> > > >> > > >> >> > >> >> On 2012-09-07 2:41 PM, "Mario Charest" <community- > noreply@qnx.com> > >> >>wrote: > >> >> > >> >> > > >> >> >At the time this post was written, the latest driver I have on > >> >> >hand ( date is 2012/05/03, experimental ) works on that chipset > >> >> >but the one > >> >>with > >> >> >SP1 doesn't. It detects the NIC but it always reports a speed of > >> >> >0 half duplex. But the SP1 driver is data 2012/06/20. Is it > >> >> >because something go broken or the experimental driver has some > >> >> >changes that didn't make > >> >>it > >> >> >into SP1? > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >_______________________________________________ > >> >> > > >> >> >Networking Drivers > >> >> >http://community.qnx.com/sf/go/post95454 > >> >> >To cancel your subscription to this discussion, please e-mail > >> >> >drivers-networking-unsubscribe@community.qnx.com > >> >> > >> > > >> > > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> > > >> >Networking Drivers > >> >http://community.qnx.com/sf/go/post95456 > >> >To cancel your subscription to this discussion, please e-mail > >> >drivers-networking-unsubscribe@community.qnx.com > >> > >> > >> > >> > >> > >> _______________________________________________ > >> > >> Networking Drivers > >> http://community.qnx.com/sf/go/post95464 > >> To cancel your subscription to this discussion, please e-mail > >> drivers- networking-unsubscribe@community.qnx.com > > > > > > > > > >_______________________________________________ > > > >Networking Drivers > >http://community.qnx.com/sf/go/post95465 > >To cancel your subscription to this discussion, please e-mail > >drivers-networking-unsubscribe@community.qnx.com > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post95474 > To cancel your subscription to this discussion, please e-mail drivers- > networking-unsubscribe@community.qnx.com Mon, 10 Sep 2012 16:50:44 GMT http://community.qnx.com/sf/go/post95484 Mario Charest 2012-09-10T16:50:44Z http://community.qnx.com/sf/go/post95474 Please try this one. Thanks, Hugh. On 2012-09-10 9:08 AM, "Mario Charest" <community-noreply@qnx.com> wrote: > >This one is working! > >> -----Message d'origine----- >> De : Hugh Brown [mailto:community-noreply@qnx.com] >> Envoyé : 10 septembre 2012 08:25 >> À : drivers-networking@community.qnx.com >> Objet : Re: Intel i350 >> >> Now the thread shows up again! Please try the attached driver and let me >> know if it works. >> >> On 2012-09-07 3:45 PM, "Mario Charest" <community-noreply@qnx.com> >> wrote: >> >> >> Does the attached driver work for you? If not, can you please start >> >> the driver with "verbose=3" and post the sloginfo output. >> >> >> >> >> >Didn't work. Sloginfo ouput attached. Nicinfo shows incoming packets. >> >It's important to note our cisco switch takes around 30 seconds to >> >auto-negoticate and do some fancy test detection before showing the >> >port as active. Though I'd mention it in case it could be related. >> > >> > >> >> >> >> On 2012-09-07 2:41 PM, "Mario Charest" <community-noreply@qnx.com> >> >>wrote: >> >> >> >> > >> >> >At the time this post was written, the latest driver I have on hand >> >> >( date is 2012/05/03, experimental ) works on that chipset but the >> >> >one >> >>with >> >> >SP1 doesn't. It detects the NIC but it always reports a speed of 0 >> >> >half duplex. But the SP1 driver is data 2012/06/20. Is it because >> >> >something go broken or the experimental driver has some changes that >> >> >didn't make >> >>it >> >> >into SP1? >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >_______________________________________________ >> >> > >> >> >Networking Drivers >> >> >http://community.qnx.com/sf/go/post95454 >> >> >To cancel your subscription to this discussion, please e-mail >> >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> > >> > >> > >> > >> > >> > >> >_______________________________________________ >> > >> >Networking Drivers >> >http://community.qnx.com/sf/go/post95456 >> >To cancel your subscription to this discussion, please e-mail >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> >> _______________________________________________ >> >> Networking Drivers >> http://community.qnx.com/sf/go/post95464 >> To cancel your subscription to this discussion, please e-mail drivers- >> networking-unsubscribe@community.qnx.com > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95465 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Mon, 10 Sep 2012 15:08:52 GMT http://community.qnx.com/sf/go/post95474 Hugh Brown 2012-09-10T15:08:52Z http://community.qnx.com/sf/go/post95466 OK, so there must be a difference between the trunk and 6.5.0 branches. I'll investigate. Thanks, Hugh. On 2012-09-10 9:08 AM, "Mario Charest" <community-noreply@qnx.com> wrote: > >This one is working! > >> -----Message d'origine----- >> De : Hugh Brown [mailto:community-noreply@qnx.com] >> Envoyé : 10 septembre 2012 08:25 >> À : drivers-networking@community.qnx.com >> Objet : Re: Intel i350 >> >> Now the thread shows up again! Please try the attached driver and let me >> know if it works. >> >> On 2012-09-07 3:45 PM, "Mario Charest" <community-noreply@qnx.com> >> wrote: >> >> >> Does the attached driver work for you? If not, can you please start >> >> the driver with "verbose=3" and post the sloginfo output. >> >> >> >> >> >Didn't work. Sloginfo ouput attached. Nicinfo shows incoming packets. >> >It's important to note our cisco switch takes around 30 seconds to >> >auto-negoticate and do some fancy test detection before showing the >> >port as active. Though I'd mention it in case it could be related. >> > >> > >> >> >> >> On 2012-09-07 2:41 PM, "Mario Charest" <community-noreply@qnx.com> >> >>wrote: >> >> >> >> > >> >> >At the time this post was written, the latest driver I have on hand >> >> >( date is 2012/05/03, experimental ) works on that chipset but the >> >> >one >> >>with >> >> >SP1 doesn't. It detects the NIC but it always reports a speed of 0 >> >> >half duplex. But the SP1 driver is data 2012/06/20. Is it because >> >> >something go broken or the experimental driver has some changes that >> >> >didn't make >> >>it >> >> >into SP1? >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >_______________________________________________ >> >> > >> >> >Networking Drivers >> >> >http://community.qnx.com/sf/go/post95454 >> >> >To cancel your subscription to this discussion, please e-mail >> >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> > >> > >> > >> > >> > >> > >> >_______________________________________________ >> > >> >Networking Drivers >> >http://community.qnx.com/sf/go/post95456 >> >To cancel your subscription to this discussion, please e-mail >> >drivers-networking-unsubscribe@community.qnx.com >> >> >> >> >> >> _______________________________________________ >> >> Networking Drivers >> http://community.qnx.com/sf/go/post95464 >> To cancel your subscription to this discussion, please e-mail drivers- >> networking-unsubscribe@community.qnx.com > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95465 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Mon, 10 Sep 2012 13:13:49 GMT http://community.qnx.com/sf/go/post95466 Hugh Brown 2012-09-10T13:13:49Z http://community.qnx.com/sf/go/post95465 This one is working! > -----Message d'origine----- > De : Hugh Brown [mailto:community-noreply@qnx.com] > Envoyé : 10 septembre 2012 08:25 > À : drivers-networking@community.qnx.com > Objet : Re: Intel i350 > > Now the thread shows up again! Please try the attached driver and let me > know if it works. > > On 2012-09-07 3:45 PM, "Mario Charest" <community-noreply@qnx.com> > wrote: > > >> Does the attached driver work for you? If not, can you please start > >> the driver with "verbose=3" and post the sloginfo output. > >> > >> > >Didn't work. Sloginfo ouput attached. Nicinfo shows incoming packets. > >It's important to note our cisco switch takes around 30 seconds to > >auto-negoticate and do some fancy test detection before showing the > >port as active. Though I'd mention it in case it could be related. > > > > > >> > >> On 2012-09-07 2:41 PM, "Mario Charest" <community-noreply@qnx.com> > >>wrote: > >> > >> > > >> >At the time this post was written, the latest driver I have on hand > >> >( date is 2012/05/03, experimental ) works on that chipset but the > >> >one > >>with > >> >SP1 doesn't. It detects the NIC but it always reports a speed of 0 > >> >half duplex. But the SP1 driver is data 2012/06/20. Is it because > >> >something go broken or the experimental driver has some changes that > >> >didn't make > >>it > >> >into SP1? > >> > > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> > > >> >Networking Drivers > >> >http://community.qnx.com/sf/go/post95454 > >> >To cancel your subscription to this discussion, please e-mail > >> >drivers-networking-unsubscribe@community.qnx.com > >> > > > > > > > > > > > > > >_______________________________________________ > > > >Networking Drivers > >http://community.qnx.com/sf/go/post95456 > >To cancel your subscription to this discussion, please e-mail > >drivers-networking-unsubscribe@community.qnx.com > > > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post95464 > To cancel your subscription to this discussion, please e-mail drivers- > networking-unsubscribe@community.qnx.com Mon, 10 Sep 2012 13:11:11 GMT http://community.qnx.com/sf/go/post95465 Mario Charest 2012-09-10T13:11:11Z http://community.qnx.com/sf/go/post95464 Now the thread shows up again! Please try the attached driver and let me know if it works. On 2012-09-07 3:45 PM, "Mario Charest" <community-noreply@qnx.com> wrote: >> Does the attached driver work for you? If not, can you please start the >> driver with "verbose=3" and post the sloginfo output. >> >> >Didn't work. Sloginfo ouput attached. Nicinfo shows incoming packets. >It's important to note our cisco switch takes around 30 seconds to >auto-negoticate and do some fancy test detection before showing the port >as active. Though I'd mention it in case it could be related. > > >> >> On 2012-09-07 2:41 PM, "Mario Charest" <community-noreply@qnx.com> >>wrote: >> >> > >> >At the time this post was written, the latest driver I have on hand ( >> >date is 2012/05/03, experimental ) works on that chipset but the one >>with >> >SP1 doesn't. It detects the NIC but it always reports a speed of 0 half >> >duplex. But the SP1 driver is data 2012/06/20. Is it because something >> >go broken or the experimental driver has some changes that didn't make >>it >> >into SP1? >> > >> > >> > >> > >> > >> >_______________________________________________ >> > >> >Networking Drivers >> >http://community.qnx.com/sf/go/post95454 >> >To cancel your subscription to this discussion, please e-mail >> >drivers-networking-unsubscribe@community.qnx.com >> > > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95456 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Mon, 10 Sep 2012 12:26:21 GMT http://community.qnx.com/sf/go/post95464 Hugh Brown 2012-09-10T12:26:21Z http://community.qnx.com/sf/go/post95456 > Does the attached driver work for you? If not, can you please start the > driver with "verbose=3" and post the sloginfo output. > > Didn't work. Sloginfo ouput attached. Nicinfo shows incoming packets. It's important to note our cisco switch takes around 30 seconds to auto-negoticate and do some fancy test detection before showing the port as active. Though I'd mention it in case it could be related. > > On 2012-09-07 2:41 PM, "Mario Charest" <community-noreply@qnx.com> wrote: > > > > >At the time this post was written, the latest driver I have on hand ( > >date is 2012/05/03, experimental ) works on that chipset but the one with > >SP1 doesn't. It detects the NIC but it always reports a speed of 0 half > >duplex. But the SP1 driver is data 2012/06/20. Is it because something > >go broken or the experimental driver has some changes that didn't make it > >into SP1? > > > > > > > > > > > >_______________________________________________ > > > >Networking Drivers > >http://community.qnx.com/sf/go/post95454 > >To cancel your subscription to this discussion, please e-mail > >drivers-networking-unsubscribe@community.qnx.com > Fri, 07 Sep 2012 19:45:52 GMT http://community.qnx.com/sf/go/post95456 Mario Charest 2012-09-07T19:45:52Z http://community.qnx.com/sf/go/post95455 Does the attached driver work for you? If not, can you please start the driver with "verbose=3" and post the sloginfo output. On 2012-09-07 2:41 PM, "Mario Charest" <community-noreply@qnx.com> wrote: > >At the time this post was written, the latest driver I have on hand ( >date is 2012/05/03, experimental ) works on that chipset but the one with >SP1 doesn't. It detects the NIC but it always reports a speed of 0 half >duplex. But the SP1 driver is data 2012/06/20. Is it because something >go broken or the experimental driver has some changes that didn't make it >into SP1? > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95454 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Fri, 07 Sep 2012 18:57:18 GMT http://community.qnx.com/sf/go/post95455 Hugh Brown 2012-09-07T18:57:18Z http://community.qnx.com/sf/go/post95454 At the time this post was written, the latest driver I have on hand ( date is 2012/05/03, experimental ) works on that chipset but the one with SP1 doesn't. It detects the NIC but it always reports a speed of 0 half duplex. But the SP1 driver is data 2012/06/20. Is it because something go broken or the experimental driver has some changes that didn't make it into SP1? Fri, 07 Sep 2012 18:41:58 GMT http://community.qnx.com/sf/go/post95454 Mario Charest 2012-09-07T18:41:58Z http://community.qnx.com/sf/go/post95353 Well if you changed the interrupt, that sounds like the problem. What interrupt are you using? On 2012-09-03 11:31 PM, "yu zhe" <community-noreply@qnx.com> wrote: >hi, our old project used smc9000.so for MX chip, and it works fine. for >now, we changed the reset pin and interrupt pin in the new release. and >the sloginfo is like below: > >unable to attach to pci server . no such file or directory. >couldn't initialize listen services: tcp >(address family not supported by protocol family) > >what caused the errors above? besides, can u provide the driver source >of smc9000.so? > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95342 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 04 Sep 2012 12:41:05 GMT http://community.qnx.com/sf/go/post95353 Hugh Brown 2012-09-04T12:41:05Z http://community.qnx.com/sf/go/post95342 hi, our old project used smc9000.so for MX chip, and it works fine. for now, we changed the reset pin and interrupt pin in the new release. and the sloginfo is like below: unable to attach to pci server . no such file or directory. couldn't initialize listen services: tcp (address family not supported by protocol family) what caused the errors above? besides, can u provide the driver source of smc9000.so? Tue, 04 Sep 2012 03:31:52 GMT http://community.qnx.com/sf/go/post95342 yu zhe 2012-09-04T03:31:52Z http://community.qnx.com/sf/go/post95292 I have a similar problem. Bought a Belkin F5D7050, plugged into a powered hub and ran the following commands: io-pkt-v4-hc -d /fs/hd1/lib/devnp-rum.so wpa_supplicant -B -i rum0 -c /fs/hd1/etc/wpa_supplicant.conf my conf file: network={ ssid="mgtsciences" key_mgmt=WPA-PSK psk="abcdefghij" } ifconfig shows: rum0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ssid "" nwkey 65536:"","","","" powersave off address: 94:44:52:03:ad:89 media: IEEE802.11 autoselect (DS1 mode 11g) status: no network sloginfo shows: Jan 16 08:39:59 5 14 0 USB device vendor 0x50d, device 0x705a matched. Jan 16 08:39:59 5 14 0 rum0 at pci0 dev 0 function 0rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528, address 94:44:52:03:ad:89 Jan 16 08:39:59 5 14 0 ether_ifattach: rum0 null if_stop Jan 16 08:39:59 5 14 0 rum0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Jan 16 08:39:59 5 14 0 rum0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Jan 16 08:42:46 5 14 0 USB error 0x06000000 encountered in io-pkt. Jan 16 08:42:51 5 14 0 USB error 0x06000000 encountered in io-pkt. Jan 16 08:43:03 5 14 0 USB error 0x06000000 encountered in io-pkt. Jan 16 08:43:08 5 14 0 USB error 0x06000000 encountered in io-pkt. Jan 16 08:43:20 5 14 0 USB error 0x06000000 encountered in io-pkt. Jan 16 08:43:31 5 14 0 USB error 0x06000000 encountered in io-pkt. Any ideas? Thanks, Todd > What type of target platform are you on? We have seen errors like that > when the target wasn't capable of supplying enough power to the dongle. > In those instances, we recommended plugging the dongle into a powered > USB hub and that usually fixed things. > > R. > > -----Original Message----- > From: Agoston Feher [mailto:community-noreply@qnx.com] > Sent: Tuesday, April 14, 2009 12:35 PM > To: drivers-networking > Subject: USB WiFi hangs > > Hi, > > i have an issue with usb wifi connection i use io-pkt-v4-hc, the > devnp-rum.so driver mounts without problem, i configure the network with > wpa_supplicant, and i get ip address with dhcp everything seems fine but > after some time - usually during heavy network traffic - the connection > hangs. > the board only has usb 1.1 controller but it should be compatible as far > as i know. i also tried to limit the wifi speed by setting the mode and > media parameters of the driver to different values but i had the same > results. > > the board is Advantech PCI-6871 > the usb stick is ASUS WL-167g > > here is the output from sloginfo: > Jan 12 00:09:03 5 14 0 en0USB device vendor 0xb05, device > 0x1723 matched. > Jan 12 00:09:03 5 14 0 rum0 at pci0 dev 0 function 0rum0: > MAC/BBP RT2573 (rev 0x2573a), RF RT2528, address 00:1b:fc:8f:ff:96 > Jan 12 00:09:03 5 14 0 ether_ifattach: rum0 null if_stop > Jan 12 00:09:03 5 14 0 rum0: 11b rates: 1Mbps 2Mbps 5.5Mbps > 11Mbps > Jan 12 00:09:03 5 14 0 rum0: 11g rates: 1Mbps 2Mbps 5.5Mbps > 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > > Jan 12 00:11:38 5 14 0 rum0: device timeout > Jan 12 00:11:39 5 14 0 USB error 0x06000000 encountered in > io-pkt. > Jan 12 00:11:44 5 14 0 rum0: device timeout > Jan 12 00:11:49 5 14 0 USB error 0x06000000 encountered in > io-pkt. > Jan 12 00:11:57 5 14 0 rum0: could not multi read MAC > register: NOMEM > Jan 12 00:13:34 5 14 0 rum0: could not multi read MAC > register: NOMEM > Jan 12 00:13:51 5 14 0 USB error 0x06000000 encountered in > io-pkt. > > Jan 12 00:27:40 5 14 0 rum0: timeout waiting for BBP/RF to > wakeup > Jan 12 00:27:40 5 14 0 rum0: could not multi read MAC > register: NO_ADDR > Jan 12 00:27:40 5 14 0 rum0: could not multi write MAC > register: NO_ADDR > Jan 12 00:27:40 5 14 0 rum0: could not multi write MAC > register: NO_ADDR > Jan 12 00:27:40 5 14 0 rum0: could not multi write MAC > register: NO_ADDR > > _______________________________________________ > Networking Drivers > http://community.qnx.com/sf/go/post26946 Thu, 30 Aug 2012 00:17:47 GMT http://community.qnx.com/sf/go/post95292 Todd Peterson 2012-08-30T00:17:47Z http://community.qnx.com/sf/go/post95250 Archive attached. On 2012-08-28 6:35 PM, "Todd Peterson" <community-noreply@qnx.com> wrote: >Thanks, looks like more than I want to chew on. Can we get the source >code for the rum and ural drivers? It looks like the newer RT5201USB >chipset (RF5226 & RT2571W) is pretty close to the RT2501USB chipset >(RF2528 & RT2571W). Might not be too hard to adapt the existing driver. > >> I have attached the archive. Please be advised that this is a ported >> FreeBSD driver and that there is no support for it. >> >> >> >> On 2012-08-27 12:57 PM, "Todd Peterson" <community-noreply@qnx.com> >>wrote: >> >> >Would it be possible to get the source code for the ARM version of the >> >devnp-run.so driver? >> > >> >> This device is supported by the devnp-run.so driver. I have attached >>2 >> >> versions, one for ARM and the other for x86. > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95240 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Wed, 29 Aug 2012 11:51:05 GMT http://community.qnx.com/sf/go/post95250 Hugh Brown 2012-08-29T11:51:05Z http://community.qnx.com/sf/go/post95240 Thanks, looks like more than I want to chew on. Can we get the source code for the rum and ural drivers? It looks like the newer RT5201USB chipset (RF5226 & RT2571W) is pretty close to the RT2501USB chipset (RF2528 & RT2571W). Might not be too hard to adapt the existing driver. > I have attached the archive. Please be advised that this is a ported > FreeBSD driver and that there is no support for it. > > > > On 2012-08-27 12:57 PM, "Todd Peterson" <community-noreply@qnx.com> wrote: > > >Would it be possible to get the source code for the ARM version of the > >devnp-run.so driver? > > > >> This device is supported by the devnp-run.so driver. I have attached 2 > >> versions, one for ARM and the other for x86. Tue, 28 Aug 2012 22:35:04 GMT http://community.qnx.com/sf/go/post95240 Todd Peterson 2012-08-28T22:35:04Z http://community.qnx.com/sf/go/post95157 I have attached the archive. Please be advised that this is a ported FreeBSD driver and that there is no support for it. On 2012-08-27 12:57 PM, "Todd Peterson" <community-noreply@qnx.com> wrote: >Would it be possible to get the source code for the ARM version of the >devnp-run.so driver? > >> This device is supported by the devnp-run.so driver. I have attached 2 >> versions, one for ARM and the other for x86. >> >> >> >> >> On 2012-08-08 12:53 PM, "Todd Peterson" <community-noreply@qnx.com> >>wrote: >> >> >Is there a list of supported device/vendor ids for these drivers. I >>have >> >a Linksys WUSB54GC version 3 USB 802.11g dongle, which reports with usb >> >-v command: >> ><pre> >> >Vendor : 0x1737 (Ralink) >> >Product : 0x0077 (802.11 g WLAN) >> ></pre> >> >Neither driver recognizes the device: >> ><pre> >> ># io-pkt-v4-hc -drum >> ># sloginfo >> >Feb 03 01:12:11 2 14 0 Unable to init devnp-rum.so: No such >> >device or address >> ></pre> >> > >> > >> > >> >_______________________________________________ >> > >> >Networking Drivers >> >http://community.qnx.com/sf/go/post94696 >> >To cancel your subscription to this discussion, please e-mail >> >drivers-networking-unsubscribe@community.qnx.com >> > > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post95156 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Mon, 27 Aug 2012 17:11:35 GMT http://community.qnx.com/sf/go/post95157 Hugh Brown 2012-08-27T17:11:35Z http://community.qnx.com/sf/go/post95156 Would it be possible to get the source code for the ARM version of the devnp-run.so driver? > This device is supported by the devnp-run.so driver. I have attached 2 > versions, one for ARM and the other for x86. > > > > > On 2012-08-08 12:53 PM, "Todd Peterson" <community-noreply@qnx.com> wrote: > > >Is there a list of supported device/vendor ids for these drivers. I have > >a Linksys WUSB54GC version 3 USB 802.11g dongle, which reports with usb > >-v command: > ><pre> > >Vendor : 0x1737 (Ralink) > >Product : 0x0077 (802.11 g WLAN) > ></pre> > >Neither driver recognizes the device: > ><pre> > ># io-pkt-v4-hc -drum > ># sloginfo > >Feb 03 01:12:11 2 14 0 Unable to init devnp-rum.so: No such > >device or address > ></pre> > > > > > > > >_______________________________________________ > > > >Networking Drivers > >http://community.qnx.com/sf/go/post94696 > >To cancel your subscription to this discussion, please e-mail > >drivers-networking-unsubscribe@community.qnx.com > Mon, 27 Aug 2012 16:57:58 GMT http://community.qnx.com/sf/go/post95156 Todd Peterson 2012-08-27T16:57:58Z http://community.qnx.com/sf/go/post95061 Hello Ravish , Did you get snmptrap configuration details ? Regards, Naresh Kumar Thu, 23 Aug 2012 05:21:47 GMT http://community.qnx.com/sf/go/post95061 Naresh Kumar 2012-08-23T05:21:47Z http://community.qnx.com/sf/go/post94784 Hi all: I've run into an icky issue with the porting of the netbsd wifi driver. The code uses async usb tasks which I have absolutely no idea how to implement in qnx. These tasks are also ordered in a task queue. Can anyone shed any light on a possible approach? I am currently testing nw_pthread_create in the attach but getting error 22... Any advice would be much appreciated, thanks in advance. B/R Jim Tan On Thu, May 10, 2012 at 9:30 PM, Jim Tan <shinjiuh@gmail.com> wrote: > Hi everyone ! > > I'm a newcomer to qnx 6.5.0. I have a USB wifi dongle (Zyxel NWD2205) that > I need to setup an ad-hoc network with. Apparently, the chipset is realtek > rtl8192cu, qnx doesn't have any driver support for this module. Netbsd does > have the driver tho. > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/?only_with_tag=MAIN > (if_urtwn.c, if_urtwn_data.h, if_urtwnreg.h and if_urtwnvar.h) > > I also have the linux drivers from realtek site... > > What should I do at this point in time ? Can I simply download the 4 files > from netbsd, create a qnx C project in momentics and make a devnp-urtwn.so > target ? Or am I going about this in the wrong way? Is there a > comprehensive guide that I can refer to about porting netbsd drivers ? > Also, how should I make this driver available for other qnx users like > myself ? > > Any help would be much appreciated, thanks. > > B/R > Jim Tan > Mon, 13 Aug 2012 14:23:31 GMT http://community.qnx.com/sf/go/post94784 Jim Tan 2012-08-13T14:23:31Z http://community.qnx.com/sf/go/post94730 Only the drivers that you previously mentioned. The devnp-rum.so driver supports the Ralink RT2501/2601USB chipsets and the devnp-ural.so driver supports the Ralink RT2500USB chipset. We don't have the vendor names of dongles that contain these chipsets. On 2012-08-09 1:37 PM, "Todd Peterson" <community-noreply@qnx.com> wrote: >Ok, understood. Is there a list of wireless USB dongles supported by the >released drivers? Or just a suggested dongle? > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94729 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 09 Aug 2012 17:44:49 GMT http://community.qnx.com/sf/go/post94730 Hugh Brown 2012-08-09T17:44:49Z http://community.qnx.com/sf/go/post94729 Ok, understood. Is there a list of wireless USB dongles supported by the released drivers? Or just a suggested dongle? Thu, 09 Aug 2012 17:37:51 GMT http://community.qnx.com/sf/go/post94729 Todd Peterson 2012-08-09T17:37:51Z http://community.qnx.com/sf/go/post94727 Unfortunately this is an experimental/un-supported driver that was ported from a FreeBSD driver and hasn't gone through any official testing, so that is why it isn't released. On 2012-08-09 12:23 PM, "Todd Peterson" <community-noreply@qnx.com> wrote: >Thanks for the drivers! I'm still having some issues. I can associate >with our office network, but can't seem to do anything useful (ping, >telnet, etc.). I notice that the system log gets swamped with messages >from the driver (attached). I also see that the driver is using 25% of >the CPU. My hardware is a Beagleboard-xM and I am running QNX 6.4.2. > >Commands I run to reproduce the behavior: >io-pkt-v4-hc -d /fs/hd1/lib/devnp-run.so >wpa_supplicant -B -i run0 -c /fs/hd1/etc/wpa_supplicant.conf >ifconfig run0 172.23.93.19 >ifconfig >lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 > inet 127.0.0.1 netmask 0xff000000 >run0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > ssid mgtsciences nwkey 65536:"","","","" > powersave off > bssid 00:09:5b:a1:89:2b chan 9 > address: 00:23:69:e0:27:8f > media: IEEE802.11 autoselect (DS1 mode 11g) > status: active > inet 172.23.93.193 netmask 0xffff0000 broadcast 172.23.255.255 > >sloginfo > sloginfo.txt > >Here is my wpa_supplicant.conf: > >network={ >ssid="mgtsciences" >key_mgmt=WPA-PSK >psk="abcdefghij" >} > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94723 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 09 Aug 2012 17:13:43 GMT http://community.qnx.com/sf/go/post94727 Hugh Brown 2012-08-09T17:13:43Z http://community.qnx.com/sf/go/post94723 Thanks for the drivers! I'm still having some issues. I can associate with our office network, but can't seem to do anything useful (ping, telnet, etc.). I notice that the system log gets swamped with messages from the driver (attached). I also see that the driver is using 25% of the CPU. My hardware is a Beagleboard-xM and I am running QNX 6.4.2. Commands I run to reproduce the behavior: io-pkt-v4-hc -d /fs/hd1/lib/devnp-run.so wpa_supplicant -B -i run0 -c /fs/hd1/etc/wpa_supplicant.conf ifconfig run0 172.23.93.19 ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 run0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ssid mgtsciences nwkey 65536:"","","","" powersave off bssid 00:09:5b:a1:89:2b chan 9 address: 00:23:69:e0:27:8f media: IEEE802.11 autoselect (DS1 mode 11g) status: active inet 172.23.93.193 netmask 0xffff0000 broadcast 172.23.255.255 sloginfo > sloginfo.txt Here is my wpa_supplicant.conf: network={ ssid="mgtsciences" key_mgmt=WPA-PSK psk="abcdefghij" } Thu, 09 Aug 2012 16:23:58 GMT http://community.qnx.com/sf/go/post94723 Todd Peterson 2012-08-09T16:23:58Z http://community.qnx.com/sf/go/post94698 This device is supported by the devnp-run.so driver. I have attached 2 versions, one for ARM and the other for x86. On 2012-08-08 12:53 PM, "Todd Peterson" <community-noreply@qnx.com> wrote: >Is there a list of supported device/vendor ids for these drivers. I have >a Linksys WUSB54GC version 3 USB 802.11g dongle, which reports with usb >-v command: ><pre> >Vendor : 0x1737 (Ralink) >Product : 0x0077 (802.11 g WLAN) ></pre> >Neither driver recognizes the device: ><pre> ># io-pkt-v4-hc -drum ># sloginfo >Feb 03 01:12:11 2 14 0 Unable to init devnp-rum.so: No such >device or address ></pre> > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94696 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Wed, 08 Aug 2012 17:15:14 GMT http://community.qnx.com/sf/go/post94698 Hugh Brown 2012-08-08T17:15:14Z http://community.qnx.com/sf/go/post94696 Is there a list of supported device/vendor ids for these drivers. I have a Linksys WUSB54GC version 3 USB 802.11g dongle, which reports with usb -v command: <pre> Vendor : 0x1737 (Ralink) Product : 0x0077 (802.11 g WLAN) </pre> Neither driver recognizes the device: <pre> # io-pkt-v4-hc -drum # sloginfo Feb 03 01:12:11 2 14 0 Unable to init devnp-rum.so: No such device or address </pre> Wed, 08 Aug 2012 16:53:53 GMT http://community.qnx.com/sf/go/post94696 Todd Peterson 2012-08-08T16:53:53Z http://community.qnx.com/sf/go/post94684 No, this is in the libc library. On 2012-08-07 3:41 PM, "Wen Xu" <community-noreply@qnx.com> wrote: >> I don't think so. There is a reference count for each open of the shared >> memory object and it is only destroyed when the reference count is zero. >> >> >> >> >Thanks.That's what I am thinking about. Is there anyway to get the >reference count? Any API? > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94683 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 07 Aug 2012 19:43:27 GMT http://community.qnx.com/sf/go/post94684 Hugh Brown 2012-08-07T19:43:27Z http://community.qnx.com/sf/go/post94683 > I don't think so. There is a reference count for each open of the shared > memory object and it is only destroyed when the reference count is zero. > > > > Thanks.That's what I am thinking about. Is there anyway to get the reference count? Any API? Tue, 07 Aug 2012 19:41:42 GMT http://community.qnx.com/sf/go/post94683 Wen Xu 2012-08-07T19:41:42Z http://community.qnx.com/sf/go/post94682 I don't think so. There is a reference count for each open of the shared memory object and it is only destroyed when the reference count is zero. On 2012-08-07 2:38 PM, "Wen Xu" <community-noreply@qnx.com> wrote: >> The file will only be removed once all references to it have been >>removed, >> so if another process has the filename open, it will only be removed >>once >> that process releases it. >> > >Thanks. The problem is, the shr mem object is created/reads/writes in >io-pkt-v4 process. >The other process reads/write to the shr mem. When io-pkt-v4 is slayed or >exits, I wish the mem object to be destroyed. It's okay that the other >process could no longer have access to the shr mem. Is there any way to >achieve that? > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94681 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 07 Aug 2012 19:19:37 GMT http://community.qnx.com/sf/go/post94682 Hugh Brown 2012-08-07T19:19:37Z http://community.qnx.com/sf/go/post94681 > The file will only be removed once all references to it have been removed, > so if another process has the filename open, it will only be removed once > that process releases it. > Thanks. The problem is, the shr mem object is created/reads/writes in io-pkt-v4 process. The other process reads/write to the shr mem. When io-pkt-v4 is slayed or exits, I wish the mem object to be destroyed. It's okay that the other process could no longer have access to the shr mem. Is there any way to achieve that? Tue, 07 Aug 2012 18:38:49 GMT http://community.qnx.com/sf/go/post94681 Wen Xu 2012-08-07T18:38:49Z http://community.qnx.com/sf/go/post94677 The file will only be removed once all references to it have been removed, so if another process has the filename open, it will only be removed once that process releases it. On 2012-08-07 12:40 PM, "Wen Xu" <community-noreply@qnx.com> wrote: >> You would do this in the mpc85xx_stop routine. >> >> >> >> >> On 2012-08-06 5:39 PM, "Wen Xu" <community-noreply@qnx.com> wrote: >> >> >Hi, >> > >> >I created a shared mem object by calling shm_open() in the function >> >mpc85xx_attach() e.g. >> > >> > fd = shm_open( fileName, O_RDWR | O_CREAT, 0777 ); >> > >> >I wish to destroy this shared mem object when io-pkt-v4 exits for some >> >reason (e.g. being slayed). >> > >> >In which function should I call the function shm_unlink(fileName); >> > >> >Thanks. >> > >> > >> > > > >Thanks. As suggested shm_unlink() is called in the function >mpc85xx_stop(). >However, after I issue the command "slay io-pkt-v4", this shared mem >object is still accessible >from another process. Would you please suggest why the share mem object >is not destroyed successfully? > >e.g. > >static void >mpc85xx_stop(struct ifnet *ifp, int disable) >{ >.... >if (disable) >{ >shm_unlink(fileName); >} >} > > > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94676 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 07 Aug 2012 16:44:35 GMT http://community.qnx.com/sf/go/post94677 Hugh Brown 2012-08-07T16:44:35Z http://community.qnx.com/sf/go/post94676 > You would do this in the mpc85xx_stop routine. > > > > > On 2012-08-06 5:39 PM, "Wen Xu" <community-noreply@qnx.com> wrote: > > >Hi, > > > >I created a shared mem object by calling shm_open() in the function > >mpc85xx_attach() e.g. > > > > fd = shm_open( fileName, O_RDWR | O_CREAT, 0777 ); > > > >I wish to destroy this shared mem object when io-pkt-v4 exits for some > >reason (e.g. being slayed). > > > >In which function should I call the function shm_unlink(fileName); > > > >Thanks. > > > > > > Thanks. As suggested shm_unlink() is called in the function mpc85xx_stop(). However, after I issue the command "slay io-pkt-v4", this shared mem object is still accessible from another process. Would you please suggest why the share mem object is not destroyed successfully? e.g. static void mpc85xx_stop(struct ifnet *ifp, int disable) { .... if (disable) { shm_unlink(fileName); } } Tue, 07 Aug 2012 16:40:32 GMT http://community.qnx.com/sf/go/post94676 Wen Xu 2012-08-07T16:40:32Z http://community.qnx.com/sf/go/post94667 You would do this in the mpc85xx_stop routine. On 2012-08-06 5:39 PM, "Wen Xu" <community-noreply@qnx.com> wrote: >Hi, > >I created a shared mem object by calling shm_open() in the function >mpc85xx_attach() e.g. > > fd = shm_open( fileName, O_RDWR | O_CREAT, 0777 ); > >I wish to destroy this shared mem object when io-pkt-v4 exits for some >reason (e.g. being slayed). > >In which function should I call the function shm_unlink(fileName); > >Thanks. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94661 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 07 Aug 2012 11:30:47 GMT http://community.qnx.com/sf/go/post94667 Hugh Brown 2012-08-07T11:30:47Z http://community.qnx.com/sf/go/post94666 You can edit the /etc/rc.d/rc.local file and in that script file, slay io-pkt and re-start it with whatever parameters you need. If that doesn't work, then you can always edit the /etc/system/enum/devices/net file and remove the line(s) for your device ID, so the driver won't be started automatically. You can then start the driver in the /etc/rc.d/rc.local file. On 2012-08-05 7:36 PM, "Roger Marley" <community-noreply@qnx.com> wrote: >The problem is that I need to slay io-pkt first, which I cannot do. > >Is there a system config file or startup script which is used to start >io-pkt on startup? If so I could just modify it. >Otherwise, is there a way of preventing io-pkt from starting on boot (a >'safe mode, no networking' or something like that)? > >Cheers, Roger > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94652 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Tue, 07 Aug 2012 11:27:31 GMT http://community.qnx.com/sf/go/post94666 Hugh Brown 2012-08-07T11:27:31Z http://community.qnx.com/sf/go/post94661 Hi, I created a shared mem object by calling shm_open() in the function mpc85xx_attach() e.g. fd = shm_open( fileName, O_RDWR | O_CREAT, 0777 ); I wish to destroy this shared mem object when io-pkt-v4 exits for some reason (e.g. being slayed). In which function should I call the function shm_unlink(fileName); Thanks. Mon, 06 Aug 2012 21:39:55 GMT http://community.qnx.com/sf/go/post94661 Wen Xu 2012-08-06T21:39:55Z http://community.qnx.com/sf/go/post94652 The problem is that I need to slay io-pkt first, which I cannot do. Is there a system config file or startup script which is used to start io-pkt on startup? If so I could just modify it. Otherwise, is there a way of preventing io-pkt from starting on boot (a 'safe mode, no networking' or something like that)? Cheers, Roger Sun, 05 Aug 2012 23:36:39 GMT http://community.qnx.com/sf/go/post94652 Roger Marley 2012-08-05T23:36:39Z http://community.qnx.com/sf/go/post94635 You have to use the APIC version of the build file to create a boot image that will support MSI/MSI-X. pci-bios-v2 alone won't give you MSI. On 2012-08-03 12:14 PM, "James VanOeffelen" <community-noreply@qnx.com> wrote: >I created a new build of 6.5.0 SP1 using pci-bios-v2. My board has an >intel 82574L which is capable of MSI and MSI-X. However, when I run the >system it appears it is still using a hardline interrupt. How can I tell >if MSI is working? Should the interrupt line be something higher than 15 >when MSI is working or am I looking in the wrong place? > >My issue is that I have two 82574L based ports. One gets IRQ5 and the >other IRQ11. Well, my USB is getting IRQ10 and IRQ11. So the NIC with >IRQ11 becomes unstable when using the USB while the net traffic is heavy. >So I was hoping MSI would solve my problem by getting the NICs off the >legacy lines. > >A PCI output is attached. > >Any insight would be greatly welcomed. > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94633 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Fri, 03 Aug 2012 16:22:06 GMT http://community.qnx.com/sf/go/post94635 Hugh Brown 2012-08-03T16:22:06Z http://community.qnx.com/sf/go/post94633 I created a new build of 6.5.0 SP1 using pci-bios-v2. My board has an intel 82574L which is capable of MSI and MSI-X. However, when I run the system it appears it is still using a hardline interrupt. How can I tell if MSI is working? Should the interrupt line be something higher than 15 when MSI is working or am I looking in the wrong place? My issue is that I have two 82574L based ports. One gets IRQ5 and the other IRQ11. Well, my USB is getting IRQ10 and IRQ11. So the NIC with IRQ11 becomes unstable when using the USB while the net traffic is heavy. So I was hoping MSI would solve my problem by getting the NICs off the legacy lines. A PCI output is attached. Any insight would be greatly welcomed. Fri, 03 Aug 2012 16:14:00 GMT http://community.qnx.com/sf/go/post94633 James VanOeffelen 2012-08-03T16:14:00Z http://community.qnx.com/sf/go/post94625 You can try starting the driver in verbose mode and see if there is anything in sloginfo. (io-pkt-v4 -drtl8169 verbose=3). If there is nothing in sloginfo, then I will only be able to do something with the driver if I have the hardware. On 2012-08-02 9:14 PM, "Roger Marley" <community-noreply@qnx.com> wrote: >OK thanks Hugh, >I have tried the new driver but it has not effected the problem. >We have some different machines which run the same OS and driver, and >they have no problem slaying and restarting io-pkt. Could it be somehow >related to the hardware? Another thread about a different io-pkt slaying >problem mentioned something about interrupts. Also is there any error log >which would shed light on the issue (I checked sloginfo but there was >nothing)? > >Cheers, Roger > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94618 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Fri, 03 Aug 2012 11:35:33 GMT http://community.qnx.com/sf/go/post94625 Hugh Brown 2012-08-03T11:35:33Z http://community.qnx.com/sf/go/post94618 OK thanks Hugh, I have tried the new driver but it has not effected the problem. We have some different machines which run the same OS and driver, and they have no problem slaying and restarting io-pkt. Could it be somehow related to the hardware? Another thread about a different io-pkt slaying problem mentioned something about interrupts. Also is there any error log which would shed light on the issue (I checked sloginfo but there was nothing)? Cheers, Roger Fri, 03 Aug 2012 01:14:19 GMT http://community.qnx.com/sf/go/post94618 Roger Marley 2012-08-03T01:14:19Z http://community.qnx.com/sf/go/post94611 Hi all, Thank you for all the responses and help. As Hugh had suggested, I used a powered USB Hub on Board2 and then removed the dongle on board1 and connected to the ethernet port on the board, and it works now. I can ping one from the other and vice-versa. So now, board1 has all 0's mac address and board2 has the same configuration as mentioned above. Thanks, Johnson Thu, 02 Aug 2012 19:19:11 GMT http://community.qnx.com/sf/go/post94611 Johnson Thomas 2012-08-02T19:19:11Z http://community.qnx.com/sf/go/post94609 It sounds a little too simple, but did you try both boards (individually) connected to the desktop? (i.e. dev1 <-> desktop, then dev2 <-> desktop) There could be something wrong with Ethernet connector or transceiver on one of the Asix dongles (it's rare, but I have seen it before). -----Original Message----- From: Hugh Brown [mailto:community-noreply@qnx.com] Sent: August-02-12 2:17 PM To: drivers-networking@community.qnx.com Subject: Re: Unable to ping one pandaboard from another with both having QNX on it I can only imagine that there is not enough power on the USB ports to power the dongle as well as the link. Try connecting the dongles via a USB hub. On 2012-08-02 1:55 PM, "Johnson Thomas" <community-noreply@qnx.com> wrote: >Thanks for the quick response. > >I just added that as part of my various attempts to get the ping working. >Even if I remove that, the issue exists. > >Note: I had tried connecting one of the pandaboard to a desktop using >the same crosswire ethernet cable. So basically the same setup as >mentioned above, with one pandaboard replaced with a Desktop. >Everything works fine. I can ping from the pandaboard to the Desktop >and other way round too. The Desktop had the same IP/netmask as BOARD2 mentioned above. > >Thanks, >Johnson > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94603 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post94608 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Thu, 02 Aug 2012 18:25:25 GMT http://community.qnx.com/sf/go/post94609 Dean Denter 2012-08-02T18:25:25Z http://community.qnx.com/sf/go/post94608 I can only imagine that there is not enough power on the USB ports to power the dongle as well as the link. Try connecting the dongles via a USB hub. On 2012-08-02 1:55 PM, "Johnson Thomas" <community-noreply@qnx.com> wrote: >Thanks for the quick response. > >I just added that as part of my various attempts to get the ping working. >Even if I remove that, the issue exists. > >Note: I had tried connecting one of the pandaboard to a desktop using the >same crosswire ethernet cable. So basically the same setup as mentioned >above, with one pandaboard replaced with a Desktop. Everything works >fine. I can ping from the pandaboard to the Desktop and other way round >too. The Desktop had the same IP/netmask as BOARD2 mentioned above. > >Thanks, >Johnson > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94603 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 02 Aug 2012 18:21:06 GMT http://community.qnx.com/sf/go/post94608 Hugh Brown 2012-08-02T18:21:06Z http://community.qnx.com/sf/go/post94607 The <MAC ADDRESS> is the mac addresses on the respective boards. I am not giving it a different mac address. I dont know how to check the version of devn-asix.so, but the build version of the QNX BSP for pandaboard that I am using is 201203081153, if that helps. Thanks, Johnson Thu, 02 Aug 2012 18:17:33 GMT http://community.qnx.com/sf/go/post94607 Johnson Thomas 2012-08-02T18:17:33Z http://community.qnx.com/sf/go/post94603 Thanks for the quick response. I just added that as part of my various attempts to get the ping working. Even if I remove that, the issue exists. Note: I had tried connecting one of the pandaboard to a desktop using the same crosswire ethernet cable. So basically the same setup as mentioned above, with one pandaboard replaced with a Desktop. Everything works fine. I can ping from the pandaboard to the Desktop and other way round too. The Desktop had the same IP/netmask as BOARD2 mentioned above. Thanks, Johnson Thu, 02 Aug 2012 17:55:19 GMT http://community.qnx.com/sf/go/post94603 Johnson Thomas 2012-08-02T17:55:19Z http://community.qnx.com/sf/go/post94601 What is <MAC ADDRESS>? Why are you specifying it if the Asix dongle already has a MAC address? On 2012-08-02 12:51 PM, "Johnson Thomas" <community-noreply@qnx.com> wrote: >Hi all, > >I have QNX 6.5.0 running on two pandaboards (Board1 & Board2) connected >by a crosswire ethernet cable. I am using a ASIX USB to Ethernet dongle >on both the boards since for some reason the mac address of the ethernet >port on both boards are all 0's. I use the following lines in the build >script to start up io-pkt-v4 > > io-pkt-v4 -dasix promiscuous,mac=<MAC ADDRESS>,verbose=4 -ptcpip > waitfor /dev/socket > if_up -p en0 > display_msg Getting Static IP > ifconfig en0 <IP> netmask 255.255.254.0 > ifconfig en0 > >The following are the sloginfo for both boards > >Board 1 >Time Sev Major Minor Args >Jan 01 00:00:00 2 19 1800 devb-mmcsd-blaze 1.00A (Aug 2 2012 >12:28:51) >Jan 01 00:00:00 2 5 0 libcam.so (Jun 15 2010 01:01:35) bver >6040207 >Jan 01 00:00:00 2 5 100 cam-disk.so (Jun 15 2010 01:01:50) >Jan 01 00:00:02 5 14 0 tcpip starting >Jan 01 00:00:02 3 14 0 Unable to attach to pci server: No such >file or directory >Jan 01 00:00:02 3 14 0 Using pseudo random generator. See >"random" option >Jan 01 00:00:03 5 14 0 devn-ax: MII transceiver found at >address 16. >Jan 01 00:00:03 5 14 0 io-pkt shim >Jan 01 00:00:03 5 14 0 Vendor .............. 0x0 >Jan 01 00:00:03 5 14 0 Device .............. 0x0 >Jan 01 00:00:03 5 14 0 Revision ............ 0x0 >Jan 01 00:00:03 5 14 0 MAC address ......... 0050b6 0a3c66 >Jan 01 00:00:03 5 14 0 Asix >Jan 01 00:00:03 5 14 0 LanIdx .............. 18 >Jan 01 00:00:03 5 14 0 DevIdx .............. 0 >Jan 01 00:00:03 5 14 0 Vendor .............. 0xb95 >Jan 01 00:00:03 5 14 0 Device .............. 0x7720 >Jan 01 00:00:03 5 14 0 Revision ............ 0x0 >Jan 01 00:00:03 5 14 0 MAC address ......... <MAC ADDRESS> >Jan 01 00:00:06 5 10 0 devn-ax: link up (100 BaseT Full Duplex) > > >Board2 >Time Sev Major Minor Args >Jan 01 00:00:00 2 19 1800 devb-mmcsd-blaze 1.00A (Aug 2 2012 >12:26:08) >Jan 01 00:00:00 2 5 0 libcam.so (Jun 15 2010 01:01:35) bver >6040207 >Jan 01 00:00:00 2 5 100 cam-disk.so (Jun 15 2010 01:01:50) >Jan 01 00:00:02 5 14 0 tcpip starting >Jan 01 00:00:02 3 14 0 Unable to attach to pci server: No such >file or directory >Jan 01 00:00:02 3 14 0 Using pseudo random generator. See >"random" option >Jan 01 00:00:03 5 14 0 devn-ax: MII transceiver found at >address 16. >Jan 01 00:00:03 5 14 0 io-pkt shim >Jan 01 00:00:03 5 14 0 Vendor .............. 0x0 >Jan 01 00:00:03 5 14 0 Device .............. 0x0 >Jan 01 00:00:03 5 14 0 Revision ............ 0x0 >Jan 01 00:00:03 5 14 0 MAC address ......... 0050b6 0a546c >Jan 01 00:00:03 5 14 0 Asix >Jan 01 00:00:03 5 14 0 LanIdx .............. 18 >Jan 01 00:00:03 5 14 0 DevIdx .............. 0 >Jan 01 00:00:03 5 14 0 Vendor .............. 0xb95 >Jan 01 00:00:03 5 14 0 Device .............. 0x7720 >Jan 01 00:00:03 5 14 0 Revision ............ 0x0 >Jan 01 00:00:03 5 14 0 MAC address ......... <MAC ADDRESS> >Jan 01 00:00:36 5 10 0 devn-ax: link up (100 BaseT Full Duplex) > >nicinfo: > >Board1 >en0: > Asix Ethernet Controller > > Physical Node ID ........................... <MAC ADDRESS> > Current Physical Node ID ................... <MAC ADDRESS> > Current Operation Rate ..................... 100.00 Mb/s full-duplex > Active Interface Type ...................... MII > Active PHY address ....................... 16 > Maximum Transmittable data Unit ............ 1514 > Maximum Receivable data Unit ............... 1514 > Promiscuous Mode ........................... Off > Multicast Support .......................... Enabled > > Packets Transmitted OK ..................... 6 > Bytes Transmitted OK ....................... 252 > Broadcast Packets Transmitted OK ........... 6 > Multicast Packets Transmitted OK ........... 0 > > Packets Received OK ........................ 0 > Bytes Received OK .......................... 0 > Broadcast Packets Received OK .............. 0 > 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 > Transmit Underruns ......................... 0 > No Carrier on Transmit ..................... 0 > Receive Alignment errors ................... 0 > Received packets with CRC errors ........... 0 > Packets Dropped on receive ................. 0 > Short packets .............................. 0 > Total Frames experiencing Collison(s) ...... 0 > > >Board2: >en0: > Asix Ethernet Controller > > Physical Node ID ........................... <MAC ADDRESS> > Current Physical Node ID ................... <MAC ADDRESS> > Current Operation Rate ..................... 100.00 Mb/s full-duplex > Active Interface Type ...................... MII > Active PHY address ....................... 16 > Maximum Transmittable data Unit ............ 1514 > Maximum Receivable data Unit ............... 1514 > Promiscuous Mode ........................... Off > Multicast Support .......................... Enabled > > Packets Transmitted OK ..................... 1 > Bytes Transmitted OK ....................... 42 > Broadcast Packets Transmitted OK ........... 1 > Multicast Packets Transmitted OK ........... 0 > > Packets Received OK ........................ 0 > Bytes Received OK .......................... 0 > Broadcast Packets Received OK .............. 0 > 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 > Transmit Underruns ......................... 0 > No Carrier on Transmit ..................... 0 > Receive Alignment errors ................... 0 > Received packets with CRC errors ........... 0 > Packets Dropped on receive ................. 0 > Short packets .............................. 0 > Total Frames experiencing Collison(s) ...... 0 > > >ifconfig -a > >Board1 > >lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 > inet 127.0.0.1 netmask 0xff000000 >en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> >mtu 1500 > address: <MAC ADDRESS> > media: Ethernet 100baseTX full-duplex > status: active > inet 129.97.69.159 netmask 0xfffffe00 broadcast 129.97.69.255 > > >Board2 > >lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 > inet 127.0.0.1 netmask 0xff000000 >en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> >mtu 1500 > address: <MAC ADDRESS> > media: Ethernet 100baseTX full-duplex > status: active > inet 129.97.69.181 netmask 0xfffffe00 broadcast 129.97.69.255 > > >pidin irq > >Board1 > pid tid name > 1 1 /procnto-smp-instr > 1 2 /procnto-smp-instr > 0 0x45 0 -P- @0xfe0540e0:0x0 > 1 3 /procnto-smp-instr > 1 4 /procnto-smp-instr > 1 5 /procnto-smp-instr > 1 6 /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 > 4098 1 /boot/devc-seromap > 1 0x6a 0 --- @0x1025bc:0x12ba88 > 4099 1 proc/boot/slogger > 4100 1 proc/boot/pipe > 4100 2 proc/boot/pipe > 4100 3 proc/boot/pipe > 4101 1 i2c-omap35xx-omap4 > 2 0x58 0 T-- @0x10227c:0x108040 > 4102 1 i2c-omap35xx-omap4 > 3 0x59 0 T-- @0x10227c:0x108040 > 4103 1 i2c-omap35xx-omap4 > 4 0x5d 0 T-- @0x10227c:0x108040 > 4104 1 i2c-omap35xx-omap4 > 5 0x5e 0 T-- @0x10227c:0x108040 > 16393 1 t/devb-mmcsd-blaze > 16393 2 t/devb-mmcsd-blaze > 16393 3 t/devb-mmcsd-blaze > 6 0x73 0 TP- =PULSE 0x40000005:21 0x2:0 > 16393 4 t/devb-mmcsd-blaze > 16393 5 t/devb-mmcsd-blaze > 16393 6 t/devb-mmcsd-blaze > 16393 7 t/devb-mmcsd-blaze > 16394 1 oc/boot/spi-master > 16394 2 oc/boot/spi-master > 7 0x61 0 T-- @0x78001764:0x11bef0 > 16395 1 oc/boot/spi-master > 16395 2 oc/boot/spi-master > 8 0x50 0 T-- @0x78001764:0x11bef0 > 16396 1 proc/boot/io-usb > 9 0x7d 0 T-- @0x78008944:0x133948 > 11 0x6d 0 TP- =PULSE 0x4000000b:21 0:0 > 16396 2 proc/boot/io-usb > 10 0x7c 0 T-- @0x780062a0:0x138410 > 16396 3 proc/boot/io-usb > 16396 4 proc/boot/io-usb > 16396 5 proc/boot/io-usb > 16396 6 proc/boot/io-usb > 16396 7 proc/boot/io-usb > 16396 8 proc/boot/io-usb > 20493 1 roc/boot/io-pkt-v4 > 20493 2 roc/boot/io-pkt-v4 > 12 0x45 0 T-- @0x13e9bc:0x18c150 > 20493 3 roc/boot/io-pkt-v4 > 20493 4 roc/boot/io-pkt-v4 > 32782 1 proc/boot/devc-pty > 32785 1 usr/bin/pdebug > 36879 1 usr/sbin/inetd > 40976 1 bin/sh > 114706 1 proc/boot/pidin > >Board2 > pid tid name > 1 1 /procnto-smp-instr > 1 2 /procnto-smp-instr > 0 0x45 0 -P- @0xfe0540e0:0x0 > 1 3 /procnto-smp-instr > 1 4 /procnto-smp-instr > 1 6 /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 > 4098 1 /boot/devc-seromap > 1 0x6a 0 --- @0x1025bc:0x12ba88 > 4099 1 proc/boot/slogger > 4100 1 proc/boot/pipe > 4100 2 proc/boot/pipe > 4100 3 proc/boot/pipe > 4101 1 i2c-omap35xx-omap4 > 2 0x58 0 T-- @0x10227c:0x108040 > 4102 1 i2c-omap35xx-omap4 > 3 0x59 0 T-- @0x10227c:0x108040 > 4103 1 i2c-omap35xx-omap4 > 4 0x5d 0 T-- @0x10227c:0x108040 > 4104 1 i2c-omap35xx-omap4 > 5 0x5e 0 T-- @0x10227c:0x108040 > 16393 1 t/devb-mmcsd-blaze > 16393 2 t/devb-mmcsd-blaze > 16393 3 t/devb-mmcsd-blaze > 6 0x73 0 TP- =PULSE 0x40000005:21 0x2:0 > 16393 4 t/devb-mmcsd-blaze > 16393 5 t/devb-mmcsd-blaze > 16393 6 t/devb-mmcsd-blaze > 16393 7 t/devb-mmcsd-blaze > 16394 1 oc/boot/spi-master > 16394 2 oc/boot/spi-master > 7 0x61 0 T-- @0x78001764:0x11bef0 > 16395 1 oc/boot/spi-master > 16395 2 oc/boot/spi-master > 8 0x50 0 T-- @0x78001764:0x11bef0 > 16396 1 proc/boot/io-usb > 9 0x7d 0 T-- @0x78008944:0x133948 > 11 0x6d 0 TP- =PULSE 0x4000000b:21 0:0 > 16396 2 proc/boot/io-usb > 10 0x7c 0 T-- @0x780062a0:0x138410 > 16396 3 proc/boot/io-usb > 16396 4 proc/boot/io-usb > 16396 5 proc/boot/io-usb > 16396 6 proc/boot/io-usb > 16396 7 proc/boot/io-usb > 16396 8 proc/boot/io-usb > 20493 1 roc/boot/io-pkt-v4 > 20493 2 roc/boot/io-pkt-v4 > 12 0x45 0 T-- @0x13e9bc:0x18c150 > 20493 3 roc/boot/io-pkt-v4 > 20493 4 roc/boot/io-pkt-v4 > 32782 1 proc/boot/devc-pty > 32785 1 usr/bin/pdebug > 36879 1 usr/sbin/inetd > 40976 1 bin/sh > 65554 1 proc/boot/pidin > >When I try to ping one board from the other, I just get > >PING 129.97.69.181 (129.97.69.181): 56 data bytes >ping: sendto: Host is down >ping: sendto: Host is down >ping: sendto: Host is down >ping: sendto: Host is down > >The interesting thing is that SOMETIMES it works, I mean I am able to >ping one board from the other. I have searched a lot on the web to find >anything related to solve this issue, but no luck. I have no idea how to >debug this issue. > >Any help would be great. > >Thanks, >Johnson > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94599 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 02 Aug 2012 17:01:13 GMT http://community.qnx.com/sf/go/post94601 Hugh Brown 2012-08-02T17:01:13Z http://community.qnx.com/sf/go/post94600 Is your dongle consistently working by connecting to your desktop for example. We are not getting anything on either side. What is the version of your devn-asix.so? -----Original Message----- From: Johnson Thomas [mailto:community-noreply@qnx.com] Sent: Thursday, August 02, 2012 12:52 PM To: drivers-networking Subject: Unable to ping one pandaboard from another with both having QNX on it Hi all, I have QNX 6.5.0 running on two pandaboards (Board1 & Board2) connected by a crosswire ethernet cable. I am using a ASIX USB to Ethernet dongle on both the boards since for some reason the mac address of the ethernet port on both boards are all 0's. I use the following lines in the build script to start up io-pkt-v4 io-pkt-v4 -dasix promiscuous,mac=<MAC ADDRESS>,verbose=4 -ptcpip waitfor /dev/socket if_up -p en0 display_msg Getting Static IP ifconfig en0 <IP> netmask 255.255.254.0 ifconfig en0 The following are the sloginfo for both boards Board 1 Time Sev Major Minor Args Jan 01 00:00:00 2 19 1800 devb-mmcsd-blaze 1.00A (Aug 2 2012 12:28:51) Jan 01 00:00:00 2 5 0 libcam.so (Jun 15 2010 01:01:35) bver 6040207 Jan 01 00:00:00 2 5 100 cam-disk.so (Jun 15 2010 01:01:50) Jan 01 00:00:02 5 14 0 tcpip starting Jan 01 00:00:02 3 14 0 Unable to attach to pci server: No such file or directory Jan 01 00:00:02 3 14 0 Using pseudo random generator. See "random" option Jan 01 00:00:03 5 14 0 devn-ax: MII transceiver found at address 16. Jan 01 00:00:03 5 14 0 io-pkt shim Jan 01 00:00:03 5 14 0 Vendor .............. 0x0 Jan 01 00:00:03 5 14 0 Device .............. 0x0 Jan 01 00:00:03 5 14 0 Revision ............ 0x0 Jan 01 00:00:03 5 14 0 MAC address ......... 0050b6 0a3c66 Jan 01 00:00:03 5 14 0 Asix Jan 01 00:00:03 5 14 0 LanIdx .............. 18 Jan 01 00:00:03 5 14 0 DevIdx .............. 0 Jan 01 00:00:03 5 14 0 Vendor .............. 0xb95 Jan 01 00:00:03 5 14 0 Device .............. 0x7720 Jan 01 00:00:03 5 14 0 Revision ............ 0x0 Jan 01 00:00:03 5 14 0 MAC address ......... <MAC ADDRESS> Jan 01 00:00:06 5 10 0 devn-ax: link up (100 BaseT Full Duplex) Board2 Time Sev Major Minor Args Jan 01 00:00:00 2 19 1800 devb-mmcsd-blaze 1.00A (Aug 2 2012 12:26:08) Jan 01 00:00:00 2 5 0 libcam.so (Jun 15 2010 01:01:35) bver 6040207 Jan 01 00:00:00 2 5 100 cam-disk.so (Jun 15 2010 01:01:50) Jan 01 00:00:02 5 14 0 tcpip starting Jan 01 00:00:02 3 14 0 Unable to attach to pci server: No such file or directory Jan 01 00:00:02 3 14 0 Using pseudo random generator. See "random" option Jan 01 00:00:03 5 14 0 devn-ax: MII transceiver found at address 16. Jan 01 00:00:03 5 14 0 io-pkt shim Jan 01 00:00:03 5 14 0 Vendor .............. 0x0 Jan 01 00:00:03 5 14 0 Device .............. 0x0 Jan 01 00:00:03 5 14 0 Revision ............ 0x0 Jan 01 00:00:03 5 14 0 MAC address ......... 0050b6 0a546c Jan 01 00:00:03 5 14 0 Asix Jan 01 00:00:03 5 14 0 LanIdx .............. 18 Jan 01 00:00:03 5 14 0 DevIdx .............. 0 Jan 01 00:00:03 5 14 0 Vendor .............. 0xb95 Jan 01 00:00:03 5 14 0 Device .............. 0x7720 Jan 01 00:00:03 5 14 0 Revision ............ 0x0 Jan 01 00:00:03 5 14 0 MAC address ......... <MAC ADDRESS> Jan 01 00:00:36 5 10 0 devn-ax: link up (100 BaseT Full Duplex) nicinfo: Board1 en0: Asix Ethernet Controller Physical Node ID ........................... <MAC ADDRESS> Current Physical Node ID ................... <MAC ADDRESS> Current Operation Rate ..................... 100.00 Mb/s full-duplex Active Interface Type ...................... MII Active PHY address ....................... 16 Maximum Transmittable data Unit ............ 1514 Maximum Receivable data Unit ............... 1514 Promiscuous Mode ........................... Off Multicast Support .......................... Enabled Packets Transmitted OK ..................... 6 Bytes Transmitted OK ....................... 252 Broadcast Packets Transmitted OK ........... 6 Multicast Packets Transmitted OK ........... 0 Packets Received OK ........................ 0 Bytes Received OK .......................... 0 Broadcast Packets Received OK .............. 0 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 Transmit Underruns ......................... 0 No Carrier on Transmit ..................... 0 Receive Alignment errors ................... 0 Received packets with CRC errors ........... 0 Packets Dropped on receive ................. 0 Short packets .............................. 0 Total Frames experiencing Collison(s) ...... 0 Board2: en0: Asix Ethernet Controller Physical Node ID ........................... <MAC ADDRESS> Current Physical Node ID ................... <MAC ADDRESS> Current Operation Rate ..................... 100.00 Mb/s full-duplex Active Interface Type ...................... MII Active PHY address ....................... 16 Maximum Transmittable data Unit ............ 1514 Maximum Receivable data Unit ............... 1514 Promiscuous Mode ........................... Off Multicast Support .......................... Enabled Packets Transmitted OK ..................... 1 Bytes Transmitted OK ....................... 42 Broadcast Packets Transmitted OK ........... 1 Multicast Packets Transmitted OK ........... 0 Packets Received OK ........................ 0 Bytes Received OK .......................... 0 Broadcast Packets Received OK .............. 0 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 Transmit Underruns ......................... 0 No Carrier on Transmit ..................... 0 Receive Alignment errors ................... 0 Received packets with CRC errors ........... 0 Packets Dropped on receive ................. 0 Short packets .............................. 0 Total Frames experiencing Collison(s) ...... 0 ifconfig -a Board1 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: <MAC ADDRESS> media: Ethernet 100baseTX full-duplex status: active inet 129.97.69.159 netmask 0xfffffe00 broadcast 129.97.69.255 Board2 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: <MAC ADDRESS> media: Ethernet 100baseTX full-duplex status: active inet 129.97.69.181 netmask 0xfffffe00 broadcast 129.97.69.255 pidin irq Board1 pid tid name 1 1 /procnto-smp-instr 1 2 /procnto-smp-instr 0 0x45 0 -P- @0xfe0540e0:0x0 1 3 /procnto-smp-instr 1 4 /procnto-smp-instr 1 5 /procnto-smp-instr 1 6 /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 4098 1 /boot/devc-seromap 1 0x6a 0 --- @0x1025bc:0x12ba88 4099 1 proc/boot/slogger 4100 1 proc/boot/pipe 4100 2 proc/boot/pipe 4100 3 proc/boot/pipe 4101 1 i2c-omap35xx-omap4 2 0x58 0 T-- @0x10227c:0x108040 4102 1 i2c-omap35xx-omap4 3 0x59 0 T-- @0x10227c:0x108040 4103 1 i2c-omap35xx-omap4 4 0x5d 0 T-- @0x10227c:0x108040 4104 1 i2c-omap35xx-omap4 5 0x5e 0 T-- @0x10227c:0x108040 16393 1 t/devb-mmcsd-blaze 16393 2 t/devb-mmcsd-blaze 16393 3 t/devb-mmcsd-blaze 6 0x73 0 TP- =PULSE 0x40000005:21 0x2:0 16393 4 t/devb-mmcsd-blaze 16393 5 t/devb-mmcsd-blaze 16393 6 t/devb-mmcsd-blaze 16393 7 t/devb-mmcsd-blaze 16394 1 oc/boot/spi-master 16394 2 oc/boot/spi-master 7 0x61 0 T-- @0x78001764:0x11bef0 16395 1 oc/boot/spi-master 16395 2 oc/boot/spi-master 8 0x50 0 T-- @0x78001764:0x11bef0 16396 1 proc/boot/io-usb 9 0x7d 0 T-- @0x78008944:0x133948 11 0x6d 0 TP- =PULSE 0x4000000b:21 0:0 16396 2 proc/boot/io-usb 10 0x7c 0 T-- @0x780062a0:0x138410 16396 3 proc/boot/io-usb 16396 4 proc/boot/io-usb 16396 5 proc/boot/io-usb 16396 6 proc/boot/io-usb 16396 7 proc/boot/io-usb 16396 8 proc/boot/io-usb 20493 1 roc/boot/io-pkt-v4 20493 2 roc/boot/io-pkt-v4 12 0x45 0 T-- @0x13e9bc:0x18c150 20493 3 roc/boot/io-pkt-v4 20493 4 roc/boot/io-pkt-v4 32782 1 proc/boot/devc-pty 32785 1 usr/bin/pdebug 36879 1 usr/sbin/inetd 40976 1 bin/sh 114706 1 proc/boot/pidin Board2 pid tid name 1 1 /procnto-smp-instr 1 2 /procnto-smp-instr 0 0x45 0 -P- @0xfe0540e0:0x0 1 3 /procnto-smp-instr 1 4 /procnto-smp-instr 1 6 /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 4098 1 /boot/devc-seromap 1 0x6a 0 --- @0x1025bc:0x12ba88 4099 1 proc/boot/slogger 4100 1 proc/boot/pipe 4100 2 proc/boot/pipe 4100 3 proc/boot/pipe 4101 1 i2c-omap35xx-omap4 2 0x58 0 T-- @0x10227c:0x108040 4102 1 i2c-omap35xx-omap4 3 0x59 0 T-- @0x10227c:0x108040 4103 1 i2c-omap35xx-omap4 4 0x5d 0 T-- @0x10227c:0x108040 4104 1 i2c-omap35xx-omap4 5 0x5e 0 T-- @0x10227c:0x108040 16393 1 t/devb-mmcsd-blaze 16393 2 t/devb-mmcsd-blaze 16393 3 t/devb-mmcsd-blaze 6 0x73 0 TP- =PULSE 0x40000005:21 0x2:0 16393 4 t/devb-mmcsd-blaze 16393 5 t/devb-mmcsd-blaze 16393 6 t/devb-mmcsd-blaze 16393 7 t/devb-mmcsd-blaze 16394 1 oc/boot/spi-master 16394 2 oc/boot/spi-master 7 0x61 0 T-- @0x78001764:0x11bef0 16395 1 oc/boot/spi-master 16395 2 oc/boot/spi-master 8 0x50 0 T-- @0x78001764:0x11bef0 16396 1 proc/boot/io-usb 9 0x7d 0 T-- @0x78008944:0x133948 11 0x6d 0 TP- =PULSE 0x4000000b:21 0:0 16396 2 proc/boot/io-usb 10 0x7c 0 T-- @0x780062a0:0x138410 16396 3 proc/boot/io-usb 16396 4 proc/boot/io-usb 16396 5 proc/boot/io-usb 16396 6 proc/boot/io-usb 16396 7 proc/boot/io-usb 16396 8 proc/boot/io-usb 20493 1 roc/boot/io-pkt-v4 20493 2 roc/boot/io-pkt-v4 12 0x45 0 T-- @0x13e9bc:0x18c150 20493 3 roc/boot/io-pkt-v4 20493 4 roc/boot/io-pkt-v4 32782 1 proc/boot/devc-pty 32785 1 usr/bin/pdebug 36879 1 usr/sbin/inetd 40976 1 bin/sh 65554 1 proc/boot/pidin When I try to ping one board from the other, I just get PING 129.97.69.181 (129.97.69.181): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down The interesting thing is that SOMETIMES it works, I mean I am able to ping one board from the other. I have searched a lot on the web to find anything related to solve this issue, but no luck. I have no idea how to debug this issue. Any help would be great. Thanks, Johnson _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post94599 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Thu, 02 Aug 2012 16:59:20 GMT http://community.qnx.com/sf/go/post94600 Lichun Zhu 2012-08-02T16:59:20Z http://community.qnx.com/sf/go/post94599 Hi all, I have QNX 6.5.0 running on two pandaboards (Board1 & Board2) connected by a crosswire ethernet cable. I am using a ASIX USB to Ethernet dongle on both the boards since for some reason the mac address of the ethernet port on both boards are all 0's. I use the following lines in the build script to start up io-pkt-v4 io-pkt-v4 -dasix promiscuous,mac=<MAC ADDRESS>,verbose=4 -ptcpip waitfor /dev/socket if_up -p en0 display_msg Getting Static IP ifconfig en0 <IP> netmask 255.255.254.0 ifconfig en0 The following are the sloginfo for both boards Board 1 Time Sev Major Minor Args Jan 01 00:00:00 2 19 1800 devb-mmcsd-blaze 1.00A (Aug 2 2012 12:28:51) Jan 01 00:00:00 2 5 0 libcam.so (Jun 15 2010 01:01:35) bver 6040207 Jan 01 00:00:00 2 5 100 cam-disk.so (Jun 15 2010 01:01:50) Jan 01 00:00:02 5 14 0 tcpip starting Jan 01 00:00:02 3 14 0 Unable to attach to pci server: No such file or directory Jan 01 00:00:02 3 14 0 Using pseudo random generator. See "random" option Jan 01 00:00:03 5 14 0 devn-ax: MII transceiver found at address 16. Jan 01 00:00:03 5 14 0 io-pkt shim Jan 01 00:00:03 5 14 0 Vendor .............. 0x0 Jan 01 00:00:03 5 14 0 Device .............. 0x0 Jan 01 00:00:03 5 14 0 Revision ............ 0x0 Jan 01 00:00:03 5 14 0 MAC address ......... 0050b6 0a3c66 Jan 01 00:00:03 5 14 0 Asix Jan 01 00:00:03 5 14 0 LanIdx .............. 18 Jan 01 00:00:03 5 14 0 DevIdx .............. 0 Jan 01 00:00:03 5 14 0 Vendor .............. 0xb95 Jan 01 00:00:03 5 14 0 Device .............. 0x7720 Jan 01 00:00:03 5 14 0 Revision ............ 0x0 Jan 01 00:00:03 5 14 0 MAC address ......... <MAC ADDRESS> Jan 01 00:00:06 5 10 0 devn-ax: link up (100 BaseT Full Duplex) Board2 Time Sev Major Minor Args Jan 01 00:00:00 2 19 1800 devb-mmcsd-blaze 1.00A (Aug 2 2012 12:26:08) Jan 01 00:00:00 2 5 0 libcam.so (Jun 15 2010 01:01:35) bver 6040207 Jan 01 00:00:00 2 5 100 cam-disk.so (Jun 15 2010 01:01:50) Jan 01 00:00:02 5 14 0 tcpip starting Jan 01 00:00:02 3 14 0 Unable to attach to pci server: No such file or directory Jan 01 00:00:02 3 14 0 Using pseudo random generator. See "random" option Jan 01 00:00:03 5 14 0 devn-ax: MII transceiver found at address 16. Jan 01 00:00:03 5 14 0 io-pkt shim Jan 01 00:00:03 5 14 0 Vendor .............. 0x0 Jan 01 00:00:03 5 14 0 Device .............. 0x0 Jan 01 00:00:03 5 14 0 Revision ............ 0x0 Jan 01 00:00:03 5 14 0 MAC address ......... 0050b6 0a546c Jan 01 00:00:03 5 14 0 Asix Jan 01 00:00:03 5 14 0 LanIdx .............. 18 Jan 01 00:00:03 5 14 0 DevIdx .............. 0 Jan 01 00:00:03 5 14 0 Vendor .............. 0xb95 Jan 01 00:00:03 5 14 0 Device .............. 0x7720 Jan 01 00:00:03 5 14 0 Revision ............ 0x0 Jan 01 00:00:03 5 14 0 MAC address ......... <MAC ADDRESS> Jan 01 00:00:36 5 10 0 devn-ax: link up (100 BaseT Full Duplex) nicinfo: Board1 en0: Asix Ethernet Controller Physical Node ID ........................... <MAC ADDRESS> Current Physical Node ID ................... <MAC ADDRESS> Current Operation Rate ..................... 100.00 Mb/s full-duplex Active Interface Type ...................... MII Active PHY address ....................... 16 Maximum Transmittable data Unit ............ 1514 Maximum Receivable data Unit ............... 1514 Promiscuous Mode ........................... Off Multicast Support .......................... Enabled Packets Transmitted OK ..................... 6 Bytes Transmitted OK ....................... 252 Broadcast Packets Transmitted OK ........... 6 Multicast Packets Transmitted OK ........... 0 Packets Received OK ........................ 0 Bytes Received OK .......................... 0 Broadcast Packets Received OK .............. 0 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 Transmit Underruns ......................... 0 No Carrier on Transmit ..................... 0 Receive Alignment errors ................... 0 Received packets with CRC errors ........... 0 Packets Dropped on receive ................. 0 Short packets .............................. 0 Total Frames experiencing Collison(s) ...... 0 Board2: en0: Asix Ethernet Controller Physical Node ID ........................... <MAC ADDRESS> Current Physical Node ID ................... <MAC ADDRESS> Current Operation Rate ..................... 100.00 Mb/s full-duplex Active Interface Type ...................... MII Active PHY address ....................... 16 Maximum Transmittable data Unit ............ 1514 Maximum Receivable data Unit ............... 1514 Promiscuous Mode ........................... Off Multicast Support .......................... Enabled Packets Transmitted OK ..................... 1 Bytes Transmitted OK ....................... 42 Broadcast Packets Transmitted OK ........... 1 Multicast Packets Transmitted OK ........... 0 Packets Received OK ........................ 0 Bytes Received OK .......................... 0 Broadcast Packets Received OK .............. 0 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 Transmit Underruns ......................... 0 No Carrier on Transmit ..................... 0 Receive Alignment errors ................... 0 Received packets with CRC errors ........... 0 Packets Dropped on receive ................. 0 Short packets .............................. 0 Total Frames experiencing Collison(s) ...... 0 ifconfig -a Board1 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: <MAC ADDRESS> media: Ethernet 100baseTX full-duplex status: active inet 129.97.69.159 netmask 0xfffffe00 broadcast 129.97.69.255 Board2 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: <MAC ADDRESS> media: Ethernet 100baseTX full-duplex status: active inet 129.97.69.181 netmask 0xfffffe00 broadcast 129.97.69.255 pidin irq Board1 pid tid name 1 1 /procnto-smp-instr 1 2 /procnto-smp-instr 0 0x45 0 -P- @0xfe0540e0:0x0 1 3 /procnto-smp-instr 1 4 /procnto-smp-instr 1 5 /procnto-smp-instr 1 6 /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 4098 1 /boot/devc-seromap 1 0x6a 0 --- @0x1025bc:0x12ba88 4099 1 proc/boot/slogger 4100 1 proc/boot/pipe 4100 2 proc/boot/pipe 4100 3 proc/boot/pipe 4101 1 i2c-omap35xx-omap4 2 0x58 0 T-- @0x10227c:0x108040 4102 1 i2c-omap35xx-omap4 3 0x59 0 T-- @0x10227c:0x108040 4103 1 i2c-omap35xx-omap4 4 0x5d 0 T-- @0x10227c:0x108040 4104 1 i2c-omap35xx-omap4 5 0x5e 0 T-- @0x10227c:0x108040 16393 1 t/devb-mmcsd-blaze 16393 2 t/devb-mmcsd-blaze 16393 3 t/devb-mmcsd-blaze 6 0x73 0 TP- =PULSE 0x40000005:21 0x2:0 16393 4 t/devb-mmcsd-blaze 16393 5 t/devb-mmcsd-blaze 16393 6 t/devb-mmcsd-blaze 16393 7 t/devb-mmcsd-blaze 16394 1 oc/boot/spi-master 16394 2 oc/boot/spi-master 7 0x61 0 T-- @0x78001764:0x11bef0 16395 1 oc/boot/spi-master 16395 2 oc/boot/spi-master 8 0x50 0 T-- @0x78001764:0x11bef0 16396 1 proc/boot/io-usb 9 0x7d 0 T-- @0x78008944:0x133948 11 0x6d 0 TP- =PULSE 0x4000000b:21 0:0 16396 2 proc/boot/io-usb 10 0x7c 0 T-- @0x780062a0:0x138410 16396 3 proc/boot/io-usb 16396 4 proc/boot/io-usb 16396 5 proc/boot/io-usb 16396 6 proc/boot/io-usb 16396 7 proc/boot/io-usb 16396 8 proc/boot/io-usb 20493 1 roc/boot/io-pkt-v4 20493 2 roc/boot/io-pkt-v4 12 0x45 0 T-- @0x13e9bc:0x18c150 20493 3 roc/boot/io-pkt-v4 20493 4 roc/boot/io-pkt-v4 32782 1 proc/boot/devc-pty 32785 1 usr/bin/pdebug 36879 1 usr/sbin/inetd 40976 1 bin/sh 114706 1 proc/boot/pidin Board2 pid tid name 1 1 /procnto-smp-instr 1 2 /procnto-smp-instr 0 0x45 0 -P- @0xfe0540e0:0x0 1 3 /procnto-smp-instr 1 4 /procnto-smp-instr 1 6 /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 4098 1 /boot/devc-seromap 1 0x6a 0 --- @0x1025bc:0x12ba88 4099 1 proc/boot/slogger 4100 1 proc/boot/pipe 4100 2 proc/boot/pipe 4100 3 proc/boot/pipe 4101 1 i2c-omap35xx-omap4 2 0x58 0 T-- @0x10227c:0x108040 4102 1 i2c-omap35xx-omap4 3 0x59 0 T-- @0x10227c:0x108040 4103 1 i2c-omap35xx-omap4 4 0x5d 0 T-- @0x10227c:0x108040 4104 1 i2c-omap35xx-omap4 5 0x5e 0 T-- @0x10227c:0x108040 16393 1 t/devb-mmcsd-blaze 16393 2 t/devb-mmcsd-blaze 16393 3 t/devb-mmcsd-blaze 6 0x73 0 TP- =PULSE 0x40000005:21 0x2:0 16393 4 t/devb-mmcsd-blaze 16393 5 t/devb-mmcsd-blaze 16393 6 t/devb-mmcsd-blaze 16393 7 t/devb-mmcsd-blaze 16394 1 oc/boot/spi-master 16394 2 oc/boot/spi-master 7 0x61 0 T-- @0x78001764:0x11bef0 16395 1 oc/boot/spi-master 16395 2 oc/boot/spi-master 8 0x50 0 T-- @0x78001764:0x11bef0 16396 1 proc/boot/io-usb 9 0x7d 0 T-- @0x78008944:0x133948 11 0x6d 0 TP- =PULSE 0x4000000b:21 0:0 16396 2 proc/boot/io-usb 10 0x7c 0 T-- @0x780062a0:0x138410 16396 3 proc/boot/io-usb 16396 4 proc/boot/io-usb 16396 5 proc/boot/io-usb 16396 6 proc/boot/io-usb 16396 7 proc/boot/io-usb 16396 8 proc/boot/io-usb 20493 1 roc/boot/io-pkt-v4 20493 2 roc/boot/io-pkt-v4 12 0x45 0 T-- @0x13e9bc:0x18c150 20493 3 roc/boot/io-pkt-v4 20493 4 roc/boot/io-pkt-v4 32782 1 proc/boot/devc-pty 32785 1 usr/bin/pdebug 36879 1 usr/sbin/inetd 40976 1 bin/sh 65554 1 proc/boot/pidin When I try to ping one board from the other, I just get PING 129.97.69.181 (129.97.69.181): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down The interesting thing is that SOMETIMES it works, I mean I am able to ping one board from the other. I have searched a lot on the web to find anything related to solve this issue, but no luck. I have no idea how to debug this issue. Any help would be great. Thanks, Johnson Thu, 02 Aug 2012 16:51:31 GMT http://community.qnx.com/sf/go/post94599 Johnson Thomas 2012-08-02T16:51:31Z http://community.qnx.com/sf/go/post94594 I need to run gdb on a my shared library loaded by mount. I normally would start my driver like so: mount -v -T io-pkt devnp-canpro_g.so -o baud=1000,port=0,board_index=0,verbose but if I start gdb like this: gdb --x ./gdbopts --args mount -vvv-T io-pkt devnp-canpro_g.so -o baud=1000,port=0,board_index=0,verbose where gdbopts contains: set solib-search-path /lib/dll set auto-solib-add 1 And I set a breakpoint on my _attach etc entry point it never gets called before mount exits and the program ends normally. Any tips on how to debug my devnp-canpro_g.so? I have been able to get it to load and debug using this: gdb --x ./gdbopts --args io-pkt-v4 -v -dcanpro_g baud=1000,port=0,board_index=0,verbose but a bug I am seeing does not show up with this method of starting. Thanks Allan Thu, 02 Aug 2012 14:27:56 GMT http://community.qnx.com/sf/go/post94594 Allan Smith 2012-08-02T14:27:56Z http://community.qnx.com/sf/go/post94590 Further to my last e-mail, if you want to slay io-pkt you must first make sure that anything that is running against io-pkt is slayed first. eg. inetd, dhcp.client etc. On 2012-08-01 7:57 PM, "Roger Marley" <community-noreply@qnx.com> wrote: >It is QNX6.5.0 > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94583 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 02 Aug 2012 12:07:05 GMT http://community.qnx.com/sf/go/post94590 Hugh Brown 2012-08-02T12:07:05Z http://community.qnx.com/sf/go/post94589 I have never had a problem slaying io-pkt with the rtl8169 driver. I have attached the latest driver from SP1, so please try that. On 2012-08-01 7:57 PM, "Roger Marley" <community-noreply@qnx.com> wrote: >It is QNX6.5.0 > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94583 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Thu, 02 Aug 2012 11:35:37 GMT http://community.qnx.com/sf/go/post94589 Hugh Brown 2012-08-02T11:35:37Z http://community.qnx.com/sf/go/post94583 It is QNX6.5.0 Wed, 01 Aug 2012 23:57:23 GMT http://community.qnx.com/sf/go/post94583 Roger Marley 2012-08-01T23:57:23Z http://community.qnx.com/sf/go/post94558 What version of the O/S are you running? On 2012-08-01 3:01 AM, "Roger Marley" <community-noreply@qnx.com> wrote: >Hi, > >I am having a problem slaying io-pkt-v4-hc, which I need to do to restart >it at a higher speed. >After I have slayed it, if I attempt to run 'ps -e' it freezes, and >cannot be terminated with CTRL C (but it can be stopped with CTRL Z). >Other commands also freeze (e.g. 'shutdown'). >The driver is rtl8169. > >I have attached my pci -vv > >Any help would be greatly appreciated, >Regards, Roger > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94551 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Wed, 01 Aug 2012 11:42:03 GMT http://community.qnx.com/sf/go/post94558 Hugh Brown 2012-08-01T11:42:03Z http://community.qnx.com/sf/go/post94551 Hi, I am having a problem slaying io-pkt-v4-hc, which I need to do to restart it at a higher speed. After I have slayed it, if I attempt to run 'ps -e' it freezes, and cannot be terminated with CTRL C (but it can be stopped with CTRL Z). Other commands also freeze (e.g. 'shutdown'). The driver is rtl8169. I have attached my pci -vv Any help would be greatly appreciated, Regards, Roger Wed, 01 Aug 2012 07:01:55 GMT http://community.qnx.com/sf/go/post94551 Roger Marley 2012-08-01T07:01:55Z http://community.qnx.com/sf/go/post94531 It looks like you have two separate discussions. One for the driver and one for the custom protocol you are trying to send. For the driver, I would just start with the default utilities (ping, telnet, ftp) to see if the driver appears to be working. If the driver appears to be working then you can examine your custom protocol. If it is IP based you can look at SOCK_RAW to encapsulate your protocol in IP frames. If it is not IP based, then you can look at nraw, BPF, or your own custom resource manager for your driver to inject your frames onto the wire. It could depend a bit on what the rawcan io-net module did under 6.3 and whether the frames are ethernet or raw bus frames. Nraw would have to be requested from your sales representative. Dave -----Original Message----- From: Allan Smith [mailto:community-noreply@qnx.com] Sent: July-31-12 10:13 AM To: drivers-networking Subject: io-pkt driver to implement socketCAN for our hardware issue I have written a native io-pkt driver for our CAN bus hardware. It seems to be working but when I try to open a socket and send to it, the data never gets to my network driver. I start my driver like so: mount -vvv -Tio-pkt -obaud=1000,port=0,board_index=0,verbose devnp-canpro_g.so then I assign it an arbitrary IP like so: ifconfig can0 10.0.0.1 I can see the interface is up from the output of ifconfig # 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: 00:50:ba:50:af:6a media: Ethernet 100baseTX full-duplex status: active inet 206.130.75.216 netmask 0xffffff00 broadcast 206.130.75.255 can0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: 00:01:02:03:04:05 media: Ethernet autoselect (none full-duplex) status: active inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 then I access the port using my test program like so: struct can_sockaddr addr; addr.sa_len = sizeof(addr); addr.sa_family = AF_INET; addr.iface = ifaddr; addr.id = ENDIAN_BE32(0xffe00000); s = socket(AF_INET, SOCK_RAW, 0); I know the default protocol is tcpip. Could the tcpip stack be deciding to not route the data to my driver? I have tried playing with the netmask and using destination IPs like 10.0.0.2 with no luck either. In the original socketCAN implementation under QNX 6.3 he had a rawcan protocol he used a a upper filter driver. Am I going to have to make my own to make this work and if so I don't see any samples on how to do this? Any help would be greatly appreciated. Thanks Allan _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post94529 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Tue, 31 Jul 2012 17:23:51 GMT http://community.qnx.com/sf/go/post94531 Dave Brown 2012-07-31T17:23:51Z http://community.qnx.com/sf/go/post94530 I have been doing some reading and research and I think what I need is the shared library lsm-nraw.so. Unfortunately it does not seem to be included in the 6.4 or 6.5 images. Is this library not published? Allan Tue, 31 Jul 2012 15:41:11 GMT http://community.qnx.com/sf/go/post94530 Allan Smith 2012-07-31T15:41:11Z http://community.qnx.com/sf/go/post94529 I have written a native io-pkt driver for our CAN bus hardware. It seems to be working but when I try to open a socket and send to it, the data never gets to my network driver. I start my driver like so: mount -vvv -Tio-pkt -obaud=1000,port=0,board_index=0,verbose devnp-canpro_g.so then I assign it an arbitrary IP like so: ifconfig can0 10.0.0.1 I can see the interface is up from the output of ifconfig # 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: 00:50:ba:50:af:6a media: Ethernet 100baseTX full-duplex status: active inet 206.130.75.216 netmask 0xffffff00 broadcast 206.130.75.255 can0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: 00:01:02:03:04:05 media: Ethernet autoselect (none full-duplex) status: active inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 then I access the port using my test program like so: struct can_sockaddr addr; addr.sa_len = sizeof(addr); addr.sa_family = AF_INET; addr.iface = ifaddr; addr.id = ENDIAN_BE32(0xffe00000); s = socket(AF_INET, SOCK_RAW, 0); I know the default protocol is tcpip. Could the tcpip stack be deciding to not route the data to my driver? I have tried playing with the netmask and using destination IPs like 10.0.0.2 with no luck either. In the original socketCAN implementation under QNX 6.3 he had a rawcan protocol he used a a upper filter driver. Am I going to have to make my own to make this work and if so I don't see any samples on how to do this? Any help would be greatly appreciated. Thanks Allan Tue, 31 Jul 2012 14:13:06 GMT http://community.qnx.com/sf/go/post94529 Allan Smith 2012-07-31T14:13:06Z http://community.qnx.com/sf/go/post94509 Yea sorry I should have clarified that - you need to set an address to kick start the init for your device. Until that point it won't get called. After that point it can get called multiple times for example when you change mtu - so in general if you are writing to the interface. Mon, 30 Jul 2012 13:05:56 GMT http://community.qnx.com/sf/go/post94509 Gervais Mulongoy 2012-07-30T13:05:56Z http://community.qnx.com/sf/go/post94508 Ok figured out the init call. The ifconfig only causes an init when an IP is also assigned to the interface before hand. Thanks for the tips. Allan Mon, 30 Jul 2012 13:05:07 GMT http://community.qnx.com/sf/go/post94508 Allan Smith 2012-07-30T13:05:07Z http://community.qnx.com/sf/go/post94507 Hmmm changing the mtu is only causing an ioctl call Allan Time Sev Major Minor Args Jul 30 13:14:13 5 10 0 devnp-canpro: canpro_ioctl (2156947839) Mon, 30 Jul 2012 12:37:46 GMT http://community.qnx.com/sf/go/post94507 Allan Smith 2012-07-30T12:37:46Z http://community.qnx.com/sf/go/post94506 Oh wow, thanks for the info. Read or write to the interface will cause an _init as well right? Allan Mon, 30 Jul 2012 12:35:57 GMT http://community.qnx.com/sf/go/post94506 Allan Smith 2012-07-30T12:35:57Z http://community.qnx.com/sf/go/post94500 As far as I know native io-pkt drivers don't get listed in /dev/ or in /dev/io-pkt only older io-net drivers get listed in /dev/io-net. To force a call to your init call, try changing the mtu of your device or setting an address: ifconfig yourdev0 mtu 1300 Mon, 30 Jul 2012 11:55:38 GMT http://community.qnx.com/sf/go/post94500 Gervais Mulongoy 2012-07-30T11:55:38Z http://community.qnx.com/sf/go/post94497 Hello, I understand the in the if_bridge.c source file, the routing of packets based of MAC address is done. But I am not able to locate which part of code that handles it. I am trying to locate a place where the whole ethernet packet is available such that bridge work without any issues, at the same time I can copy the whole ethernet packet to my own custom buffers. Also I am trying to put certain filters such that i can drop the packet for certain logical conditions without sending it to upper layers or to the other interface for forwarding. Please let me know which part of code I need to refer. Thanks and warm regards, Santhosh. A Mon, 30 Jul 2012 06:29:02 GMT http://community.qnx.com/sf/go/post94497 Santhosh A 2012-07-30T06:29:02Z http://community.qnx.com/sf/go/post94494 I have created a custom io-pkt network driver based mostly on the sample provided. Currently testing on QNX 6.4.1 x86, but same behavior happens on 6.5. I am seeing something strange where my driver seems to start fine and shows up under ifconfig, but it does not get listed in the /dev or /dev/io-pkt directory. Likely related to this issue, the _init call never gets called. Other calls like _start, _ioctl, _attach etc all seem fine. Here is the mount verbose output: mount -vvv -Tio-pkt -obaud=1000,port=0,board_index=0,verbose devnp-canpro_g.so Parsed: mount from [devnp-canpro_g.so] mount on [NULL] type [io-pkt] exec: mount_io-pkt -o baud=1000 -o port=0 -o board_index=0 -o verbose -o implied -o nostat devnp-canpro_g.so / Using internal mount (mount_io-pkt not found) Type [io-pkt] Flags 0x80080000 Device [devnp-canpro_g.so] Directory [/] Options [baud=1000,port=0,board_index=0,verbose] Also the sloginfo output Jul 30 00:02:04 5 10 0 devnp-canpro: canpro_detach Jul 30 00:02:04 5 10 0 devnp-canpro: canpro_stop Jul 30 00:02:04 5 10 0 devnp-canpro: in8: 0x40100000 = 0x21 Jul 30 00:02:04 5 10 0 devnp-canpro: in8: 0x40100000 = 0x21 Jul 30 00:02:04 5 10 0 devnp-canpro: out8: 0x40100002 = 0x3c Jul 30 00:02:04 5 10 0 devnp-canpro: out8: 0x4010000d = 0x60 Jul 30 00:02:04 5 10 0 devnp-canpro: out8: 0x4010000e = 0x00 Jul 30 00:02:04 5 10 0 devnp-canpro: out8: 0x4010000f = 0x00 Jul 30 00:02:04 5 10 0 devnp-canpro: out8: 0x40100001 = 0x0c Jul 30 00:02:04 5 10 0 devnp-canpro: Controller reset Jul 30 00:02:04 5 10 0 devnp-canpro: in8: 0x40100000 = 0x21 Jul 30 00:02:04 5 10 0 devnp-canpro: canpro_ioctl (2156947762) Jul 30 00:02:37 5 10 0 devnp-canpro: canpro_detect Jul 30 00:02:37 1 10 0 devnp-canpro: SubSystemVendorID=0x12c4 SubSystemID=0x0900 Jul 30 00:02:37 1 10 0 devnp-canpro: canpro_detect: mem=0x40102000 Jul 30 00:02:37 5 10 0 devnp-canpro: canpro_attach Jul 30 00:02:37 5 10 0 devnp-canpro: in8: 0x40102000 = 0x21 I have definately set the ifp->if_init parameter during _attach. I have reviewed the dev_attach parameters and they seem ok but I am betting there is something wrong there. Any suggestions would be greatly appreciated. Allan Sun, 29 Jul 2012 23:31:58 GMT http://community.qnx.com/sf/go/post94494 Allan Smith 2012-07-29T23:31:58Z http://community.qnx.com/sf/go/post94454 That chipset is not supported by the 6.4.1 e1000 driver, only under 6.5.0. On 12-07-26 4:25 PM, "K Morant" <community-noreply@qnx.com> wrote: >Hi there, > >We are looking for driver QNX 6.4.1 driver support for Intel 82567V >Ethernet chip for an x86 platform. I was unable to find it in the driver >downloads section. > >Please let me know > >Regards > >Karl > > > >_______________________________________________ > >Networking Drivers >http://community.qnx.com/sf/go/post94451 >To cancel your subscription to this discussion, please e-mail >drivers-networking-unsubscribe@community.qnx.com Fri, 27 Jul 2012 22:57:14 GMT http://community.qnx.com/sf/go/post94454 Hugh Brown 2012-07-27T22:57:14Z http://community.qnx.com/sf/go/post94451 Hi there, We are looking for driver QNX 6.4.1 driver support for Intel 82567V Ethernet chip for an x86 platform. I was unable to find it in the driver downloads section. Please let me know Regards Karl Thu, 26 Jul 2012 20:25:09 GMT http://community.qnx.com/sf/go/post94451 K Morant 2012-07-26T20:25:09Z http://community.qnx.com/sf/go/post94432 net/if_bridge.c -seanb ----- Original Message ----- From: Santhosh A [mailto:community-noreply@qnx.com] Sent: Thursday, July 26, 2012 07:42 AM To: drivers-networking <drivers-networking@community.qnx.com> Subject: Re: Bridge functionality I am aware of that. I am looking for the implementation in the network stack, but don't know where to look for it. Please let me know which file in network stack implementation this logic is implemented. Warm regards, Santhosh. A _______________________________________________ Networking Drivers http://community.qnx.com/sf/go/post94431 To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Thu, 26 Jul 2012 12:20:49 GMT http://community.qnx.com/sf/go/post94432 Sean Boudreau 2012-07-26T12:20:49Z http://community.qnx.com/sf/go/post94430 As far as I know the routing logic isn't handled by implementation in the BSP, this is taken care of in the network stack implementation. On 07/26/2012 07:09 AM, Santhosh A wrote: > Hello, > > I am using P1020RDB PA EVK. > > Using brconfig, tsec0 and tsec2 are bridged, the packets are getting routed properly. > > Can anyone please tell me where in code this routing logic is implemented? I mean which file I need to refer to understand the routing mechanism. > > Thanks and warm regards, > Santhosh. A > > > > _______________________________________________ > > Networking Drivers > http://community.qnx.com/sf/go/post94429 > To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com Thu, 26 Jul 2012 11:57:02 GMT http://community.qnx.com/sf/go/post94430 Gervais Mulongoy 2012-07-26T11:57:02Z http://community.qnx.com/sf/go/post94431 I am aware of that. I am looking for the implementation in the network stack, but don't know where to look for it. Please let me know which file in network stack implementation this logic is implemented. Warm regards, Santhosh. A Thu, 26 Jul 2012 11:42:34 GMT http://community.qnx.com/sf/go/post94431 Santhosh A 2012-07-26T11:42:34Z http://community.qnx.com/sf/go/post94429 Hello, I am using P1020RDB PA EVK. Using brconfig, tsec0 and tsec2 are bridged, the packets are getting routed properly. Can anyone please tell me where in code this routing logic is implemented? I mean which file I need to refer to understand the routing mechanism. Thanks and warm regards, Santhosh. A Thu, 26 Jul 2012 11:09:47 GMT http://community.qnx.com/sf/go/post94429 Santhosh A 2012-07-26T11:09:47Z http://community.qnx.com/sf/go/post94240 After one week of testing no failure is noticed. Thu, 12 Jul 2012 23:54:36 GMT http://community.qnx.com/sf/go/post94240 janusz ruszel 2012-07-12T23:54:36Z http://community.qnx.com/sf/go/post94150 Hello, I just ran into the same problem. Again: Is there a solution? How does arp do it? Cheers, Christoph Mon, 09 Jul 2012 14:58:55 GMT http://community.qnx.com/sf/go/post94150 Christoph Nemmaier 2012-07-09T14:58:55Z http://community.qnx.com/sf/go/post94054 Hi, A little update on this issue : - a part of the problem was the network driver "devn-mpc5200". It limits the number of RX/TX buffers to 64/64 (default is 32/64), which is way too low ! You should recompile the driver from source, changing "mpc5200.h" to allow 256 RX buffers. - devnp-shim and io-pkt in QNX 6.4.1 are also a source of trouble. Contact your FAE to get a new software (bug fix from QNX 6.5.0) Thu, 05 Jul 2012 11:44:40 GMT http://community.qnx.com/sf/go/post94054 Emmanuel Herbreteau 2012-07-05T11:44:40Z