Bug in the sample driver code enclosed ??

The following driver for IRQ4 loads successfully .
But when an interrupt occurs, the ISR is not called. (the kdprint
statement is not executed!)
Is there any bug in the code ??

Experts please help.

Hope the following info might help:

The values HalGetInterruptVector returns for IRQ 4 are
MappedVector = 0x00000034
Irql = 0x20206F17
Affinity = 1

Please Note: The assembly code is checked correct. I wrote a linux
driver with the same assembly code in appropriate place (init_module( )
function).
And everything worked fine. But on windows, there is a problem. The
ISRis not getting called.
Maybe I should use some extra additional API to enable interrupt
handling ???
The device is a serial port one which generates DCD interrupt on the
RS-232 port.

THE CODE:

BOOLEAN InterruptIsr(IN PKINTERRUPT Interrupt, IN OUT PVOID Context)
{
asm(“movw $0x20, %dx”);
asm(“movb $0x20, %al”);
asm(“out %al, %dx”);
KdPrint( (“Kiran.sys: Interrupt Service Routine\n”) );
return TRUE;
}

NTSTATUS STDCALL
DriverEntry( IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING
RegistryPath )
{
NTSTATUS status;
PDEVICE_OBJECT DeviceObject;
UNICODE_STRING DeviceName;
UNICODE_STRING com1name;
UNICODE_STRING SymbolicLinkName;
ULONG MappedVector;
KIRQL Irql;
KAFFINITY Aff;

DriverObject->DriverUnload = kiran_unload;

/* initialize counted unicode strings */
RtlInitUnicodeString( &DeviceName, L"\Device\kiran" );
RtlInitUnicodeString( &SymbolicLinkName, L"\DosDevices\kiran"
);

/* create device object */
status = IoCreateDevice( DriverObject, 0, &DeviceName,
FILE_DEVICE_SERIAL_PORT, 0, FALSE, &DeviceObject );
if (!NT_SUCCESS( status ))
return status;

DeviceObject->Flags |= DO_BUFFERED_IO;

/* create user-visible name for the device */
status = IoCreateSymbolicLink( &SymbolicLinkName, &DeviceName );
if (!NT_SUCCESS( status ))
return status;

/* Create interrupt object */
MappedVector = HalGetInterruptVector(Internal,0, 4, 0, &Irql,
&Aff);

status = IoConnectInterrupt( &InterruptObject,
// InterruptObject
(PKSERVICE_ROUTINE)
InterruptIsr, // ServiceRoutine
DeviceObject,
// ServiceContext
NULL,
// SpinLock
MappedVector,
// Vector
Irql,
// Irql
Irql,
// SynchronizeIrql
Latched,
// InterruptMode
TRUE,
// ShareVector
Aff,
// ProcessorEnableMask
FALSE);
// FloatingSave

if (!NT_SUCCESS (status)) {
KdPrint((“Kiran.sys: IoConnectInterrupt Failed %x\n”,
status));
}
else {
KdPrint((“Kiran.sys: IoConnectInterrupt Succeed\n”));
}

/* Initialize the ports… */

/* The following assembly code read the data reg, modem status reg,
etc, of the UART */

asm(“movw $0x3FD, %dx”);
asm(“in %dx, %al”);

asm(“movw $0x3FA, %dx”);
asm(“in %dx, %al”);

asm(“movw $0x3F8, %dx”);
asm(“in %dx, %al”);

asm(“movw $0x3FE, %dx”);
asm(“in %dx, %al”);

/* The following assembly code sets the UART registers appropriately
so that DCD interrupts are enabled, RTS is set high, etc */

asm(“movw $0x3FB, %dx”);
asm(“movb $0x02, %al”);
asm(“out %al, %dx”);

asm(“movw $0x3FC, %dx”);
asm(“movb $0x0B, %al”);
asm(“out %al, %dx”);

asm(“movw $0x3F9, %dx”);
asm(“movb $0x01, %al”);
asm(“out %al, %dx”);

/* This assembly code enables the IRQ4 on the PIC */

asm(“movw $0x21, %dx”);
asm(“movb $0x00, %al”);
asm(“out %al, %dx”);*/

return STATUS_SUCCESS;
}

Yeah, I once wrote a DOS driver with similar asm code. But today I use
the DDK. :slight_smile:

... and there are source code samples (e.g. src\kernel\serial) that
show how to do it.

... and there is Walter Oney's Book which will give you even more
insight.

Norbert.

"There is no elevator to success. You have to take the stairs."
---- snip ----

Please Note: The assembly code is checked correct. I wrote a linux
driver with the same assembly code in appropriate place (init_module( )

---- snip ----

Infact, I searched the NTDEV mails to find oue that someone else also
had encountered a problem very similar to this.
The suggested solution was to "claim the hardware resource".
So I think I have to use IoAssignResources API for that.

The Art Baker's latest Book on 'Windows 2000 Device Drivers' showed a
sample code for a parallel port device.
In that sample code, before "IoConnectInterrupt( ) " is called, the
hardware resources for the parallel port are claimed.

But I'm still not sure of the following:

1> Does the IoConnectInterrupt API also ensures that the corresponding
IRQ is enabled in the PIC chip ?
Linux kernel does not do this. So we have to explicitly program the
PIC. (the assemble code I had used shows that)

2> Is it required in the ISR we write, to have a code that resets the
interrupt bit for that IRQ in PIC ?
Or the windows kernel will take care of that, after our ISR routinme
returns?

Thanx
Kiran

-----Original Message-----
From: Norbert Kawulski [mailto:xxxxx@stollmann.de]
Sent: Wednesday, September 17, 2003 5:49 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Bug in the sample driver code enclosed ??

Yeah, I once wrote a DOS driver with similar asm code. But today I use
the DDK. :slight_smile:

... and there are source code samples (e.g. src\kernel\serial) that
show how to do it.

... and there is Walter Oney's Book which will give you even more
insight.

Norbert.

"There is no elevator to success. You have to take the stairs."
---- snip ----

Please Note: The assembly code is checked correct. I wrote a linux
driver with the same assembly code in appropriate place (init_module(
)

---- snip ----


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

1< Yes. PIC/APIC/??? this is abstracted by HAL.
2< No. (see above)
Norbert.

"Experience is what you get if you didn¹t get what you wanted."
---- snip ----
1>> Does the IoConnectInterrupt API also ensures that the corresponding

IRQ is enabled in the PIC chip ?
Linux kernel does not do this. So we have to explicitly program the
PIC. (the assemble code I had used shows that)

2>> Is it required in the ISR we write, to have a code that resets the

interrupt bit for that IRQ in PIC ?
Or the windows kernel will take care of that, after our ISR routinme
returns?
---- snip ----