Hi, I have a driver controling multiple devices running on normal PC and
compactPCI platform. The two devices are allowed to work with the same IRQ
number but not when IRQs are different. For example,
Device#1 Device #2
10 15 not working
10 10 working
15 10 not working
15 15 working
Is there anyone can give me some idea why this happens? Thanks.
Z.S.Wang
Are they using the same interrupt spinlock?
-----Original Message-----
From: xxxxx@exgate.tek.com
[mailto:xxxxx@exgate.tek.com]
Sent: Monday, September 25, 2000 10:34 AM
To: NT Developers Interest List
Subject: [ntdev] one driver for two devices
Hi, I have a driver controling multiple devices running on
normal PC and
compactPCI platform. The two devices are allowed to work
with the same IRQ
number but not when IRQs are different. For example,
Device#1 Device #2
10 15 not working
10 10 working
15 10 not working
15 15 working
Is there anyone can give me some idea why this happens?
Thanks.
Z.S.Wang
You are currently subscribed to ntdev as:
xxxxx@broadstor.com
To unsubscribe send a blank email to
$subst(‘Email.Unsub’)
Hi, Gary: Actually i did not use any spinlock for interrupt. In
IoConnectInterrupt routine, I put spinlock as NULL. Could that affect
something? thanks.
Z.S.Wang
-----Original Message-----
From: Gary Little [mailto:xxxxx@broadstor.com]
Sent: Monday, September 25, 2000 10:44 AM
To: NT Developers Interest List
Subject: [ntdev] RE: one driver for two devices
Are they using the same interrupt spinlock?
-----Original Message-----
From: xxxxx@exgate.tek.com
[mailto:xxxxx@exgate.tek.com]
Sent: Monday, September 25, 2000 10:34 AM
To: NT Developers Interest List
Subject: [ntdev] one driver for two devices
Hi, I have a driver controling multiple devices running on
normal PC and
compactPCI platform. The two devices are allowed to work
with the same IRQ
number but not when IRQs are different. For example,
Device#1 Device #2
10 15 not working
10 10 working
15 10 not working
15 15 working
Is there anyone can give me some idea why this happens?
Thanks.
Z.S.Wang
You are currently subscribed to ntdev as:
xxxxx@broadstor.com
To unsubscribe send a blank email to
$subst(‘Email.Unsub’)
You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
I would recommend that you define the spinlock for each adapter when you
call. The problem may be that when you call IoConnectInterrupt on the same
IRQ, you get a separate system defined interrupt object, each with it’s own
system defined spinlock. If your not accounting for that when you’re
synchronizing access, you could have KeSynchronizeExecution using a
different spinlock to synchronize access. If you define the same spinlock in
both calls to IoConnectInterrupt, then both adapters ISR are sync’d with the
same spinlock.
Check the DDK documentation. It discusses chained IRQ’s and multiple
adapters using the same ISR.
Gary
.
-----Original Message-----
From: xxxxx@exgate.tek.com
[mailto:xxxxx@exgate.tek.com]
Sent: Monday, September 25, 2000 11:19 AM
To: NT Developers Interest List
Subject: [ntdev] RE: one driver for two devices
Hi, Gary: Actually i did not use any spinlock for interrupt.
In
IoConnectInterrupt routine, I put spinlock as NULL. Could
that affect
something? thanks.
Z.S.Wang
-----Original Message-----
From: Gary Little [mailto:xxxxx@broadstor.com]
Sent: Monday, September 25, 2000 10:44 AM
To: NT Developers Interest List
Subject: [ntdev] RE: one driver for two devices
Are they using the same interrupt spinlock?
-----Original Message-----
From: xxxxx@exgate.tek.com
[mailto:xxxxx@exgate.tek.com]
Sent: Monday, September 25, 2000 10:34 AM
To: NT Developers Interest List
Subject: [ntdev] one driver for two
devices
Hi, I have a driver controling multiple
devices running on
normal PC and
compactPCI platform. The two devices are
allowed to work
with the same IRQ
number but not when IRQs are different. For
example,
Device#1 Device #2
10 15 not working
10 10 working
15 10 not working
15 15 working
Is there anyone can give me some idea why
this happens?
Thanks.
Z.S.Wang
You are currently subscribed to ntdev as:
xxxxx@broadstor.com
To unsubscribe send a blank email to
$subst(‘Email.Unsub’)
You are currently subscribed to ntdev as:
xxxxx@exgate.tek.com
To unsubscribe send a blank email to
$subst(‘Email.Unsub’)
You are currently subscribed to ntdev as:
xxxxx@broadstor.com
To unsubscribe send a blank email to
$subst(‘Email.Unsub’)
Sorry, but this is wrong.
I would recommend that you define the spinlock for each
adapter when you
call.
This is the default behavior when you do *not* specify a spinlock in your
call to IoConnectInterrupt. Your interrupt objects will each use their own
unique default spinlock.
Generally you only specify a value for spinlock when you want to synchronize
across multiple device’s in either isr routines or dpc routines (where the
dpc is accessing data also accessed from an isr, otherwise a normal spinlock
would suffice.) Note also that this ‘feature’ is discouraged, and is
difficult to use correctly in w2k for a pnp device as it requires you to
supply the IRQ for the highest priority device - and you clearly don’t have
this information on hand in the start device routine for the first (n-1) of
n devices.
The problem may be that when you call
IoConnectInterrupt on the same
IRQ, you get a separate system defined interrupt object, each
with it’s own
system defined spinlock.
That would not be the specified behavior of the NT operating system. NT has
one interrupt object per interrupt vector. When you call IoConnectInterrupt
with an IRQ that has already been used then you get a pointer to the same
interrupt object returned for prior calls for the IRQ in question. (Or you
get an error if a prior caller has indicated that he doesn’t share, or if
you indicate that you don’t share.) Interrupt Objects are NOT allocated
dynamically as drivers request connections but instead are all created once
as part of the OS initialization process to reflect the platform
configuration.
Remember that his driver works when interrupts are shared and fails when
they are not shared.
Thanks, Mark and Gary: Actually I don’t think it is synchronization problem.
The scene is as following:
I have two different devices (d1 and d2). I assume the system will scan
slots from slot 1 to slot 2. If d1 is in slot 1 and d2 in slot 2, the driver
works perfect, but when I put d2 in slot 1 and d1 in slot2, the driver stops
right before IoConnectInterrupt routine for the d1 device which is in slot2.
It sounds to me that device d2 has some effect on device d1 if the interrupt
for d2 has been connected before d1 does. Based on my observation from IRQ,
it seems that d2 requires d1 have the same IRQ number as its. It is kind of
strange because I think d1 and d2 are independent(am I right?). I have
changed IoReportResouceUsage routine parameters and let it claim resources
on driver bases or on device bases, but either will not help me anything. So
I am confused. What could I do to explore this problem? Do you have any
further suggestion? Thanks.
Z.S.Wang
Z.S.Wang,
On a W2K system you should not be using IoReportResouceUsage, and on an NT4
system for PCI devices you generally should also not be using
IoReportResouceUsage.
I don’t understand what you mean by “the driver stops right before
IoConnectInterrupt routine”. How does the driver stop? Is it crashing, and
if so, have you looked at a stack trace to see where in your code that calls
IoConnectInterrupt you are causing the crash? We’d like to help but you are
not supplying enough information to allow us to do more than play “20
questions”.
If you are having an unhandled exception, see the windbg documentation
regarding how to get back to the original stack frame. In this case you are
most likely providing bad parameter values for your call to
IoConnectInterrupt.
If you were having problems when your devices shared an interrupt I would
suspect that there was a problem with interrupt sharing in one or other of
the ISRs (as in one ISR was returning an unconditional TRUE result.) The
fact that you are failing only when you don’t share interrupts, and
apparently while you are configuring the second interrupt, indicates to me
that you have a coding error in your software.
-----Original Message-----
From: xxxxx@exgate.tek.com
[mailto:xxxxx@exgate.tek.com]
Sent: Monday, September 25, 2000 6:25 PM
To: NT Developers Interest List
Subject: [ntdev] RE: one driver for two devicesThanks, Mark and Gary: Actually I don’t think it is
synchronization problem.
The scene is as following:I have two different devices (d1 and d2). I assume the system
will scan
slots from slot 1 to slot 2. If d1 is in slot 1 and d2 in
slot 2, the driver
works perfect, but when I put d2 in slot 1 and d1 in slot2,
the driver stops
right before IoConnectInterrupt routine for the d1 device
which is in slot2.
It sounds to me that device d2 has some effect on device d1
if the interrupt
for d2 has been connected before d1 does. Based on my
observation from IRQ,
it seems that d2 requires d1 have the same IRQ number as its.
It is kind of
strange because I think d1 and d2 are independent(am I right?). I have
changed IoReportResouceUsage routine parameters and let it
claim resources
on driver bases or on device bases, but either will not help
me anything. So
I am confused. What could I do to explore this problem? Do
you have any
further suggestion? Thanks.Z.S.Wang
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Thanks, Mark, The driver stops right at the second IoConnectInterrupt. The
debugee machine which running the driver loses its mouse and keyboard. I
think the CPU is locked somewhere, but the system does not crash.
It only causes problem when 2 devices have different IRQs and device #2 is
scanned by the system in front of device #1. Even though 2 devices have 2
different IRQs, it will not cause any problem when device #1 is scanned
before device #2. Furthermore, if I put 2 device #1, there is no problem to
run the driver, but if I put 2 device #2 in my computer, it causes the same
problem as I put one device #2 and one device #1 in the system in that
order.
It sounds to me that device #2 has some defect, but I am not sure. THe
hardware engineer claims that device #2 is modified based on device #1, but
obviously these two devices have the different effects when they run in the
system. SO what is your comments? Thanks.
Z.S.Wang