|
John Murphy
06/28/2010 8:59 AM
post57965
|
I'm working on a new io-pkt Ethernet driver under 6.4.1, and am
experiencing some strange behavior. If I unload the driver (ifconfig
destroy) and then try to load (mount) a new version, the driver that
gets "loaded" is frequently the old driver, the one I just unloaded and
which no longer exists on the disk; i.e., it's as if the unloaded driver
is still in memory, and an attempt to load a new version simply
"reactivates" the version still in memory, instead of loading a copy
from disk. I realize that this would be the expected action if I had
multiple interfaces using the one driver and didn't unload all of them,
but that is not the case. Even stranger, static variables that should
be initialized at startup are NOT initialized, but have the same values
that had just before the driver was unloaded. All the symptoms seem to
suggest that for some reason the driver never completely unloaded, but
I've looked through all the relevant code and can't find anything that
would explain such behavior.
Anyone has any ideas about what I should look for?
Murf
|
|
|
|
|
|
Hugh Brown
06/28/2010 9:23 AM
post57969
|
I would imagine that the driver is being cached in memory. Have to tried to
'umount' the driver rather than using ifconfig destroy? Do you specify the
full path to the driver in the mount command?
On 10-06-28 8:59 AM, "John Murphy" <community-noreply@qnx.com> wrote:
> I'm working on a new io-pkt Ethernet driver under 6.4.1, and am
> experiencing some strange behavior. If I unload the driver (ifconfig
> destroy) and then try to load (mount) a new version, the driver that
> gets "loaded" is frequently the old driver, the one I just unloaded and
> which no longer exists on the disk; i.e., it's as if the unloaded driver
> is still in memory, and an attempt to load a new version simply
> "reactivates" the version still in memory, instead of loading a copy
> from disk. I realize that this would be the expected action if I had
> multiple interfaces using the one driver and didn't unload all of them,
> but that is not the case. Even stranger, static variables that should
> be initialized at startup are NOT initialized, but have the same values
> that had just before the driver was unloaded. All the symptoms seem to
> suggest that for some reason the driver never completely unloaded, but
> I've looked through all the relevant code and can't find anything that
> would explain such behavior.
>
> Anyone has any ideas about what I should look for?
>
>
> Murf
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post57965
>
--
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
|
|
|
|
|
|
John Murphy
06/28/2010 10:19 AM
post57976
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Have not tried 'umount' --- didn't think that worked in 6.4! What do
you umount?<br>
And yes, the full path is specidief in the mount command.<br>
<br>
Murf<br>
<br>
Hugh Brown wrote:
<blockquote
cite="mid:17643911.1277731382293.JavaMail.sf-admin@community.qnx.com"
type="cite">
<pre wrap="">I would imagine that the driver is being cached in memory. Have to tried to
'umount' the driver rather than using ifconfig destroy? Do you specify the
full path to the driver in the mount command?
On 10-06-28 8:59 AM, "John Murphy" <a class="moz-txt-link-rfc2396E" href="mailto:community-noreply@qnx.com"><community-
noreply@qnx.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I'm working on a new io-pkt Ethernet driver under 6.4.1, and am
experiencing some strange behavior. If I unload the driver (ifconfig
destroy) and then try to load (mount) a new version, the driver that
gets "loaded" is frequently the old driver, the one I just unloaded and
which no longer exists on the disk; i.e., it's as if the unloaded driver
is still in memory, and an attempt to load a new version simply
"reactivates" the version still in memory, instead of loading a copy
from disk. I realize that this would be the expected action if I had
multiple interfaces using the one driver and didn't unload all of them,
but that is not the case. Even stranger, static variables that should
be initialized at startup are NOT initialized, but have the same values
that had just before the driver was unloaded. All the symptoms seem to
suggest that for some reason the driver never completely unloaded, but
I've looked through all the relevant code and can't find anything that
would explain such behavior.
Anyone has any ideas about what I should look for?
Murf
_______________________________________________
Networking Drivers
<a class="moz-txt-link-freetext" href="http://community.qnx.com/sf/go/post57965">http://community.qnx.com/sf/go/
post57965</a>;
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
|
|
|
|
|
|
Hugh Brown
06/28/2010 10:35 AM
post57978
|
I was thinking io-net! :-( You are right, you have to use the 'ifconfig
destroy' to umnount the driver. Do you have a detach function defined in
your driver?
On 10-06-28 10:19 AM, "John Murphy" <community-noreply@qnx.com> wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Have not tried 'umount' --- didn't think that worked in 6.4! What do
> you umount?<br>
> And yes, the full path is specidief in the mount command.<br>
> <br>
> Murf<br>
> <br>
> Hugh Brown wrote:
> <blockquote
> cite="mid:17643911.1277731382293.JavaMail.sf-admin@community.qnx.com"
> type="cite">
> <pre wrap="">I would imagine that the driver is being cached in memory. Have
> to tried to
> 'umount' the driver rather than using ifconfig destroy? Do you specify the
> full path to the driver in the mount command?
>
>
> On 10-06-28 8:59 AM, "John Murphy" <a class="moz-txt-link-rfc2396E"
> href="mailto:community-noreply@qnx.com"><community-noreply@qnx.com></a>
> wrote:
>
> </pre>
> <blockquote type="cite">
> <pre wrap="">I'm working on a new io-pkt Ethernet driver under 6.4.1, and
> am
> experiencing some strange behavior. If I unload the driver (ifconfig
> destroy) and then try to load (mount) a new version, the driver that
> gets "loaded" is frequently the old driver, the one I just unloaded and
> which no longer exists on the disk; i.e., it's as if the unloaded driver
> is still in memory, and an attempt to load a new version simply
> "reactivates" the version still in memory, instead of loading a copy
> from disk. I realize that this would be the expected action if I had
> multiple interfaces using the one driver and didn't unload all of them,
> but that is not the case. Even stranger, static variables that should
> be initialized at startup are NOT initialized, but have the same values
> that had just before the driver was unloaded. All the symptoms seem to
> suggest that for some reason the driver never completely unloaded, but
> I've looked through all the relevant code and can't find anything that
> would explain such behavior.
>
> Anyone has any ideas about what I should look for?
>
>
> Murf
>
>
>
> _______________________________________________
>
> Networking Drivers
> <a class="moz-txt-link-freetext"
> href="http://community.qnx.com/sf/go/post57965">http://community.qnx.com/sf/go
> /post57965</a>
>
> </pre>
> </blockquote>
> <pre wrap=""><!---->
> </pre>
> </blockquote>
> </body>
> </html>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post57976
>
--
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
|
|
|
|
|
|
John Murphy
06/28/2010 10:55 AM
post57980
|
Yes, I have a detach function and I haven't been able to find anything
in the system code that would explain leaving the driver in memory. Is
there any way to verify that 'dlclose' actually got called?
Murf
Hugh Brown wrote:
> I was thinking io-net! :-( You are right, you have to use the 'ifconfig
> destroy' to umnount the driver. Do you have a detach function defined in
> your driver?
>
>
> On 10-06-28 10:19 AM, "John Murphy" <community-noreply@qnx.com> wrote:
>
>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>> <html>
>> <head>
>> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>> </head>
>> <body bgcolor="#ffffff" text="#000000">
>> Have not tried 'umount' --- didn't think that worked in 6.4! What do
>> you umount?<br>
>> And yes, the full path is specidief in the mount command.<br>
>> <br>
>> Murf<br>
>> <br>
>> Hugh Brown wrote:
>> <blockquote
>> cite="mid:17643911.1277731382293.JavaMail.sf-admin@community.qnx.com"
>> type="cite">
>> <pre wrap="">I would imagine that the driver is being cached in memory. Have
>> to tried to
>> 'umount' the driver rather than using ifconfig destroy? Do you specify the
>> full path to the driver in the mount command?
>>
>>
>> On 10-06-28 8:59 AM, "John Murphy" <a class="moz-txt-link-rfc2396E"
>> href="mailto:community-noreply@qnx.com"><community-noreply@qnx.com></a>
>> wrote:
>>
>> </pre>
>> <blockquote type="cite">
>> <pre wrap="">I'm working on a new io-pkt Ethernet driver under 6.4.1, and
>> am
>> experiencing some strange behavior. If I unload the driver (ifconfig
>> destroy) and then try to load (mount) a new version, the driver that
>> gets "loaded" is frequently the old driver, the one I just unloaded and
>> which no longer exists on the disk; i.e., it's as if the unloaded driver
>> is still in memory, and an attempt to load a new version simply
>> "reactivates" the version still in memory, instead of loading a copy
>> from disk. I realize that this would be the expected action if I had
>> multiple interfaces using the one driver and didn't unload all of them,
>> but that is not the case. Even stranger, static variables that should
>> be initialized at startup are NOT initialized, but have the same values
>> that had just before the driver was unloaded. All the symptoms seem to
>> suggest that for some reason the driver never completely unloaded, but
>> I've looked through all the relevant code and can't find anything that
>> would explain such behavior.
>>
>> Anyone has any ideas about what I should look for?
>>
>>
>> Murf
>>
>>
>>
>> _______________________________________________
>>
>> Networking Drivers
>> <a class="moz-txt-link-freetext"
>> href="http://community.qnx.com/sf/go/post57965">http://community.qnx.com/sf/go
>> /post57965</a>
>>
>> </pre>
>> </blockquote>
>> <pre wrap=""><!---->
>> </pre>
>> </blockquote>
>> </body>
>> </html>
>>
>>
>>
>> _______________________________________________
>>
>> Networking Drivers
>> http://community.qnx.com/sf/go/post57976
>>
>>
>
>
|
|
|
|
|
|
Sean Boudreau(deleted)
06/28/2010 11:06 AM
post57982
|
On Mon, Jun 28, 2010 at 10:55:19AM -0400, John Murphy wrote:
> Yes, I have a detach function and I haven't been able to find anything
> in the system code that would explain leaving the driver in memory. Is
> there any way to verify that 'dlclose' actually got called?
It won't show up in 'pidin me'.
Regards,
-seanb
|
|
|
|
|
|
John Murphy
06/28/2010 11:55 AM
post57988
|
Ah, that beings up the "buglet" in #PR43050 --- my drivers and filters
usually are reported by pidin as having the name "zero", which makes it
a bit difficult to tell which ones are still in memory. But it appears
that it is only after some (as yet undetermined) amount of activity that
the driver doesn't get completely unloaded. That at least gives me
something to look for.
Murf
Sean Boudreau wrote:
> On Mon, Jun 28, 2010 at 10:55:19AM -0400, John Murphy wrote:
>
>> Yes, I have a detach function and I haven't been able to find anything
>> in the system code that would explain leaving the driver in memory. Is
>> there any way to verify that 'dlclose' actually got called?
>>
>
> It won't show up in 'pidin me'.
>
> Regards,
>
> -seanb
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post57982
>
>
|
|
|
|
|
|
John Murphy
06/28/2010 12:13 PM
post57990
|
Aha! I may have discovered something. My Ethernet driver seems to
unload and reload properly as long as it is the last module loaded; but
if I load the driver, then mount my lsm "filter", then destroy the
driver, pidin shows both the driver and the lsm still in memory. If I
then unload my lsm, the driver also disappears from memory! Does that
ring any bells?
Murf
Sean Boudreau wrote:
> On Mon, Jun 28, 2010 at 10:55:19AM -0400, John Murphy wrote:
>
>> Yes, I have a detach function and I haven't been able to find anything
>> in the system code that would explain leaving the driver in memory. Is
>> there any way to verify that 'dlclose' actually got called?
>>
>
> It won't show up in 'pidin me'.
>
> Regards,
>
> -seanb
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post57982
>
>
|
|
|
|
|
|
John Murphy
06/29/2010 9:50 AM
post58048
|
I've done some more experiments, and I find that I can completely unload
devnp-e1000.so even when my own Ethernet driver and lsm are loaded after
it, whereas /my /driver stays around until I unload my lsm. Could this
all be part of the bug referenced in #PR43050, since both my driver and
my lsm show up in pidin with the name "zero"?
Murf
Sean Boudreau wrote:
> On Mon, Jun 28, 2010 at 10:55:19AM -0400, John Murphy wrote:
>
>> Yes, I have a detach function and I haven't been able to find anything
>> in the system code that would explain leaving the driver in memory. Is
>> there any way to verify that 'dlclose' actually got called?
>>
>
> It won't show up in 'pidin me'.
>
> Regards,
>
> -seanb
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post57982
>
>
|
|
|
|
|
|
Sean Boudreau(deleted)
06/29/2010 9:52 AM
post58050
|
On Tue, Jun 29, 2010 at 09:50:14AM -0400, John Murphy wrote:
> I've done some more experiments, and I find that I can completely unload
> devnp-e1000.so even when my own Ethernet driver and lsm are loaded after
> it, whereas /my /driver stays around until I unload my lsm. Could this
> all be part of the bug referenced in #PR43050, since both my driver and
> my lsm show up in pidin with the name "zero"?
>
Are your driver and lsm in the same dll?
-seanb
|
|
|
|
|
|
John Murphy
06/29/2010 9:53 AM
post58052
|
No, completely separate files.
Murf
Sean Boudreau wrote:
> On Tue, Jun 29, 2010 at 09:50:14AM -0400, John Murphy wrote:
>
>> I've done some more experiments, and I find that I can completely unload
>> devnp-e1000.so even when my own Ethernet driver and lsm are loaded after
>> it, whereas /my /driver stays around until I unload my lsm. Could this
>> all be part of the bug referenced in #PR43050, since both my driver and
>> my lsm show up in pidin with the name "zero"?
>>
>>
>
> Are your driver and lsm in the same dll?
>
> -seanb
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post58050
>
>
|
|
|
|
|
|
Sean Boudreau(deleted)
06/30/2010 10:49 AM
post58202
|
On Tue, Jun 29, 2010 at 09:53:47AM -0400, John Murphy wrote:
> No, completely separate files.
I can't see how it would happen then. Can you tar up a small
test case?
-seanb
|
|
|
|
|
|
John Murphy
06/30/2010 2:21 PM
post58235
|
The difficulty with a test case is that my Ethernet driver is for the
Intel 82599 10-Gigabit part, and I doubt that you have the hardware to
support it. The problem only seems to manifest itself with two modules
both of which show up in pidin with the name "zero", and despite many
hours of test and experimentation, we've never been able to figure out
what it is that makes some modules do that. So if I could build a
sample driver that came up with name "zero", I suspect that it would
have the same unload problem, but since I don't how to trigger that bug,
I can't even prove the relationship, let alone send a test case. The
"zero" name bug has been outstanding for over a year now; is there any
schedule for fixing it?
Murf
Sean Boudreau wrote:
> On Tue, Jun 29, 2010 at 09:53:47AM -0400, John Murphy wrote:
>
>> No, completely separate files.
>>
>
> I can't see how it would happen then. Can you tar up a small
> test case?
>
> -seanb
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post58202
>
>
|
|
|
|
|
|
Sean Boudreau(deleted)
06/30/2010 2:36 PM
post58238
|
On Wed, Jun 30, 2010 at 02:21:06PM -0400, John Murphy wrote:
> The difficulty with a test case is that my Ethernet driver is for the
> Intel 82599 10-Gigabit part, and I doubt that you have the hardware to
> support it. The problem only seems to manifest itself with two modules
> both of which show up in pidin with the name "zero", and despite many
> hours of test and experimentation, we've never been able to figure out
> what it is that makes some modules do that. So if I could build a
> sample driver that came up with name "zero", I suspect that it would
> have the same unload problem, but since I don't how to trigger that bug,
> I can't even prove the relationship, let alone send a test case. The
> "zero" name bug has been outstanding for over a year now; is there any
> schedule for fixing it?
>
It's currently scheduled for 6.6; however from the discription
in the PR it doesn't really sound like it could cause this
behaviour.
Regards,
0seanb
|
|
|
|
|
|
John Murphy
07/01/2010 3:26 PM
post58303
|
Did some more testing, found some points of interest. I changed enough
code in my driver that pidin now shows its correct name! I still have
no idea what mechanisms come into play there, but it did prove that, as
you suspected, the unloading problem is unrelated to the "zero" name
problem. I also verified that my driver and lsm are "dependent" on each
other to the extent that, regardless of the order in which they are
loaded, the last loaded must be unloaded before the first loaded will
leave memory.
But the point that you will probably find most interesting is that I was
mistaken about the machine running 6.4.1! We've apparently got too many
cooks in the kitchen, or at least enough to keep me confused about
what's running on which test box. The unloading/reloading problem
manifests itself only on 6.5.0 Alpha! Sorry for the previous
misinformation!
Murf
Sean Boudreau wrote:
> On Wed, Jun 30, 2010 at 02:21:06PM -0400, John Murphy wrote:
>
>> The difficulty with a test case is that my Ethernet driver is for the
>> Intel 82599 10-Gigabit part, and I doubt that you have the hardware to
>> support it. The problem only seems to manifest itself with two modules
>> both of which show up in pidin with the name "zero", and despite many
>> hours of test and experimentation, we've never been able to figure out
>> what it is that makes some modules do that. So if I could build a
>> sample driver that came up with name "zero", I suspect that it would
>> have the same unload problem, but since I don't how to trigger that bug,
>> I can't even prove the relationship, let alone send a test case. The
>> "zero" name bug has been outstanding for over a year now; is there any
>> schedule for fixing it?
>>
>>
>
> It's currently scheduled for 6.6; however from the discription
> in the PR it doesn't really sound like it could cause this
> behaviour.
>
> Regards,
>
> 0seanb
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post58238
>
>
|
|
|
|
|
|
