locked
WEC 7 : Bypassing NDISUIO RRS feed

  • Question

  • Hi All!

    I have a PCI based Ethernet Card Driver on WEC 7. I wrote a simple app which will keep querying the driver for some proprietary data in a while(1) loop. I want to bypass NDISUIO due to performance issues. Is it possible to expose a Stream Interface from the driver?? Or any other approaches?? Please suggest.

    Thanks!


    • Edited by deepak_ Wednesday, November 26, 2014 4:37 PM
    Wednesday, November 26, 2014 11:24 AM

Answers

  • Sure, assuming that you have the source code to the NIC driver, you can implement a stream interface in the same driver.

    I know it works, because I implemented it in my driver.  Here is my def file:

    LIBRARY         your_nic_driver_here
    EXPORTS         DriverEntry
                    ETH_Init
                    ETH_Deinit
                    ETH_Open
                    ETH_Close
                    ETH_IOControl
                    ETH_PowerUp
                    ETH_PowerDown
                    ETH_Seek
    	        ETH_Write
    	        ETH_Read

    You need to change a few things in the registry, namely the Prefix and Dll keys:

    [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\PCI\Template\<your driver>]
    ;  "Prefix"="NDS"
    ;  "Dll"="NDIS.dll"
    ;  "Entry"="NdisPCIBusDeviceInit"
    ;  "MiniPort"="ENET"
       "Prefix"="ETH"
       "Dll"="<your_nic_driver_here>.dll"   
    In the ETH_Init function, you need to call NdisRegisterAdapter to do the job initially done by NDIS.dll








    • Edited by Mario_M [MCTS] Thursday, November 27, 2014 9:48 PM
    • Proposed as answer by Mario_M [MCTS] Thursday, December 4, 2014 12:55 PM
    • Marked as answer by deepak_ Wednesday, December 10, 2014 1:28 PM
    Thursday, November 27, 2014 9:33 PM

All replies

  • NDISUIO is a driver with a stream driver that can be used to access the miniport driver. Why do you want to bypass NDISUIO?
    Thursday, November 27, 2014 11:57 AM
  • Helge,

    Thank You for responding.

    I want to bypass NDISIO because it is giving random crashes while my application runs. When I check the call stack, it shows the crash triggered by UIO_IOControl, the IOCTL handler in NDISUIO. Though mostly crashes are occurring due to Heap corruption (while UIO_IOControl calls LocalAlloc() to allocate memory for Input/Output buffers), I see occasional crashes in PCBGetDwordAtOffset(), ndisFdoOidRequest(), LeaveCriticalSection(), ndisOidRequestComplete() etc. I am on ARM platform, using iMX6 SABRE SDB.

    So my query remains the same: Is it possible to expose a Stream Interface from the driver?? Or any other feasible  approaches??

    Thanks!

    Thursday, November 27, 2014 12:27 PM
  • NDISUIO is the vehicle that provides a stream driver in the NDIS world. I doub't that you will find another.

    I used NDISUIO for years without problems. I would check the application for heap corruption.

    • Edited by Harper23 Thursday, November 27, 2014 12:36 PM
    • Proposed as answer by Harper23 Thursday, November 27, 2014 12:36 PM
    • Unproposed as answer by deepak_ Friday, November 28, 2014 2:31 PM
    Thursday, November 27, 2014 12:34 PM
  • I agree with your views that NDISUIO is the vehicle. My concern is: Is it the ONLY vehicle?

    In fact we have the same solution working fine on x86. I am observing this issue on ARM only. That's why looking for alternate ways.

    Regarding the application, I have a statically allocated buffer which I pass to the NDISUIO through DeviceIoControl; so no malloc() or anything similar to it is involved. Hence I don't doubt the application for causing Heap Corruption. Only NDISUIO has LocalAlloc which allocates from Heap, thus leading to Heap Corruption.

    Also, I am not getting much ideas on the kind of random crashes happening in different modules. Where else would you suggest me to check into?

    Thanks!

    Thursday, November 27, 2014 1:26 PM
  • Sure, assuming that you have the source code to the NIC driver, you can implement a stream interface in the same driver.

    I know it works, because I implemented it in my driver.  Here is my def file:

    LIBRARY         your_nic_driver_here
    EXPORTS         DriverEntry
                    ETH_Init
                    ETH_Deinit
                    ETH_Open
                    ETH_Close
                    ETH_IOControl
                    ETH_PowerUp
                    ETH_PowerDown
                    ETH_Seek
    	        ETH_Write
    	        ETH_Read

    You need to change a few things in the registry, namely the Prefix and Dll keys:

    [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\PCI\Template\<your driver>]
    ;  "Prefix"="NDS"
    ;  "Dll"="NDIS.dll"
    ;  "Entry"="NdisPCIBusDeviceInit"
    ;  "MiniPort"="ENET"
       "Prefix"="ETH"
       "Dll"="<your_nic_driver_here>.dll"   
    In the ETH_Init function, you need to call NdisRegisterAdapter to do the job initially done by NDIS.dll








    • Edited by Mario_M [MCTS] Thursday, November 27, 2014 9:48 PM
    • Proposed as answer by Mario_M [MCTS] Thursday, December 4, 2014 12:55 PM
    • Marked as answer by deepak_ Wednesday, December 10, 2014 1:28 PM
    Thursday, November 27, 2014 9:33 PM
  • Thanks a lot Mario!
    I could implement stream interface in my driver and it is working.
    However, I still see the random crashes as I mentioned earlier. So probably there is some other reason behind these crashes. This is same as mentioned in this (http://stackoverflow.com/questions/14610051/debugging-data-abort-and-prefetch-abort-exceptions-on-windows-ce-6) thread, except mine is a Console app written in C.
    Do you have any suggestions regarding where else should I check??

    Thanks!
    Wednesday, December 10, 2014 1:28 PM
  • Can you enable error reporting on your platform?  You can configure it to save the kernel dump directly on your target.  After you've got the crash, upload the .kdmp file on your PC and open it with PB.

    You will be able to see the place where the exception occurs and the calling sequence that lead to the exception.

    Wednesday, December 10, 2014 1:36 PM
  • Thanks for responding Mario.

    I am using EBOOT so am able to see some of the crashes (Access Violations etc.) but Prefetch Aborts are still like a black box.
    The main issue is the crashes are not consistent and are occurring in various OS modules like kernel.dll, coredll.dll, gwes.dll etc. I'd like to remind here that I am calling DeviceIoControl in a while(1) loop to continuously query the driver for received packets. Many a times the Return Address of the exception points to xxx_DeviceIoControl. Are there some system components getting affected by this heavy traffic of data in/out?


    • Edited by deepak_ Wednesday, December 10, 2014 2:18 PM
    Wednesday, December 10, 2014 2:17 PM
  • You seem to have many problems which typically means that you have either a hardware problem or a problem with your address map.

    You say that you have Prefetch Aborts.   Prefetch Aborts indicate that the CPU hit a point where it no longer had instructions to execute.  That can happen if the stack is corrupted or there is a null function pointer.

    You may want to capture the first exception as it can often be an indicator of where the problem lies, and the rest are just symptoms of the first exception.


    Bruce Eitman (eMVP) Senior Engineer Bruce.Eitman AT Eurotech DOT com My BLOG http://geekswithblogs.net/bruceeitman Eurotech Inc. www.Eurotech.com

    Wednesday, December 10, 2014 9:08 PM
  • Thank you for responding Bruce.

    There are not many problems but one: random exceptions. After your suggestion I checked more on xxx_DeviceIoControl. I added marshalling code (CeOpenCallerBuffer()) in my stream interface's IOControl handler and the app was running fine for around 7 hours until I got an exception in kernel.dll. A check in the map file and it was pointing to ServerCallReturn. Following is the capture from serial debug:

    PID:00400004 TID:018D1C4A Exception 'Data Abort' (0x4): Thread-Id=018d1c4a(pth=9b426000), Proc-Id=00400002(pprc=835ccae0) 'NK.EXE', VM-active=018e1b6a(pprc=9b496b80) 'my_test_app.exe'
    PID:00400004 TID:018D1C4A PC=80231b4b(kernel.dll+0x0001eb4b) RA=80231b39(kernel.dll+0x0001eb39) SP=af7cfdd8, BVA=00000048

    1) I read that ServerCallReturn is called when an API is returning and in my case I have DeviceIoControl running in a while(1) loop. So i feel while DeviceIoControl is returning, this exception happened. Your thoughts on this??

    2) I have restarted the app and will keep posted on the updates.

    Thanks!

    Friday, December 12, 2014 2:50 PM
  • This is an issue in the iMX6 BSP related to SMP and caching. It has nothing to do with your code. Disable SMP and your problems will go away (and so will your performance of course).

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    Monday, December 15, 2014 10:00 AM
  • Thank You for responding Michel.

    1) Which BSP Provider are you referring to?
    2) The Boot Config menu gives the options to activate the desired no. of cores so I can set it there. I have a doubt that making the no. of active cores as 1 won't bring down the performance?

    Thanks!


    • Edited by deepak_ Monday, December 15, 2014 2:01 PM
    Monday, December 15, 2014 11:57 AM
  • Deepak, as far as we know; all iMX6 BSPs on the market at this moment have this problem, despite what your BSP vendor may tell you (as you have noticed).

    Yes, in the bootloader you can set the number of processors. Set it to 1 and verify the problems disappear. Or, better; build a kernel with IMGNOSMP set to 1 to make sure SMP is disabled.

    If the problems disappear it shows there are still problems in your iMX6 BSP with SMP. Please do report your findings back on this forum so other people can do the same tests.

    You may want to wait for our iMX6 BSP release; https://guruce.com/blogpost/guruce-to-release-a-high-quality-imx6-bsp-supporting-imx6-solo-dual-lite-dual-and-quad


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    Monday, December 15, 2014 8:02 PM
  • Deepak,

    Did you manage to test with SMP disabled? If so, please report your findings back here.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    Wednesday, December 17, 2014 3:14 AM
  • Michel,

    I managed to test it with SMP disabled in the Bootloader but not for a very long time. In whatever time I tested it (~10 Hours), I didn't see any crashes. I'll update this post once I get to test it for a relatively longer time such as 2-3 days continuously.

    Thank You for your inputs..

    Thursday, December 18, 2014 1:59 PM