- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I was attempting to get the VTune driver running on Fedora Core 6 on P4-HT (i686; kernel: 2.6.18-1.2849.fc6). I was able to successfully compile the driver. When I tried to install the module, I got the following error:
# insmod vtune_drv-x32-2.6.18-1.2849.fc6smp.ko
insmod: error inserting 'vtune_drv-x32-2.6.18-1.2849.fc6smp.ko': -1 Unknown symbol in module
The dmesg indicates that unknown symbol is "tasklist_lock".
vtune_drv: Unknown symbol tasklist_lock
Can you please help me with this?
Thanks and Regards
Keshavan
I was attempting to get the VTune driver running on Fedora Core 6 on P4-HT (i686; kernel: 2.6.18-1.2849.fc6). I was able to successfully compile the driver. When I tried to install the module, I got the following error:
# insmod vtune_drv-x32-2.6.18-1.2849.fc6smp.ko
insmod: error inserting 'vtune_drv-x32-2.6.18-1.2849.fc6smp.ko': -1 Unknown symbol in module
The dmesg indicates that unknown symbol is "tasklist_lock".
vtune_drv: Unknown symbol tasklist_lock
Can you please help me with this?
Thanks and Regards
Keshavan
Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have some more updates with regard to the errors seen on FC6 (kernel: 2.6.18). The support for tasklist_lock has been removed from the 2.6.18 kernel. Also a solution has been proposed for libafs in the link below. http://www.mail-archive.com/openafs-info@openafs.org/msg22061.html
It is proposed that read_lock and read_unlock be replaced with rcu_read_lock() and rcu_read_unlock(). However I did not find an alternative call for read_trylock() which is being used in vtune.c (function: get_tgid_trylock). This function uses TGID_TRY and TGID_RELEASE macros (defined in vtprotos.h). I was considering replacing this with rcu_read_lock and rcu_read_unlock, since I dont know an alternative technique. However the comments in the code indicate:
// Since we want the interrupt handler to avoid possible deadlock
// due to a spin on the tasklist_lock, we will use the read_trylock()
// call when it is available, but when it isn't we'll use the more
// heavy handed write_trylock() which is available on all the kernels
// we support...
I modified the driver, compiled it and loaded it. There does not seem to be any errors so far. Since I am not a kernel programmer and have no familiarity with Linux kernel, this needs some more investigation from the more knowledgable ones. Can someone give me some guidance on this?
Many Thanks,
Regards
--Keshavan
It is proposed that read_lock and read_unlock be replaced with rcu_read_lock() and rcu_read_unlock(). However I did not find an alternative call for read_trylock() which is being used in vtune.c (function: get_tgid_trylock). This function uses TGID_TRY and TGID_RELEASE macros (defined in vtprotos.h). I was considering replacing this with rcu_read_lock and rcu_read_unlock, since I dont know an alternative technique. However the comments in the code indicate:
// Since we want the interrupt handler to avoid possible deadlock
// due to a spin on the tasklist_lock, we will use the read_trylock()
// call when it is available, but when it isn't we'll use the more
// heavy handed write_trylock() which is available on all the kernels
// we support...
I modified the driver, compiled it and loaded it. There does not seem to be any errors so far. Since I am not a kernel programmer and have no familiarity with Linux kernel, this needs some more investigation from the more knowledgable ones. Can someone give me some guidance on this?
Many Thanks,
Regards
--Keshavan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Keshavan
This is a know issue. It will be addressed in the 8.0.3 product update which is expected soon. Please upgrade your version once it's released.
Regards, Andrei
This is a know issue. It will be addressed in the 8.0.3 product update which is expected soon. Please upgrade your version once it's released.
Regards, Andrei
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
You could replace all references to read_lock(&tasklist) by rcu_read_lock and similiarly for read_unlock.
Now try_lock tries to get a lock before 10,000 spins or retire; If you think a lock can be acquires within lesser spins, you CAN use a rcu_read_lock in place. (and the release part is a rcu_read_unlock)
I don't think this is what was required, though.
You could replace all references to read_lock(&tasklist) by rcu_read_lock and similiarly for read_unlock.
Now try_lock tries to get a lock before 10,000 spins or retire; If you think a lock can be acquires within lesser spins, you CAN use a rcu_read_lock in place. (and the release part is a rcu_read_unlock)
I don't think this is what was required, though.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Note: Fedora Core* 6 is not supported by any available releases. Please watch http://www.intel.com/software/products/vtunefor updates.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I wonder does anyone have a timeline on that?
Regards
Mike Brady
Regards
Mike Brady
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, i'm running FC5 with a new 2.6.20 kernel - has anyone managed to compile the vkl code by replacing read_try_lock with the rcu versions? If so, could someone send the patch?
Thanks,
Shash
Thanks,
Shash
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have modified the code and compiled it for 2.6.18 kernel. I can send you the modified source code. I dont know how to create a patch for the same. Let me know if you want it.
Regards
Keshavan

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page