Hello, I have ndis driver (based on netvmin sample from MS repo), and I want to realize interrupt handling. How do I do this?
I’ve got some functions implemented (MPIsr, MPDisableInt, …EnableInt) and did register these handlers.
So my current problems are:
- Im stuck at device specific code like actual handling various interrupts (CarrierLost, Tx Error, etc.)
- How do I start handling? I cant find any explanation where should I get current interrupt status from the device.
I have a linux driver for this card with handling implemented and working
- For specific code I have offests of events
- I read status as RTL_R16(IntrStatusOffset) and find event as if (status & EventOffset)
IIRC, WDK samples, apart from other things, provided miniports for RTL8139 and NE2000 adapters
at the time when I writing code for Windows (i.e.10 years ago.)
Did they remove these samples from WDK?
Anton Bassov
anton, well, I cannot find anything device-specific for ethernet cards in repo. So I think they did remove these samples
I’ll check WDK 7.0 for this drivers
> I cannot find anything device-specific for ethernet cards in repo.
How may something like that be even possible???
Anton Bassov
You won’t find an example for interrupt management. There is a netvmini sample without the hardware interfacing code.
Sent from TypeApp
On 10 Jun 2016, 19:20, at 19:20, xxxxx@gmail.com wrote:
I’ll check WDK 7.0 for this drivers
NTDEV is sponsored by OSR
Visit the list online at:
http:
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:></http:>
anton,
I dont expect anything fully-functional, but at least some example of interrupt handling (in any kind). I dont know where to start learning from.
Jenson
I see. So is there anything that can help me understand how to build some basic event processing?
xxxxx@gmail.com wrote:
anton,
I dont expect anything fully-functional, but at least some example of interrupt handling (in any kind). I dont know where to start learning from.
Jenson
I see. So is there anything that can help me understand how to build some basic event processing?
When your hardware fires an interrupt, it’s trying to tell you
something. The job of an interrupt handler is, essentially
- Find out if it really was my device that fired, if not return FALSE
- Find out what caused the device to interrupt and remember that
- Clear the cause of the interrupt
- Queue up a DPC to handle whatever the cause was
In the DPC, you’ll do whatever service needs to be done. If a buffer
has gone empty, you can refill it. If an incoming buffer is full, you
can empty it and complete user requests. If there was an error, you can
decide what to do about the error.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
xxxxx@gmail.com wrote:
So my current problems are:
- Im stuck at device specific code like actual handling various interrupts (CarrierLost, Tx Error, etc.)
- How do I start handling? I cant find any explanation where should I get current interrupt status from the device.
You cannot possibly write a driver for a device without having a
datasheet that describes the registers for that device. There are
RTL8139 datasheets available on the Interwebs. The Interrupt Status
Register is at 0x003E. There are 10 different interrupt causes, several
of which you can’t do anything about anyway.
I have a linux driver for this card with handling implemented and working
- For specific code I have offests of events
- I read status as RTL_R16(IntrStatusOffset) and find event as if (status & EventOffset)
Yep, that’s the concept.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>> I dont expect anything fully-functional, but at least some example of interrupt handling (in any kind). I dont know where to
> start learning from.
The Windows 2000 DDK was the last DDK were the NE2000 miniport sample was provided ( NDIS5 ). It is installable for the RTL8019
and works rather well , even on Win98 :-). So , you have to compare the RTL8019 and the RTL8139 datasheet content when analyzing
that sample.
Christiaan
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, June 10, 2016 4:11 PM
Subject: RE:[ntdev] Handling interrupts for Realtek 8139 NDIS driver
> anton,
> I dont expect anything fully-functional, but at least some example of interrupt handling (in any kind). I dont know where to start
> learning from.
>
> Jenson
> I see. So is there anything that can help me understand how to build some basic event processing?
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
Christiaan Ghijselinck
thanks for this info, I will definitely use this!
Tim,
oh I have the datasheet of course 
So, I dont need any IO or Memory to Mmap(), I can just use NdisReadRegister() routines to get the status and other info?
If I’n right that ‘synonym’ for RTL_R16(IntrStatusOffset) is NdisRead/WriteRegister(Offset, etc)
xxxxx@gmail.com wrote:
Tim,
oh I have the datasheet of course So, I dont need any IO or Memory to Mmap(), I can just use NdisReadRegister() routines to get the status and other info?
You do, but the driver must already have mapped the register space,
using NdisMMapIoSpace.
If I’n right that ‘synonym’ for RTL_R16(IntrStatusOffset) is NdisRead/WriteRegister(Offset, etc)
Pretty much, except that the RTL_R16 macro must be adding the base
address of the register space. You will have to add that yourself when
you call NdisReadRegisterUshort.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
Do we go with NdisMMapIoSpace (Memory Mapped) or use Ndis I/O Port Interface for directly accessing the NIC registers ?Which one is recommended ?
With regards,Jenson Pais
Subject: Re: [ntdev] Handling interrupts for Realtek 8139 NDIS driver
To: xxxxx@lists.osr.com
From: xxxxx@probo.com
Date: Fri, 10 Jun 2016 17:39:47 -0700
xxxxx@gmail.com wrote:
> Tim,
> oh I have the datasheet of course So, I dont need any IO or Memory to Mmap(), I can just use NdisReadRegister() routines to get the status and other info?
You do, but the driver must already have mapped the register space,
using NdisMMapIoSpace.
> If I’n right that ‘synonym’ for RTL_R16(IntrStatusOffset) is NdisRead/WriteRegister(Offset, etc)
Pretty much, except that the RTL_R16 macro must be adding the base
address of the register space. You will have to add that yourself when
you call NdisReadRegisterUshort.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
Jenson Pais wrote:
Do we go with NdisMMapIoSpace (Memory Mapped) or use Ndis I/O Port
Interface for directly accessing the NIC registers ?
Which one is recommended ?
It’s not a matter of being “recommended”. If your device has registers
mapped into memory space, then you’ll use NdisMMapIoSpace and
NdisReadRegisterUshort. If your device has registers in I/O port space,
then you’ll use NdisReadPortUshort. Very few modern devices use I/O
port space any more, because the performance isn’t as good, so I tend to
assume memory space.
Years ago, back when Windows NT ran on non-Intel architectures, this
distinction was more fuzzy. Those other architectures (Alpha and PPC)
did not have the concept of “I/O space”, so ALL resources – even I/O
ports – had to go through a mapping. Today, we’re back to assuming
that I/O port numbers are absolute.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I think a slight clarification to Tim’s last point is needed. NDIS is used on Windows Embedded Compact {7|2013} which are primarily ARM based. ARM does not have the concept of “I/O ports”. Some of these ARM microcontrollers actually have PCIe interfaces too. So, you could have a PCIe NIC (such as the RTL8139) running on an architecture without the legacy Intel-centric “I/O ports”. The PCIe I/O regions are usually just mapped to memory addresses and the appropriate translation entries set up in the AXI to PCIe bridge.
Greg
— xxxxx@probo.com wrote:
From: Tim Roberts
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] Handling interrupts for Realtek 8139 NDIS driver
Date: Wed, 15 Jun 2016 09:52:16 -0700
Jenson Pais wrote:
>
> Do we go with NdisMMapIoSpace (Memory Mapped) or use Ndis I/O Port
> Interface for directly accessing the NIC registers ?
> Which one is recommended ?
It’s not a matter of being “recommended”. If your device has registers
mapped into memory space, then you’ll use NdisMMapIoSpace and
NdisReadRegisterUshort. If your device has registers in I/O port space,
then you’ll use NdisReadPortUshort. Very few modern devices use I/O
port space any more, because the performance isn’t as good, so I tend to
assume memory space.
Years ago, back when Windows NT ran on non-Intel architectures, this
distinction was more fuzzy. Those other architectures (Alpha and PPC)
did not have the concept of “I/O space”, so ALL resources – even I/O
ports – had to go through a mapping. Today, we’re back to assuming
that I/O port numbers are absolute.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
Gregory G Dyess wrote:
I think a slight clarification to Tim’s last point is needed. NDIS is used on Windows Embedded Compact {7|2013} which are primarily ARM based. ARM does not have the concept of “I/O ports”. Some of these ARM microcontrollers actually have PCIe interfaces too. So, you could have a PCIe NIC (such as the RTL8139) running on an architecture without the legacy Intel-centric “I/O ports”. The PCIe I/O regions are usually just mapped to memory addresses and the appropriate translation entries set up in the AXI to PCIe bridge.
How is that seen in the driver? Does the driver see a port resource?
In the Alpha/PPC days, drivers had to call HalTranslateBusAddress. You
told it whether you thought it was a port or memory resource, and it
would respond “no, this is really a memory resource”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
For PCIe devices, it’s just a PCIe I/O BAR. If it’s not an NDIS device, you would just map it to a memory address via a call analogous to HalTranslateBusAddress and you get a physical address which is then translated to a virtual address. There’s a wrapper/helper function that does both translations in one call. From this level, I/O and memory regions are indistinguishable. Even on an x86 platform, you can force map a PCIe I/O BAR to memory addresses and access it accordingly. On ARM (and other architectures where PCIe is not the native bus) it’s all handled in the address translation unit within the AXI to PCIe bridge. This makes the PCIe driver stack have to do a lot more work in configuring the AXI to PCIe bridge, especially where PCIe switches are involved. (Nightmare situation!)
Greg
— xxxxx@probo.com wrote:
From: Tim Roberts
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] Handling interrupts for Realtek 8139 NDIS driver
Date: Wed, 15 Jun 2016 10:32:48 -0700
Gregory G Dyess wrote:
> I think a slight clarification to Tim’s last point is needed. NDIS is used on Windows Embedded Compact {7|2013} which are primarily ARM based. ARM does not have the concept of “I/O ports”. Some of these ARM microcontrollers actually have PCIe interfaces too. So, you could have a PCIe NIC (such as the RTL8139) running on an architecture without the legacy Intel-centric “I/O ports”. The PCIe I/O regions are usually just mapped to memory addresses and the appropriate translation entries set up in the AXI to PCIe bridge.
How is that seen in the driver? Does the driver see a port resource?
In the Alpha/PPC days, drivers had to call HalTranslateBusAddress. You
told it whether you thought it was a port or memory resource, and it
would respond “no, this is really a memory resource”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
Tim,
Cheers for that bit of information.
Greg,
Thanks to you and Tim, understood the differences between x86 and ARM devices when it comes to NDIS based NIC register interfacing.
Regards,Jenson
Date: Wed, 15 Jun 2016 11:44:03 -0700
From: xxxxx@PDQ.NET
To: xxxxx@lists.osr.com
CC: xxxxx@lists.osr.com
Subject: Re: [ntdev] Handling interrupts for Realtek 8139 NDIS driver
For PCIe devices, it’s just a PCIe I/O BAR. If it’s not an NDIS device, you would just map it to a memory address via a call analogous to HalTranslateBusAddress and you get a physical address which is then translated to a virtual address. There’s a wrapper/helper function that does both translations in one call. From this level, I/O and memory regions are indistinguishable. Even on an x86 platform, you can force map a PCIe I/O BAR to memory addresses and access it accordingly. On ARM (and other architectures where PCIe is not the native bus) it’s all handled in the address translation unit within the AXI to PCIe bridge. This makes the PCIe driver stack have to do a lot more work in configuring the AXI to PCIe bridge, especially where PCIe switches are involved. (Nightmare situation!)
Greg
— xxxxx@probo.com wrote:
From: Tim Roberts
> To: “Windows System Software Devs Interest List”
> Subject: Re: [ntdev] Handling interrupts for Realtek 8139 NDIS driver
> Date: Wed, 15 Jun 2016 10:32:48 -0700
>
> Gregory G Dyess wrote:
> > I think a slight clarification to Tim’s last point is needed. NDIS is used on Windows Embedded Compact {7|2013} which are primarily ARM based. ARM does not have the concept of “I/O ports”. Some of these ARM microcontrollers actually have PCIe interfaces too. So, you could have a PCIe NIC (such as the RTL8139) running on an architecture without the legacy Intel-centric “I/O ports”. The PCIe I/O regions are usually just mapped to memory addresses and the appropriate translation entries set up in the AXI to PCIe bridge.
>
> How is that seen in the driver? Does the driver see a port resource?
> In the Alpha/PPC days, drivers had to call HalTranslateBusAddress. You
> told it whether you thought it was a port or memory resource, and it
> would respond “no, this is really a memory resource”.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:>