Menu
▾
▴
open-vm-tools-devel — List for open-vm-tools developer discussions.
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(30) |
Oct
(50) |
Nov
(42) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(36) |
Feb
(13) |
Mar
(74) |
Apr
(17) |
May
(62) |
Jun
(53) |
Jul
(32) |
Aug
(58) |
Sep
(44) |
Oct
(21) |
Nov
(35) |
Dec
(53) |
| 2009 |
Jan
(43) |
Feb
(58) |
Mar
(14) |
Apr
(16) |
May
(61) |
Jun
(49) |
Jul
(11) |
Aug
(22) |
Sep
(37) |
Oct
(12) |
Nov
(23) |
Dec
(10) |
| 2010 |
Jan
(21) |
Feb
(13) |
Mar
(5) |
Apr
(18) |
May
(14) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
(13) |
Oct
(8) |
Nov
(11) |
Dec
(14) |
| 2011 |
Jan
(13) |
Feb
(19) |
Mar
(16) |
Apr
(10) |
May
(22) |
Jun
(4) |
Jul
(63) |
Aug
(14) |
Sep
(10) |
Oct
(12) |
Nov
(10) |
Dec
(43) |
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
(35) |
Apr
(1) |
May
(32) |
Jun
(8) |
Jul
(10) |
Aug
(6) |
Sep
(3) |
Oct
(25) |
Nov
(14) |
Dec
(4) |
| 2013 |
Jan
(12) |
Feb
(6) |
Mar
(15) |
Apr
(24) |
May
(9) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(3) |
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2015 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: cornel <co...@up...> - 2009-03-23 20:01:16
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML><HEAD><title>Untitled-1</title> <META content="text/html; charset=iso-8859-1" http-equiv=content-type> <META name=GENERATOR content="Email Marketer Message Editor"></HEAD> <BODY> <DIV style="Z-INDEX: 0; POSITION: absolute; WIDTH: 707px; HEIGHT: 582px; OVERFLOW: hidden; TOP: 61px; LEFT: 120px" id=text1> <DIV class=wpmd> <DIV><FONT class=ws12> </FONT><FONT class=ws14> </FONT><FONT class=ws14><B><I>EVRIKA GROUP</I></B></FONT><FONT class=ws12> - </FONT><FONT class=ws12><A title="" href="http://www.cursonline.eu/">cursuri de perfectionare</A></FONT><FONT class=ws12> :</FONT></DIV> <DIV><FONT class=ws12>-</FONT><FONT class=ws12><A title="" href="http://www.cursonline.eu/index.php?index=contabilitate">contabilitate</A></FONT><FONT class=ws12> - costul cursului este de 350 ron, cu incepere din 4 mai 2009;</FONT></DIV> <DIV><FONT class=ws12>-</FONT><FONT class=ws12><A title="" href="http://www.cursonline.eu/index.php?index=ipm">inspector protectia muncii - nivel baza (studii medii - 40 ore )</A></FONT><FONT class=ws12> - costul cursului este de 300 ron, cu incepere din 11 mai 2009</FONT></DIV> <DIV><FONT class=ws12>-</FONT><FONT class=ws12><A title="" href="http://www.cursonline.eu/index.php?index=ipmm">inspector protectia muncii - nivel mediu (studii superioare tehnice - 80 ore )</A></FONT><FONT class=ws12> - costul cursului este de 450 ron, cu incepere din 11 mai 2009</FONT></DIV> <DIV><FONT class=ws12>-</FONT><FONT class=ws12><A title="" href="http://www.cursonline.eu/index.php?index=iru">inspector resurse umane</A></FONT><FONT class=ws12> - costul cursului este de 300 ron, cu incepere din 7 aprilie 2009</FONT></DIV> <DIV><FONT class=ws12><BR></FONT></DIV> <DIV><FONT class=ws12 color=#003366><I>NOU : pentru cursantii care din diferite motive nu ajung la o sedinta de curs, sau vor sa aprofundeze un subiect sau altul dezbatute in cadrul sedintelor de curs, avem si suport online.</I></FONT></DIV> <DIV><FONT class=ws12><I><BR></I></FONT></DIV> <DIV align=center><FONT class=ws12> In urma sustinerii examenului final se obtine un CERTIFICAT DE ABSOLVIRE eliberat de MINISTERUL MUNCII FAMILIEI SI EGALITATII DE SANSE si MINISTERUL EDUCATIEI CERCETARII SI TINERETULUI recunoscut pe piata muncii.</FONT></DIV> <DIV align=center><FONT class=ws12> Daca vreti sa profitati de oportunitatile ce pot aparea apasati </FONT><FONT class=ws12><A title="" href="mailto:sub...@ev...">SUBSCRIBE</A></FONT><FONT class=ws12>, daca nu, apasati </FONT><FONT class=ws12><A title="" href="mailto:uns...@ev...">UNSUBSCRIBE.</A></FONT></DIV></DIV></DIV></BODY></HTML> |
|
From: Maguet F. <mis...@io...> - 2009-03-22 20:49:01
|
Second passionatte youth <http://cid-c33f9779bc92f1ce.spaces.live.com/blog/cns!C33F9779BC92F1CE!104.entry> In every possible way in these early stages, and let us enjoy ourselves today by feasting on this of his mistake, molloy took back the l100 receipt mustered together fiftytwo crores of monkeys.94 no sin can touch them. Such men always increase. |
|
From: Haggin H. <mon...@re...> - 2009-03-18 13:56:55
|
Bigger thing, even mmore satisfaction http://cid-f1385a3327179c3c.spaces.live.com/blog/cns!F1385A3327179C3C!106.entry Troubling. Of course i hummed and hawed, and made filling the region with miniature melodies. But approached the monks, whatever that might be. There are some three dozen in kashanor to the interesting to scott, from containing the family. |
|
From: Dominique L. <Dom...@TM...> - 2009-03-17 10:42:46
|
Hi everybody. Some questions for you: VMware 6.5.1 modules do not compile on kernel 2.6.29 anymore, thus breaking execution of VMware on systems running latest kernels. Is there already an update available (at some place?) The modules to be installed on a guest and host are almost identical. the open-vm-tools are targetted to be installed on a guest. They have been updated already to support kernel 2.6.29. How much of an effort would it be to have open-vm-tools adopted to also be able to run on the HOST? What additions need to be done? Havint the open-vm-tools also available for the host part could eliminate users running into an updated kernel without having the proper kernel modules available anymore. On openSUSE (and SLE) for example, if the kernel modules are also installed by the package manager, you get a warning about future missing modules if you go for installing the updated kernel. Thus warning / informing the user well in advance. Updated module packages could be provided by distributions together with the updated kernel (same as done now for open-vm-tools, targeted at the guest systems). Dominique |
|
From: SourceForge.net <no...@so...> - 2009-03-04 22:32:48
|
Tracker item #2658928, was opened at 2009-03-03 23:24 Message generated for change (Comment added) made by eisiware You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sisternicky (eisiware) Assigned to: Nobody/Anonymous (nobody) Summary: vsock module not loadable into the kernel (2.6.28.7) Initial Comment: Hi, on my new kernel, the module vsock will not load. On modprobing, it returns the following error message: root [ ~ ]# modprobe -v vsock insmod /lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko FATAL: Error inserting vsock (/lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko): Unknown symbol in module, or unknown parameter (see dmesg) and here follows the kernel log: Mar 3 23:18:40 landfrauen kernel: [ 1912.571989] vsock: no symbol version for VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572151] vsock: Unknown symbol VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572285] vsock: no symbol version for VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572382] vsock: Unknown symbol VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572514] vsock: no symbol version for VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572595] vsock: Unknown symbol VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572864] vsock: no symbol version for VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572946] vsock: Unknown symbol VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572953] vsock: no symbol version for VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.572959] vsock: Unknown symbol VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.573510] vsock: no symbol version for VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573594] vsock: Unknown symbol VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573977] vsock: no symbol version for VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574062] vsock: Unknown symbol VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574395] vsock: no symbol version for VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574471] vsock: Unknown symbol VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574636] vsock: no symbol version for VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574713] vsock: Unknown symbol VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574947] vsock: no symbol version for VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575027] vsock: Unknown symbol VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575162] vsock: no symbol version for VMCIDatagram_CreateHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575240] vsock: Unknown symbol VMCIDatagram_CreateHnd all other modules load fine. Is there any fix known already? ---------------------------------------------------------------------- >Comment By: Sisternicky (eisiware) Date: 2009-03-04 23:32 Message: I'm using open-vm-tools-2009.02.18-148847 I did a toplevel build of the tools, the config.log is attached. File Added: config.log ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-04 22:48 Message: Also, what version of open-vm-tools are you using? ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-04 20:06 Message: Ok so we have established that it is a CONFIG_MODVERSIONS problem. Can you provide some more details about what steps you took to build the vsock module. Did you do a top level make in open-vm-tools or something else? I'd still like to get to the bottom of why you ended up with a module that wasn't built against VMCI symbols. ---------------------------------------------------------------------- Comment By: Sisternicky (eisiware) Date: 2009-03-04 17:42 Message: Yes, it does. My modules are modprobed by bootscript (all of the vmware modules), with vsock being last. ---------------------------------------------------------------------- Comment By: Giandomenico De Tullio (kheru) Date: 2009-03-04 15:36 Message: Are VMCI* symbols exported by vmci.ko module ?! If you modprobe vmci.ko BEFORE modprobe-ing vsock returns the same error? dependencies problem ?! ( depmod -a ? ^.- ) ---------------------------------------------------------------------- Comment By: Sisternicky (eisiware) Date: 2009-03-04 08:40 Message: Hi again, thanks for the quick answer. There is an (empty) Module.symvers file in the module build directory modprobe --dump-modversions ./vsock.ko: 0x4f8d5728 struct_module 0x7faa1013 release_sock 0x33c3a362 per_cpu__current_task 0x12da5bb2 __kmalloc 0x5e22aa50 sock_init_data 0xb279da12 pv_lock_ops 0xd42b7232 _write_unlock_bh 0x3f4d635c sock_no_setsockopt 0xc8b57c27 autoremove_wake_function 0xa1801a2e sock_no_getsockopt 0xbe447f76 sock_no_ioctl 0x973873ab _spin_lock 0x8949858b schedule_work 0x5acb8506 sock_queue_rcv_skb 0x6729d3df __get_user_4 0x47a346b3 skb_recv_datagram 0xed06ac02 sock_no_sendpage 0xbd31d52f sock_no_mmap 0x4ba758f9 misc_register 0x7afd8702 sock_no_socketpair 0x2254d547 sk_alloc 0xa2a1e5c9 _write_lock_bh 0xb72397d5 printk 0xc642a151 lock_sock_nested 0x2da418b5 copy_to_user 0xa8eb44f9 sock_no_listen 0xd2123419 sock_no_accept 0x293beace sk_free 0x748caf40 down 0xa368017a init_net 0x7dceceac capable 0x934b1816 proto_register 0xb2fd5ceb __put_user_4 0x85c9c6af __alloc_skb 0x82673561 schedule_delayed_work 0x3c9b4b67 sock_register 0xd62c833f schedule_timeout 0x7f8da821 kfree_skb 0x0fc26794 proto_unregister 0x88dff1b9 skb_copy_datagram_iovec 0x2253d3c5 sk_receive_skb 0x6111e1bc init_timer 0x57a6504e vsnprintf 0x3aa1dbcf _spin_unlock_bh 0x037a0cba kfree 0x0e762d6e request_module 0x33d92f9a prepare_to_wait 0x62737e1d sock_unregister 0x9fb3dd30 memcpy_fromiovec 0x3f1899f1 up 0x9ccb2622 finish_wait 0x08a56041 skb_dequeue 0x701d0ebd snprintf 0x93cbd1ec _spin_lock_bh 0xc5456b60 skb_put 0xf2a644fb copy_from_user 0xc5b0fa1a misc_deregister 0xb052f6a9 skb_free_datagram 0x0da10ec3 security_sock_graft and you are right :) with --force-modversion the module loads find. Hope the info helps. ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-04 01:08 Message: It sounds like you have a newer kernel built with CONFIG_MODVERSIONS and the vsock module doesn't know about the vmci module symbol versions so the kernel is refusing to load it. This should work ... I'm interested to figure out what went wrong. First let me say that you should be able to force the kernel to load the module by using --force-modversion (although then you bypass CONFIG_MODVERSIONS which we would like to avoid). Is there a Module.symvers file in the vsock module build directory? If so, what are the contents? What is the contents of the __versions section of the module? modprobe --dump-modversions ./vsock.ko should give the info. It would also be interesting to see the output of nm ./vmci.ko | grep __crc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-03-04 21:48:54
|
Tracker item #2658928, was opened at 2009-03-03 17:24 Message generated for change (Comment added) made by microchip21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sisternicky (eisiware) Assigned to: Nobody/Anonymous (nobody) Summary: vsock module not loadable into the kernel (2.6.28.7) Initial Comment: Hi, on my new kernel, the module vsock will not load. On modprobing, it returns the following error message: root [ ~ ]# modprobe -v vsock insmod /lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko FATAL: Error inserting vsock (/lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko): Unknown symbol in module, or unknown parameter (see dmesg) and here follows the kernel log: Mar 3 23:18:40 landfrauen kernel: [ 1912.571989] vsock: no symbol version for VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572151] vsock: Unknown symbol VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572285] vsock: no symbol version for VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572382] vsock: Unknown symbol VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572514] vsock: no symbol version for VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572595] vsock: Unknown symbol VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572864] vsock: no symbol version for VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572946] vsock: Unknown symbol VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572953] vsock: no symbol version for VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.572959] vsock: Unknown symbol VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.573510] vsock: no symbol version for VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573594] vsock: Unknown symbol VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573977] vsock: no symbol version for VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574062] vsock: Unknown symbol VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574395] vsock: no symbol version for VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574471] vsock: Unknown symbol VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574636] vsock: no symbol version for VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574713] vsock: Unknown symbol VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574947] vsock: no symbol version for VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575027] vsock: Unknown symbol VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575162] vsock: no symbol version for VMCIDatagram_CreateHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575240] vsock: Unknown symbol VMCIDatagram_CreateHnd all other modules load fine. Is there any fix known already? ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-04 16:48 Message: Also, what version of open-vm-tools are you using? ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-04 14:06 Message: Ok so we have established that it is a CONFIG_MODVERSIONS problem. Can you provide some more details about what steps you took to build the vsock module. Did you do a top level make in open-vm-tools or something else? I'd still like to get to the bottom of why you ended up with a module that wasn't built against VMCI symbols. ---------------------------------------------------------------------- Comment By: Sisternicky (eisiware) Date: 2009-03-04 11:42 Message: Yes, it does. My modules are modprobed by bootscript (all of the vmware modules), with vsock being last. ---------------------------------------------------------------------- Comment By: Giandomenico De Tullio (kheru) Date: 2009-03-04 09:36 Message: Are VMCI* symbols exported by vmci.ko module ?! If you modprobe vmci.ko BEFORE modprobe-ing vsock returns the same error? dependencies problem ?! ( depmod -a ? ^.- ) ---------------------------------------------------------------------- Comment By: Sisternicky (eisiware) Date: 2009-03-04 02:40 Message: Hi again, thanks for the quick answer. There is an (empty) Module.symvers file in the module build directory modprobe --dump-modversions ./vsock.ko: 0x4f8d5728 struct_module 0x7faa1013 release_sock 0x33c3a362 per_cpu__current_task 0x12da5bb2 __kmalloc 0x5e22aa50 sock_init_data 0xb279da12 pv_lock_ops 0xd42b7232 _write_unlock_bh 0x3f4d635c sock_no_setsockopt 0xc8b57c27 autoremove_wake_function 0xa1801a2e sock_no_getsockopt 0xbe447f76 sock_no_ioctl 0x973873ab _spin_lock 0x8949858b schedule_work 0x5acb8506 sock_queue_rcv_skb 0x6729d3df __get_user_4 0x47a346b3 skb_recv_datagram 0xed06ac02 sock_no_sendpage 0xbd31d52f sock_no_mmap 0x4ba758f9 misc_register 0x7afd8702 sock_no_socketpair 0x2254d547 sk_alloc 0xa2a1e5c9 _write_lock_bh 0xb72397d5 printk 0xc642a151 lock_sock_nested 0x2da418b5 copy_to_user 0xa8eb44f9 sock_no_listen 0xd2123419 sock_no_accept 0x293beace sk_free 0x748caf40 down 0xa368017a init_net 0x7dceceac capable 0x934b1816 proto_register 0xb2fd5ceb __put_user_4 0x85c9c6af __alloc_skb 0x82673561 schedule_delayed_work 0x3c9b4b67 sock_register 0xd62c833f schedule_timeout 0x7f8da821 kfree_skb 0x0fc26794 proto_unregister 0x88dff1b9 skb_copy_datagram_iovec 0x2253d3c5 sk_receive_skb 0x6111e1bc init_timer 0x57a6504e vsnprintf 0x3aa1dbcf _spin_unlock_bh 0x037a0cba kfree 0x0e762d6e request_module 0x33d92f9a prepare_to_wait 0x62737e1d sock_unregister 0x9fb3dd30 memcpy_fromiovec 0x3f1899f1 up 0x9ccb2622 finish_wait 0x08a56041 skb_dequeue 0x701d0ebd snprintf 0x93cbd1ec _spin_lock_bh 0xc5456b60 skb_put 0xf2a644fb copy_from_user 0xc5b0fa1a misc_deregister 0xb052f6a9 skb_free_datagram 0x0da10ec3 security_sock_graft and you are right :) with --force-modversion the module loads find. Hope the info helps. ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-03 19:08 Message: It sounds like you have a newer kernel built with CONFIG_MODVERSIONS and the vsock module doesn't know about the vmci module symbol versions so the kernel is refusing to load it. This should work ... I'm interested to figure out what went wrong. First let me say that you should be able to force the kernel to load the module by using --force-modversion (although then you bypass CONFIG_MODVERSIONS which we would like to avoid). Is there a Module.symvers file in the vsock module build directory? If so, what are the contents? What is the contents of the __versions section of the module? modprobe --dump-modversions ./vsock.ko should give the info. It would also be interesting to see the output of nm ./vmci.ko | grep __crc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-03-04 19:06:11
|
Tracker item #2658928, was opened at 2009-03-03 17:24 Message generated for change (Comment added) made by microchip21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sisternicky (eisiware) Assigned to: Nobody/Anonymous (nobody) Summary: vsock module not loadable into the kernel (2.6.28.7) Initial Comment: Hi, on my new kernel, the module vsock will not load. On modprobing, it returns the following error message: root [ ~ ]# modprobe -v vsock insmod /lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko FATAL: Error inserting vsock (/lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko): Unknown symbol in module, or unknown parameter (see dmesg) and here follows the kernel log: Mar 3 23:18:40 landfrauen kernel: [ 1912.571989] vsock: no symbol version for VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572151] vsock: Unknown symbol VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572285] vsock: no symbol version for VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572382] vsock: Unknown symbol VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572514] vsock: no symbol version for VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572595] vsock: Unknown symbol VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572864] vsock: no symbol version for VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572946] vsock: Unknown symbol VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572953] vsock: no symbol version for VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.572959] vsock: Unknown symbol VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.573510] vsock: no symbol version for VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573594] vsock: Unknown symbol VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573977] vsock: no symbol version for VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574062] vsock: Unknown symbol VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574395] vsock: no symbol version for VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574471] vsock: Unknown symbol VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574636] vsock: no symbol version for VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574713] vsock: Unknown symbol VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574947] vsock: no symbol version for VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575027] vsock: Unknown symbol VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575162] vsock: no symbol version for VMCIDatagram_CreateHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575240] vsock: Unknown symbol VMCIDatagram_CreateHnd all other modules load fine. Is there any fix known already? ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-04 14:06 Message: Ok so we have established that it is a CONFIG_MODVERSIONS problem. Can you provide some more details about what steps you took to build the vsock module. Did you do a top level make in open-vm-tools or something else? I'd still like to get to the bottom of why you ended up with a module that wasn't built against VMCI symbols. ---------------------------------------------------------------------- Comment By: Sisternicky (eisiware) Date: 2009-03-04 11:42 Message: Yes, it does. My modules are modprobed by bootscript (all of the vmware modules), with vsock being last. ---------------------------------------------------------------------- Comment By: Giandomenico De Tullio (kheru) Date: 2009-03-04 09:36 Message: Are VMCI* symbols exported by vmci.ko module ?! If you modprobe vmci.ko BEFORE modprobe-ing vsock returns the same error? dependencies problem ?! ( depmod -a ? ^.- ) ---------------------------------------------------------------------- Comment By: Sisternicky (eisiware) Date: 2009-03-04 02:40 Message: Hi again, thanks for the quick answer. There is an (empty) Module.symvers file in the module build directory modprobe --dump-modversions ./vsock.ko: 0x4f8d5728 struct_module 0x7faa1013 release_sock 0x33c3a362 per_cpu__current_task 0x12da5bb2 __kmalloc 0x5e22aa50 sock_init_data 0xb279da12 pv_lock_ops 0xd42b7232 _write_unlock_bh 0x3f4d635c sock_no_setsockopt 0xc8b57c27 autoremove_wake_function 0xa1801a2e sock_no_getsockopt 0xbe447f76 sock_no_ioctl 0x973873ab _spin_lock 0x8949858b schedule_work 0x5acb8506 sock_queue_rcv_skb 0x6729d3df __get_user_4 0x47a346b3 skb_recv_datagram 0xed06ac02 sock_no_sendpage 0xbd31d52f sock_no_mmap 0x4ba758f9 misc_register 0x7afd8702 sock_no_socketpair 0x2254d547 sk_alloc 0xa2a1e5c9 _write_lock_bh 0xb72397d5 printk 0xc642a151 lock_sock_nested 0x2da418b5 copy_to_user 0xa8eb44f9 sock_no_listen 0xd2123419 sock_no_accept 0x293beace sk_free 0x748caf40 down 0xa368017a init_net 0x7dceceac capable 0x934b1816 proto_register 0xb2fd5ceb __put_user_4 0x85c9c6af __alloc_skb 0x82673561 schedule_delayed_work 0x3c9b4b67 sock_register 0xd62c833f schedule_timeout 0x7f8da821 kfree_skb 0x0fc26794 proto_unregister 0x88dff1b9 skb_copy_datagram_iovec 0x2253d3c5 sk_receive_skb 0x6111e1bc init_timer 0x57a6504e vsnprintf 0x3aa1dbcf _spin_unlock_bh 0x037a0cba kfree 0x0e762d6e request_module 0x33d92f9a prepare_to_wait 0x62737e1d sock_unregister 0x9fb3dd30 memcpy_fromiovec 0x3f1899f1 up 0x9ccb2622 finish_wait 0x08a56041 skb_dequeue 0x701d0ebd snprintf 0x93cbd1ec _spin_lock_bh 0xc5456b60 skb_put 0xf2a644fb copy_from_user 0xc5b0fa1a misc_deregister 0xb052f6a9 skb_free_datagram 0x0da10ec3 security_sock_graft and you are right :) with --force-modversion the module loads find. Hope the info helps. ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-03 19:08 Message: It sounds like you have a newer kernel built with CONFIG_MODVERSIONS and the vsock module doesn't know about the vmci module symbol versions so the kernel is refusing to load it. This should work ... I'm interested to figure out what went wrong. First let me say that you should be able to force the kernel to load the module by using --force-modversion (although then you bypass CONFIG_MODVERSIONS which we would like to avoid). Is there a Module.symvers file in the vsock module build directory? If so, what are the contents? What is the contents of the __versions section of the module? modprobe --dump-modversions ./vsock.ko should give the info. It would also be interesting to see the output of nm ./vmci.ko | grep __crc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-03-04 16:43:08
|
Tracker item #2658928, was opened at 2009-03-03 23:24 Message generated for change (Comment added) made by eisiware You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sisternicky (eisiware) Assigned to: Nobody/Anonymous (nobody) Summary: vsock module not loadable into the kernel (2.6.28.7) Initial Comment: Hi, on my new kernel, the module vsock will not load. On modprobing, it returns the following error message: root [ ~ ]# modprobe -v vsock insmod /lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko FATAL: Error inserting vsock (/lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko): Unknown symbol in module, or unknown parameter (see dmesg) and here follows the kernel log: Mar 3 23:18:40 landfrauen kernel: [ 1912.571989] vsock: no symbol version for VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572151] vsock: Unknown symbol VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572285] vsock: no symbol version for VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572382] vsock: Unknown symbol VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572514] vsock: no symbol version for VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572595] vsock: Unknown symbol VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572864] vsock: no symbol version for VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572946] vsock: Unknown symbol VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572953] vsock: no symbol version for VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.572959] vsock: Unknown symbol VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.573510] vsock: no symbol version for VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573594] vsock: Unknown symbol VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573977] vsock: no symbol version for VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574062] vsock: Unknown symbol VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574395] vsock: no symbol version for VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574471] vsock: Unknown symbol VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574636] vsock: no symbol version for VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574713] vsock: Unknown symbol VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574947] vsock: no symbol version for VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575027] vsock: Unknown symbol VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575162] vsock: no symbol version for VMCIDatagram_CreateHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575240] vsock: Unknown symbol VMCIDatagram_CreateHnd all other modules load fine. Is there any fix known already? ---------------------------------------------------------------------- >Comment By: Sisternicky (eisiware) Date: 2009-03-04 17:42 Message: Yes, it does. My modules are modprobed by bootscript (all of the vmware modules), with vsock being last. ---------------------------------------------------------------------- Comment By: Giandomenico De Tullio (kheru) Date: 2009-03-04 15:36 Message: Are VMCI* symbols exported by vmci.ko module ?! If you modprobe vmci.ko BEFORE modprobe-ing vsock returns the same error? dependencies problem ?! ( depmod -a ? ^.- ) ---------------------------------------------------------------------- Comment By: Sisternicky (eisiware) Date: 2009-03-04 08:40 Message: Hi again, thanks for the quick answer. There is an (empty) Module.symvers file in the module build directory modprobe --dump-modversions ./vsock.ko: 0x4f8d5728 struct_module 0x7faa1013 release_sock 0x33c3a362 per_cpu__current_task 0x12da5bb2 __kmalloc 0x5e22aa50 sock_init_data 0xb279da12 pv_lock_ops 0xd42b7232 _write_unlock_bh 0x3f4d635c sock_no_setsockopt 0xc8b57c27 autoremove_wake_function 0xa1801a2e sock_no_getsockopt 0xbe447f76 sock_no_ioctl 0x973873ab _spin_lock 0x8949858b schedule_work 0x5acb8506 sock_queue_rcv_skb 0x6729d3df __get_user_4 0x47a346b3 skb_recv_datagram 0xed06ac02 sock_no_sendpage 0xbd31d52f sock_no_mmap 0x4ba758f9 misc_register 0x7afd8702 sock_no_socketpair 0x2254d547 sk_alloc 0xa2a1e5c9 _write_lock_bh 0xb72397d5 printk 0xc642a151 lock_sock_nested 0x2da418b5 copy_to_user 0xa8eb44f9 sock_no_listen 0xd2123419 sock_no_accept 0x293beace sk_free 0x748caf40 down 0xa368017a init_net 0x7dceceac capable 0x934b1816 proto_register 0xb2fd5ceb __put_user_4 0x85c9c6af __alloc_skb 0x82673561 schedule_delayed_work 0x3c9b4b67 sock_register 0xd62c833f schedule_timeout 0x7f8da821 kfree_skb 0x0fc26794 proto_unregister 0x88dff1b9 skb_copy_datagram_iovec 0x2253d3c5 sk_receive_skb 0x6111e1bc init_timer 0x57a6504e vsnprintf 0x3aa1dbcf _spin_unlock_bh 0x037a0cba kfree 0x0e762d6e request_module 0x33d92f9a prepare_to_wait 0x62737e1d sock_unregister 0x9fb3dd30 memcpy_fromiovec 0x3f1899f1 up 0x9ccb2622 finish_wait 0x08a56041 skb_dequeue 0x701d0ebd snprintf 0x93cbd1ec _spin_lock_bh 0xc5456b60 skb_put 0xf2a644fb copy_from_user 0xc5b0fa1a misc_deregister 0xb052f6a9 skb_free_datagram 0x0da10ec3 security_sock_graft and you are right :) with --force-modversion the module loads find. Hope the info helps. ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-04 01:08 Message: It sounds like you have a newer kernel built with CONFIG_MODVERSIONS and the vsock module doesn't know about the vmci module symbol versions so the kernel is refusing to load it. This should work ... I'm interested to figure out what went wrong. First let me say that you should be able to force the kernel to load the module by using --force-modversion (although then you bypass CONFIG_MODVERSIONS which we would like to avoid). Is there a Module.symvers file in the vsock module build directory? If so, what are the contents? What is the contents of the __versions section of the module? modprobe --dump-modversions ./vsock.ko should give the info. It would also be interesting to see the output of nm ./vmci.ko | grep __crc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-03-04 14:36:49
|
Tracker item #2658928, was opened at 2009-03-03 23:24 Message generated for change (Comment added) made by kheru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sisternicky (eisiware) Assigned to: Nobody/Anonymous (nobody) Summary: vsock module not loadable into the kernel (2.6.28.7) Initial Comment: Hi, on my new kernel, the module vsock will not load. On modprobing, it returns the following error message: root [ ~ ]# modprobe -v vsock insmod /lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko FATAL: Error inserting vsock (/lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko): Unknown symbol in module, or unknown parameter (see dmesg) and here follows the kernel log: Mar 3 23:18:40 landfrauen kernel: [ 1912.571989] vsock: no symbol version for VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572151] vsock: Unknown symbol VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572285] vsock: no symbol version for VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572382] vsock: Unknown symbol VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572514] vsock: no symbol version for VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572595] vsock: Unknown symbol VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572864] vsock: no symbol version for VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572946] vsock: Unknown symbol VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572953] vsock: no symbol version for VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.572959] vsock: Unknown symbol VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.573510] vsock: no symbol version for VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573594] vsock: Unknown symbol VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573977] vsock: no symbol version for VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574062] vsock: Unknown symbol VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574395] vsock: no symbol version for VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574471] vsock: Unknown symbol VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574636] vsock: no symbol version for VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574713] vsock: Unknown symbol VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574947] vsock: no symbol version for VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575027] vsock: Unknown symbol VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575162] vsock: no symbol version for VMCIDatagram_CreateHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575240] vsock: Unknown symbol VMCIDatagram_CreateHnd all other modules load fine. Is there any fix known already? ---------------------------------------------------------------------- Comment By: Giandomenico De Tullio (kheru) Date: 2009-03-04 15:36 Message: Are VMCI* symbols exported by vmci.ko module ?! If you modprobe vmci.ko BEFORE modprobe-ing vsock returns the same error? dependencies problem ?! ( depmod -a ? ^.- ) ---------------------------------------------------------------------- Comment By: Sisternicky (eisiware) Date: 2009-03-04 08:40 Message: Hi again, thanks for the quick answer. There is an (empty) Module.symvers file in the module build directory modprobe --dump-modversions ./vsock.ko: 0x4f8d5728 struct_module 0x7faa1013 release_sock 0x33c3a362 per_cpu__current_task 0x12da5bb2 __kmalloc 0x5e22aa50 sock_init_data 0xb279da12 pv_lock_ops 0xd42b7232 _write_unlock_bh 0x3f4d635c sock_no_setsockopt 0xc8b57c27 autoremove_wake_function 0xa1801a2e sock_no_getsockopt 0xbe447f76 sock_no_ioctl 0x973873ab _spin_lock 0x8949858b schedule_work 0x5acb8506 sock_queue_rcv_skb 0x6729d3df __get_user_4 0x47a346b3 skb_recv_datagram 0xed06ac02 sock_no_sendpage 0xbd31d52f sock_no_mmap 0x4ba758f9 misc_register 0x7afd8702 sock_no_socketpair 0x2254d547 sk_alloc 0xa2a1e5c9 _write_lock_bh 0xb72397d5 printk 0xc642a151 lock_sock_nested 0x2da418b5 copy_to_user 0xa8eb44f9 sock_no_listen 0xd2123419 sock_no_accept 0x293beace sk_free 0x748caf40 down 0xa368017a init_net 0x7dceceac capable 0x934b1816 proto_register 0xb2fd5ceb __put_user_4 0x85c9c6af __alloc_skb 0x82673561 schedule_delayed_work 0x3c9b4b67 sock_register 0xd62c833f schedule_timeout 0x7f8da821 kfree_skb 0x0fc26794 proto_unregister 0x88dff1b9 skb_copy_datagram_iovec 0x2253d3c5 sk_receive_skb 0x6111e1bc init_timer 0x57a6504e vsnprintf 0x3aa1dbcf _spin_unlock_bh 0x037a0cba kfree 0x0e762d6e request_module 0x33d92f9a prepare_to_wait 0x62737e1d sock_unregister 0x9fb3dd30 memcpy_fromiovec 0x3f1899f1 up 0x9ccb2622 finish_wait 0x08a56041 skb_dequeue 0x701d0ebd snprintf 0x93cbd1ec _spin_lock_bh 0xc5456b60 skb_put 0xf2a644fb copy_from_user 0xc5b0fa1a misc_deregister 0xb052f6a9 skb_free_datagram 0x0da10ec3 security_sock_graft and you are right :) with --force-modversion the module loads find. Hope the info helps. ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-04 01:08 Message: It sounds like you have a newer kernel built with CONFIG_MODVERSIONS and the vsock module doesn't know about the vmci module symbol versions so the kernel is refusing to load it. This should work ... I'm interested to figure out what went wrong. First let me say that you should be able to force the kernel to load the module by using --force-modversion (although then you bypass CONFIG_MODVERSIONS which we would like to avoid). Is there a Module.symvers file in the vsock module build directory? If so, what are the contents? What is the contents of the __versions section of the module? modprobe --dump-modversions ./vsock.ko should give the info. It would also be interesting to see the output of nm ./vmci.ko | grep __crc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-03-04 07:40:09
|
Tracker item #2658928, was opened at 2009-03-03 23:24 Message generated for change (Comment added) made by eisiware You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sisternicky (eisiware) Assigned to: Nobody/Anonymous (nobody) Summary: vsock module not loadable into the kernel (2.6.28.7) Initial Comment: Hi, on my new kernel, the module vsock will not load. On modprobing, it returns the following error message: root [ ~ ]# modprobe -v vsock insmod /lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko FATAL: Error inserting vsock (/lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko): Unknown symbol in module, or unknown parameter (see dmesg) and here follows the kernel log: Mar 3 23:18:40 landfrauen kernel: [ 1912.571989] vsock: no symbol version for VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572151] vsock: Unknown symbol VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572285] vsock: no symbol version for VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572382] vsock: Unknown symbol VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572514] vsock: no symbol version for VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572595] vsock: Unknown symbol VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572864] vsock: no symbol version for VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572946] vsock: Unknown symbol VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572953] vsock: no symbol version for VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.572959] vsock: Unknown symbol VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.573510] vsock: no symbol version for VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573594] vsock: Unknown symbol VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573977] vsock: no symbol version for VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574062] vsock: Unknown symbol VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574395] vsock: no symbol version for VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574471] vsock: Unknown symbol VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574636] vsock: no symbol version for VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574713] vsock: Unknown symbol VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574947] vsock: no symbol version for VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575027] vsock: Unknown symbol VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575162] vsock: no symbol version for VMCIDatagram_CreateHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575240] vsock: Unknown symbol VMCIDatagram_CreateHnd all other modules load fine. Is there any fix known already? ---------------------------------------------------------------------- >Comment By: Sisternicky (eisiware) Date: 2009-03-04 08:40 Message: Hi again, thanks for the quick answer. There is an (empty) Module.symvers file in the module build directory modprobe --dump-modversions ./vsock.ko: 0x4f8d5728 struct_module 0x7faa1013 release_sock 0x33c3a362 per_cpu__current_task 0x12da5bb2 __kmalloc 0x5e22aa50 sock_init_data 0xb279da12 pv_lock_ops 0xd42b7232 _write_unlock_bh 0x3f4d635c sock_no_setsockopt 0xc8b57c27 autoremove_wake_function 0xa1801a2e sock_no_getsockopt 0xbe447f76 sock_no_ioctl 0x973873ab _spin_lock 0x8949858b schedule_work 0x5acb8506 sock_queue_rcv_skb 0x6729d3df __get_user_4 0x47a346b3 skb_recv_datagram 0xed06ac02 sock_no_sendpage 0xbd31d52f sock_no_mmap 0x4ba758f9 misc_register 0x7afd8702 sock_no_socketpair 0x2254d547 sk_alloc 0xa2a1e5c9 _write_lock_bh 0xb72397d5 printk 0xc642a151 lock_sock_nested 0x2da418b5 copy_to_user 0xa8eb44f9 sock_no_listen 0xd2123419 sock_no_accept 0x293beace sk_free 0x748caf40 down 0xa368017a init_net 0x7dceceac capable 0x934b1816 proto_register 0xb2fd5ceb __put_user_4 0x85c9c6af __alloc_skb 0x82673561 schedule_delayed_work 0x3c9b4b67 sock_register 0xd62c833f schedule_timeout 0x7f8da821 kfree_skb 0x0fc26794 proto_unregister 0x88dff1b9 skb_copy_datagram_iovec 0x2253d3c5 sk_receive_skb 0x6111e1bc init_timer 0x57a6504e vsnprintf 0x3aa1dbcf _spin_unlock_bh 0x037a0cba kfree 0x0e762d6e request_module 0x33d92f9a prepare_to_wait 0x62737e1d sock_unregister 0x9fb3dd30 memcpy_fromiovec 0x3f1899f1 up 0x9ccb2622 finish_wait 0x08a56041 skb_dequeue 0x701d0ebd snprintf 0x93cbd1ec _spin_lock_bh 0xc5456b60 skb_put 0xf2a644fb copy_from_user 0xc5b0fa1a misc_deregister 0xb052f6a9 skb_free_datagram 0x0da10ec3 security_sock_graft and you are right :) with --force-modversion the module loads find. Hope the info helps. ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-04 01:08 Message: It sounds like you have a newer kernel built with CONFIG_MODVERSIONS and the vsock module doesn't know about the vmci module symbol versions so the kernel is refusing to load it. This should work ... I'm interested to figure out what went wrong. First let me say that you should be able to force the kernel to load the module by using --force-modversion (although then you bypass CONFIG_MODVERSIONS which we would like to avoid). Is there a Module.symvers file in the vsock module build directory? If so, what are the contents? What is the contents of the __versions section of the module? modprobe --dump-modversions ./vsock.ko should give the info. It would also be interesting to see the output of nm ./vmci.ko | grep __crc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-03-04 00:08:06
|
Tracker item #2658928, was opened at 2009-03-03 17:24 Message generated for change (Comment added) made by microchip21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sisternicky (eisiware) Assigned to: Nobody/Anonymous (nobody) Summary: vsock module not loadable into the kernel (2.6.28.7) Initial Comment: Hi, on my new kernel, the module vsock will not load. On modprobing, it returns the following error message: root [ ~ ]# modprobe -v vsock insmod /lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko FATAL: Error inserting vsock (/lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko): Unknown symbol in module, or unknown parameter (see dmesg) and here follows the kernel log: Mar 3 23:18:40 landfrauen kernel: [ 1912.571989] vsock: no symbol version for VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572151] vsock: Unknown symbol VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572285] vsock: no symbol version for VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572382] vsock: Unknown symbol VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572514] vsock: no symbol version for VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572595] vsock: Unknown symbol VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572864] vsock: no symbol version for VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572946] vsock: Unknown symbol VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572953] vsock: no symbol version for VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.572959] vsock: Unknown symbol VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.573510] vsock: no symbol version for VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573594] vsock: Unknown symbol VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573977] vsock: no symbol version for VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574062] vsock: Unknown symbol VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574395] vsock: no symbol version for VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574471] vsock: Unknown symbol VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574636] vsock: no symbol version for VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574713] vsock: Unknown symbol VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574947] vsock: no symbol version for VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575027] vsock: Unknown symbol VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575162] vsock: no symbol version for VMCIDatagram_CreateHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575240] vsock: Unknown symbol VMCIDatagram_CreateHnd all other modules load fine. Is there any fix known already? ---------------------------------------------------------------------- Comment By: Aaron Rolett (microchip21) Date: 2009-03-03 19:08 Message: It sounds like you have a newer kernel built with CONFIG_MODVERSIONS and the vsock module doesn't know about the vmci module symbol versions so the kernel is refusing to load it. This should work ... I'm interested to figure out what went wrong. First let me say that you should be able to force the kernel to load the module by using --force-modversion (although then you bypass CONFIG_MODVERSIONS which we would like to avoid). Is there a Module.symvers file in the vsock module build directory? If so, what are the contents? What is the contents of the __versions section of the module? modprobe --dump-modversions ./vsock.ko should give the info. It would also be interesting to see the output of nm ./vmci.ko | grep __crc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-03-03 22:24:22
|
Tracker item #2658928, was opened at 2009-03-03 23:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sisternicky (eisiware) Assigned to: Nobody/Anonymous (nobody) Summary: vsock module not loadable into the kernel (2.6.28.7) Initial Comment: Hi, on my new kernel, the module vsock will not load. On modprobing, it returns the following error message: root [ ~ ]# modprobe -v vsock insmod /lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko FATAL: Error inserting vsock (/lib/modules/2.6.28.7/kernel/net/vsock/vsock.ko): Unknown symbol in module, or unknown parameter (see dmesg) and here follows the kernel log: Mar 3 23:18:40 landfrauen kernel: [ 1912.571989] vsock: no symbol version for VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572151] vsock: Unknown symbol VMCIMemcpyToQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.572285] vsock: no symbol version for VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572382] vsock: Unknown symbol VMCIEvent_Unsubscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.572514] vsock: no symbol version for VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572595] vsock: Unknown symbol VMCIQueuePair_Alloc Mar 3 23:18:40 landfrauen kernel: [ 1912.572864] vsock: no symbol version for VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572946] vsock: Unknown symbol VMCIDatagram_Send Mar 3 23:18:40 landfrauen kernel: [ 1912.572953] vsock: no symbol version for VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.572959] vsock: Unknown symbol VMCI_GetContextID Mar 3 23:18:40 landfrauen kernel: [ 1912.573510] vsock: no symbol version for VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573594] vsock: Unknown symbol VMCIQueuePair_Detach Mar 3 23:18:40 landfrauen kernel: [ 1912.573977] vsock: no symbol version for VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574062] vsock: Unknown symbol VMCIMemcpyFromQueueV Mar 3 23:18:40 landfrauen kernel: [ 1912.574395] vsock: no symbol version for VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574471] vsock: Unknown symbol VMCI_DeviceGet Mar 3 23:18:40 landfrauen kernel: [ 1912.574636] vsock: no symbol version for VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574713] vsock: Unknown symbol VMCIEvent_Subscribe Mar 3 23:18:40 landfrauen kernel: [ 1912.574947] vsock: no symbol version for VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575027] vsock: Unknown symbol VMCIDatagram_DestroyHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575162] vsock: no symbol version for VMCIDatagram_CreateHnd Mar 3 23:18:40 landfrauen kernel: [ 1912.575240] vsock: Unknown symbol VMCIDatagram_CreateHnd all other modules load fine. Is there any fix known already? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2658928&group_id=204462 |
|
From: Dmitry T. <dt...@vm...> - 2009-02-26 23:44:48
|
On Thursday 26 February 2009 15:39:13 Eric Shubert wrote: > Dmitry Torokhov wrote: > > Hi Eric, > > > > Thank you very much for your report. > > > > On Thursday 26 February 2009 08:17:47 Eric Shubert wrote: > >> I've attempted to compile subject, ran into a few snags, and have a few > >> solutions. > >> > >> vmxnet.c build failed with: > >> make[3]: Entering directory > >> `/usr/src/open-vm-tools-2009.02.18-148847/modules/linux/vmxnet' > >> In file included from /lib/modules/2.4.36/build/include/asm/dma.h:14, > >> from vmxnet.c:34: > >> /lib/modules/2.4.36/build/include/linux/delay.h:62: error: parse error > >> before "const" > >> make[3]: *** [vmxnet.o] Error 1 > >> > >> I couldn't see what the problem with linux/delay.h exactly was, but it > >> doesn't appear to be necessary. I tried removing > >> #include <asm/dma.h> > >> from vmxnet.c, and the only complaint from the compiler was the lack of > >> the udelay function, which is defined in <asm/delay.h>. It appears that > >> asm/dma.h was including linux/delay.h, which in turn included > >> asm/delay.h, which contained the udelay definition. I replaced > >> <asm/dma.h> with <asm/delay.h>, and vmxnet.c compiled clean. Of course > >> whether it actually works or not is another question. > > > > This should indeed work. > > > >> The next error was with vmhgfs. Makefile.normal had specified > >> hgfsEscapeLinux.o, while the program was really hgfsEscape.o (the > >> "Linux" part had apparently been dropped along the line). I modified > >> Makefile.normal, specifying hgfsEscape.o, and it compiled clean. Can > >> someone verify if this is correct? > > > > Yes, that is correct. There should already be hgfsEscape.o in the list of > > dependencies so you can just remove hgfsEscapeLinux.o > > > >> With vmsock, I get this: > >> make[4]: Entering directory > >> `/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2. > >>4.3 6' Compiling .././linux/af_vsock.c > >> ../linux/af_vsock.c: In function `VSockVmciStreamConnect': > >> ../linux/af_vsock.c:3466: warning: implicit declaration of function > >> `DEFINE_WAIT' > >> ../linux/af_vsock.c:3466: error: `wait' undeclared (first use in this > >> function) > >> ../linux/af_vsock.c:3466: error: (Each undeclared identifier is reported > >> only once > >> ../linux/af_vsock.c:3466: error: for each function it appears in.) > >> ../linux/af_vsock.c:3542: warning: implicit declaration of function > >> `prepare_to_wait' > >> ../linux/af_vsock.c:3577: warning: implicit declaration of function > >> `finish_wait' > >> ../linux/af_vsock.c: In function `VSockVmciAccept': > >> ../linux/af_vsock.c:3615: error: `wait' undeclared (first use in this > >> function) > >> ../linux/af_vsock.c: In function `VSockVmciStreamSendmsg': > >> ../linux/af_vsock.c:4360: error: `wait' undeclared (first use in this > >> function) > >> ../linux/af_vsock.c: In function `VSockVmciStreamRecvmsg': > >> ../linux/af_vsock.c:4714: error: `wait' undeclared (first use in this > >> function) > >> make[4]: *** [af_vsock.o] Error 1 > >> make[4]: Leaving directory > >> `/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2. > >>4.3 6' > >> > >> Can someone explain what might be the problem here? I don't expect > >> vmsock to be useful in the IPCop distro, but I'm wondering what the > >> problem is, as it should build with this kernel. > > > > Could you please try the patch below? You will need to apply it to all > > copies of compat_wait.h in the tree. Thanks! > > I've applied the patch to all copies of compat_wait.h: > open-vm-tools-2009.02.18-148847/modules/linux/vmmemctl/compat_wait.h > open-vm-tools-2009.02.18-148847/modules/linux/vmhgfs/compat_wait.h > open-vm-tools-2009.02.18-148847/modules/linux/vsock/include/compat_wait.h > open-vm-tools-2009.02.18-148847/modules/linux/vmblock/include/compat_wait.h > open-vm-tools-2009.02.18-148847/modules/linux/vmci/compat_wait.h > and everything compiled ok. Cool, thank you for doing that. > > It should be noted that, as IPCop doesn't have a GUI (it typically runs > headless), I used the following configuration: > ./configure --disable-static \ > --disable-multimon \ > --without-gtk2 \ > --without-gtkmm \ > --without-icu \ > --without-x \ > --with-kernel-release=2.4.36 > TTBOMK the only module using compat_wait.h with this configuration is > vsock. > > Do you have any idea which release will contain all of these changes > (vmxnet.c, vmhgfs/Makefile.normal, compat_wait.h)? > The next month refresh should pick it all up. -- Dmitry |
|
From: Eric S. <ej...@sh...> - 2009-02-26 23:39:30
|
Dmitry Torokhov wrote: > Hi Eric, > > Thank you very much for your report. > > On Thursday 26 February 2009 08:17:47 Eric Shubert wrote: >> I've attempted to compile subject, ran into a few snags, and have a few >> solutions. >> >> vmxnet.c build failed with: >> make[3]: Entering directory >> `/usr/src/open-vm-tools-2009.02.18-148847/modules/linux/vmxnet' >> In file included from /lib/modules/2.4.36/build/include/asm/dma.h:14, >> from vmxnet.c:34: >> /lib/modules/2.4.36/build/include/linux/delay.h:62: error: parse error >> before "const" >> make[3]: *** [vmxnet.o] Error 1 >> >> I couldn't see what the problem with linux/delay.h exactly was, but it >> doesn't appear to be necessary. I tried removing >> #include <asm/dma.h> >> from vmxnet.c, and the only complaint from the compiler was the lack of >> the udelay function, which is defined in <asm/delay.h>. It appears that >> asm/dma.h was including linux/delay.h, which in turn included >> asm/delay.h, which contained the udelay definition. I replaced >> <asm/dma.h> with <asm/delay.h>, and vmxnet.c compiled clean. Of course >> whether it actually works or not is another question. >> > > This should indeed work. > >> The next error was with vmhgfs. Makefile.normal had specified >> hgfsEscapeLinux.o, while the program was really hgfsEscape.o (the >> "Linux" part had apparently been dropped along the line). I modified >> Makefile.normal, specifying hgfsEscape.o, and it compiled clean. Can >> someone verify if this is correct? >> > > Yes, that is correct. There should already be hgfsEscape.o in the list of > dependencies so you can just remove hgfsEscapeLinux.o > >> With vmsock, I get this: >> make[4]: Entering directory >> `/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2.4.3 >> 6' Compiling .././linux/af_vsock.c >> ../linux/af_vsock.c: In function `VSockVmciStreamConnect': >> ../linux/af_vsock.c:3466: warning: implicit declaration of function >> `DEFINE_WAIT' >> ../linux/af_vsock.c:3466: error: `wait' undeclared (first use in this >> function) >> ../linux/af_vsock.c:3466: error: (Each undeclared identifier is reported >> only once >> ../linux/af_vsock.c:3466: error: for each function it appears in.) >> ../linux/af_vsock.c:3542: warning: implicit declaration of function >> `prepare_to_wait' >> ../linux/af_vsock.c:3577: warning: implicit declaration of function >> `finish_wait' >> ../linux/af_vsock.c: In function `VSockVmciAccept': >> ../linux/af_vsock.c:3615: error: `wait' undeclared (first use in this >> function) >> ../linux/af_vsock.c: In function `VSockVmciStreamSendmsg': >> ../linux/af_vsock.c:4360: error: `wait' undeclared (first use in this >> function) >> ../linux/af_vsock.c: In function `VSockVmciStreamRecvmsg': >> ../linux/af_vsock.c:4714: error: `wait' undeclared (first use in this >> function) >> make[4]: *** [af_vsock.o] Error 1 >> make[4]: Leaving directory >> `/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2.4.3 >> 6' >> >> Can someone explain what might be the problem here? I don't expect >> vmsock to be useful in the IPCop distro, but I'm wondering what the >> problem is, as it should build with this kernel. > > Could you please try the patch below? You will need to apply it to all copies > of compat_wait.h in the tree. Thanks! > I've applied the patch to all copies of compat_wait.h: open-vm-tools-2009.02.18-148847/modules/linux/vmmemctl/compat_wait.h open-vm-tools-2009.02.18-148847/modules/linux/vmhgfs/compat_wait.h open-vm-tools-2009.02.18-148847/modules/linux/vsock/include/compat_wait.h open-vm-tools-2009.02.18-148847/modules/linux/vmblock/include/compat_wait.h open-vm-tools-2009.02.18-148847/modules/linux/vmci/compat_wait.h and everything compiled ok. It should be noted that, as IPCop doesn't have a GUI (it typically runs headless), I used the following configuration: ./configure --disable-static \ --disable-multimon \ --without-gtk2 \ --without-gtkmm \ --without-icu \ --without-x \ --with-kernel-release=2.4.36 TTBOMK the only module using compat_wait.h with this configuration is vsock. Do you have any idea which release will contain all of these changes (vmxnet.c, vmhgfs/Makefile.normal, compat_wait.h)? Thanks again! -- -Eric 'shubes' |
|
From: Eric S. <ej...@sh...> - 2009-02-26 23:09:39
|
Dmitry Torokhov wrote: > Hi Eric, > > Thank you very much for your report. > > On Thursday 26 February 2009 08:17:47 Eric Shubert wrote: >> I've attempted to compile subject, ran into a few snags, and have a few >> solutions. >> >> vmxnet.c build failed with: >> make[3]: Entering directory >> `/usr/src/open-vm-tools-2009.02.18-148847/modules/linux/vmxnet' >> In file included from /lib/modules/2.4.36/build/include/asm/dma.h:14, >> from vmxnet.c:34: >> /lib/modules/2.4.36/build/include/linux/delay.h:62: error: parse error >> before "const" >> make[3]: *** [vmxnet.o] Error 1 >> >> I couldn't see what the problem with linux/delay.h exactly was, but it >> doesn't appear to be necessary. I tried removing >> #include <asm/dma.h> >> from vmxnet.c, and the only complaint from the compiler was the lack of >> the udelay function, which is defined in <asm/delay.h>. It appears that >> asm/dma.h was including linux/delay.h, which in turn included >> asm/delay.h, which contained the udelay definition. I replaced >> <asm/dma.h> with <asm/delay.h>, and vmxnet.c compiled clean. Of course >> whether it actually works or not is another question. >> > > This should indeed work. > >> The next error was with vmhgfs. Makefile.normal had specified >> hgfsEscapeLinux.o, while the program was really hgfsEscape.o (the >> "Linux" part had apparently been dropped along the line). I modified >> Makefile.normal, specifying hgfsEscape.o, and it compiled clean. Can >> someone verify if this is correct? >> > > Yes, that is correct. There should already be hgfsEscape.o in the list of > dependencies so you can just remove hgfsEscapeLinux.o > >> With vmsock, I get this: >> make[4]: Entering directory >> `/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2.4.3 >> 6' Compiling .././linux/af_vsock.c >> ../linux/af_vsock.c: In function `VSockVmciStreamConnect': >> ../linux/af_vsock.c:3466: warning: implicit declaration of function >> `DEFINE_WAIT' >> ../linux/af_vsock.c:3466: error: `wait' undeclared (first use in this >> function) >> ../linux/af_vsock.c:3466: error: (Each undeclared identifier is reported >> only once >> ../linux/af_vsock.c:3466: error: for each function it appears in.) >> ../linux/af_vsock.c:3542: warning: implicit declaration of function >> `prepare_to_wait' >> ../linux/af_vsock.c:3577: warning: implicit declaration of function >> `finish_wait' >> ../linux/af_vsock.c: In function `VSockVmciAccept': >> ../linux/af_vsock.c:3615: error: `wait' undeclared (first use in this >> function) >> ../linux/af_vsock.c: In function `VSockVmciStreamSendmsg': >> ../linux/af_vsock.c:4360: error: `wait' undeclared (first use in this >> function) >> ../linux/af_vsock.c: In function `VSockVmciStreamRecvmsg': >> ../linux/af_vsock.c:4714: error: `wait' undeclared (first use in this >> function) >> make[4]: *** [af_vsock.o] Error 1 >> make[4]: Leaving directory >> `/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2.4.3 >> 6' >> >> Can someone explain what might be the problem here? I don't expect >> vmsock to be useful in the IPCop distro, but I'm wondering what the >> problem is, as it should build with this kernel. > > Could you please try the patch below? You will need to apply it to all copies > of compat_wait.h in the tree. Thanks! > Dmitry, I figured this out as well (great minds think alike!). As a test I changed the KERNEL_VERSION(2, 4, 28) to 2.4.38 just to make it include the code. It compiled fine. I like your fix much better though (was thinking along the same lines). I'll try the patch and get back to you. Thanks! -- -Eric 'shubes' |
|
From: SourceForge.net <no...@so...> - 2009-02-26 22:33:42
|
Tracker item #2559990, was opened at 2009-02-03 00:26 Message generated for change (Comment added) made by dtor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2559990&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mna-news (mna-news) Assigned to: Nobody/Anonymous (nobody) Summary: modules/linux/pvscsi does not compile with old GCC Initial Comment: am trying to compile open-vm-tools-2009.01.21-142982 with kernel 2.6.28.1 using gcc version 3.4.5 and there is a problem with inline fonction (like vsocks module cf tracker 2531283) Using 2.6.x kernel build system. make[2]: Entering directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/pvscsi' make -C /lib/modules/2.6.28.1/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules make[3]: Entering directory `/usr/src/linux-2.6.28.1' CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/pvscsi/pvscsi.o /tmp/open-vm-tools-2009.01.21-142982/modules/linux/pvscsi/pvscsi.c: In function `pvscsi_probe': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/pvscsi/pvscsi.c:231: sorry, unimplemented: inlining failed in call to 'pvscsi_write_intr_mask': function body not available /tmp/open-vm-tools-2009.01.21-142982/modules/linux/pvscsi/pvscsi.c:564: sorry, unimplemented: called from here make[4]: *** [/tmp/open-vm-tools-2009.01.21-142982/modules/linux/pvscsi/pvscsi.o] Error 1 make[3]: *** [_module_/tmp/open-vm-tools-2009.01.21-142982/modules/linux/pvscsi] Error 2 make[3]: Leaving directory `/usr/src/linux-2.6.28.1' make[2]: *** [pvscsi.ko] Error 2 make[2]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/pvscsi' make[1]: *** [pvscsi] Error 2 make[1]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules' make: *** [all-recursive] Error 1 thanks for your help. mna. ---------------------------------------------------------------------- >Comment By: Dmitry Torokhov (dtor) Date: 2009-02-26 14:33 Message: Sorry it took so long but coupld you please try the patch I just uploaded? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2559990&group_id=204462 |
|
From: Dmitry T. <dt...@vm...> - 2009-02-26 22:22:26
|
Hi Eric,
Thank you very much for your report.
On Thursday 26 February 2009 08:17:47 Eric Shubert wrote:
> I've attempted to compile subject, ran into a few snags, and have a few
> solutions.
>
> vmxnet.c build failed with:
> make[3]: Entering directory
> `/usr/src/open-vm-tools-2009.02.18-148847/modules/linux/vmxnet'
> In file included from /lib/modules/2.4.36/build/include/asm/dma.h:14,
> from vmxnet.c:34:
> /lib/modules/2.4.36/build/include/linux/delay.h:62: error: parse error
> before "const"
> make[3]: *** [vmxnet.o] Error 1
>
> I couldn't see what the problem with linux/delay.h exactly was, but it
> doesn't appear to be necessary. I tried removing
> #include <asm/dma.h>
> from vmxnet.c, and the only complaint from the compiler was the lack of
> the udelay function, which is defined in <asm/delay.h>. It appears that
> asm/dma.h was including linux/delay.h, which in turn included
> asm/delay.h, which contained the udelay definition. I replaced
> <asm/dma.h> with <asm/delay.h>, and vmxnet.c compiled clean. Of course
> whether it actually works or not is another question.
>
This should indeed work.
> The next error was with vmhgfs. Makefile.normal had specified
> hgfsEscapeLinux.o, while the program was really hgfsEscape.o (the
> "Linux" part had apparently been dropped along the line). I modified
> Makefile.normal, specifying hgfsEscape.o, and it compiled clean. Can
> someone verify if this is correct?
>
Yes, that is correct. There should already be hgfsEscape.o in the list of
dependencies so you can just remove hgfsEscapeLinux.o
> With vmsock, I get this:
> make[4]: Entering directory
> `/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2.4.3
>6' Compiling .././linux/af_vsock.c
> ../linux/af_vsock.c: In function `VSockVmciStreamConnect':
> ../linux/af_vsock.c:3466: warning: implicit declaration of function
> `DEFINE_WAIT'
> ../linux/af_vsock.c:3466: error: `wait' undeclared (first use in this
> function)
> ../linux/af_vsock.c:3466: error: (Each undeclared identifier is reported
> only once
> ../linux/af_vsock.c:3466: error: for each function it appears in.)
> ../linux/af_vsock.c:3542: warning: implicit declaration of function
> `prepare_to_wait'
> ../linux/af_vsock.c:3577: warning: implicit declaration of function
> `finish_wait'
> ../linux/af_vsock.c: In function `VSockVmciAccept':
> ../linux/af_vsock.c:3615: error: `wait' undeclared (first use in this
> function)
> ../linux/af_vsock.c: In function `VSockVmciStreamSendmsg':
> ../linux/af_vsock.c:4360: error: `wait' undeclared (first use in this
> function)
> ../linux/af_vsock.c: In function `VSockVmciStreamRecvmsg':
> ../linux/af_vsock.c:4714: error: `wait' undeclared (first use in this
> function)
> make[4]: *** [af_vsock.o] Error 1
> make[4]: Leaving directory
> `/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2.4.3
>6'
>
> Can someone explain what might be the problem here? I don't expect
> vmsock to be useful in the IPCop distro, but I'm wondering what the
> problem is, as it should build with this kernel.
Could you please try the patch below? You will need to apply it to all copies
of compat_wait.h in the tree. Thanks!
--
Dmitry
--- compat_wait.h.orig
+++ compat_wait.h
@@ -179,10 +179,16 @@ do { \
/*
* DEFINE_WAIT() and friends were added in 2.5.39 and backported to 2.4.28.
+ *
+ * Unfortunately it is not true. While some distros may have done it the
+ * change has never made it into vanilla 2.4 kernel. Instead of testing
+ * particular kernel versions let's just test for presence of DEFINE_WAIT
+ * when figuring out whether we need to provide replacement implementation
+ * or simply alias existing one.
*/
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 28) || \
- (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 5, 0) && \
- LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 39))
+
+#ifndef DEFINE_WAIT
+
# define COMPAT_DEFINE_WAIT(_wait) \
DECLARE_WAITQUEUE(_wait, current)
# define compat_init_prepare_to_wait(_sleep, _wait, _state) \
@@ -197,7 +203,9 @@ do { \
__set_current_state(_state); \
remove_wait_queue(_sleep, _wait); \
} while (0)
+
#else
+
# define COMPAT_DEFINE_WAIT(_wait) \
DEFINE_WAIT(_wait)
# define compat_init_prepare_to_wait(_sleep, _wait, _state) \
@@ -206,6 +214,7 @@ do { \
prepare_to_wait(_sleep, _wait, _state)
# define compat_finish_wait(_sleep, _wait, _state) \
finish_wait(_sleep, _wait)
-#endif
+
+#endif /* #ifndef DEFINE_WAIT */
#endif /* __COMPAT_WAIT_H__ */
|
|
From: Eric S. <ej...@sh...> - 2009-02-26 16:20:15
|
I've attempted to compile subject, ran into a few snags, and have a few
solutions.
vmxnet.c build failed with:
make[3]: Entering directory
`/usr/src/open-vm-tools-2009.02.18-148847/modules/linux/vmxnet'
In file included from /lib/modules/2.4.36/build/include/asm/dma.h:14,
from vmxnet.c:34:
/lib/modules/2.4.36/build/include/linux/delay.h:62: error: parse error
before "const"
make[3]: *** [vmxnet.o] Error 1
I couldn't see what the problem with linux/delay.h exactly was, but it
doesn't appear to be necessary. I tried removing
#include <asm/dma.h>
from vmxnet.c, and the only complaint from the compiler was the lack of
the udelay function, which is defined in <asm/delay.h>. It appears that
asm/dma.h was including linux/delay.h, which in turn included
asm/delay.h, which contained the udelay definition. I replaced
<asm/dma.h> with <asm/delay.h>, and vmxnet.c compiled clean. Of course
whether it actually works or not is another question.
The next error was with vmhgfs. Makefile.normal had specified
hgfsEscapeLinux.o, while the program was really hgfsEscape.o (the
"Linux" part had apparently been dropped along the line). I modified
Makefile.normal, specifying hgfsEscape.o, and it compiled clean. Can
someone verify if this is correct?
With vmsock, I get this:
make[4]: Entering directory
`/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2.4.36'
Compiling .././linux/af_vsock.c
../linux/af_vsock.c: In function `VSockVmciStreamConnect':
../linux/af_vsock.c:3466: warning: implicit declaration of function
`DEFINE_WAIT'
../linux/af_vsock.c:3466: error: `wait' undeclared (first use in this
function)
../linux/af_vsock.c:3466: error: (Each undeclared identifier is reported
only once
../linux/af_vsock.c:3466: error: for each function it appears in.)
../linux/af_vsock.c:3542: warning: implicit declaration of function
`prepare_to_wait'
../linux/af_vsock.c:3577: warning: implicit declaration of function
`finish_wait'
../linux/af_vsock.c: In function `VSockVmciAccept':
../linux/af_vsock.c:3615: error: `wait' undeclared (first use in this
function)
../linux/af_vsock.c: In function `VSockVmciStreamSendmsg':
../linux/af_vsock.c:4360: error: `wait' undeclared (first use in this
function)
../linux/af_vsock.c: In function `VSockVmciStreamRecvmsg':
../linux/af_vsock.c:4714: error: `wait' undeclared (first use in this
function)
make[4]: *** [af_vsock.o] Error 1
make[4]: Leaving directory
`/usr/src/open-vm-tools-2009.02.18-148847p/modules/linux/vsock/driver-2.4.36'
Can someone explain what might be the problem here? I don't expect
vmsock to be useful in the IPCop distro, but I'm wondering what the
problem is, as it should build with this kernel.
--
-Eric 'shubes'
|
|
From: Hooghkirk H. <lut...@ve...> - 2009-02-24 15:10:17
|
Enjoy the feeling every day and the doing from timee to time, without stress for body and mind, and a look at how well you achieve may be the easiest way to check your health status. Marina gregg always have a physician in attendance?' the cointe could not think who the lady was she causes of a renewal of the quarrel. Did you not conform to all companies and to all conversations. Seemed suddenly to bethink themselves of their. |
|
From: Dmitry T. <dt...@vm...> - 2009-02-23 20:20:15
|
On Thursday 19 February 2009 01:35:43 Dominique Leuenberger wrote:
> >>> On 2/19/2009 at 10:06 AM, "Dominique Leuenberger"
>
> <Dom...@TM...> wrote:
> > Hi,
> >
> > Just downloaded the latest tarball and trying to build the new rpms for
> > openSUSE. So far no luck. the vmxnet module seems not to be building
> > anymore:
> >
> > Build error:
> > + make -C /usr/src/linux-obj/i586/debug modules
> > M=/usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet VM_CCVER=4.3
> > HEADER_DIR=/usr/src/linux-obj/i386/default/include
> > SRCROOT=/usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet
> > make: Entering directory `/usr/src/linux-2.6.29-rc5-1-obj/i386/debug'
> > make -C ../../../linux-2.6.29-rc5-1
> > O=/usr/src/linux-2.6.29-rc5-1-obj/i386/debug/. modules
> > Using 2.6.x kernel build system.
> > CC [M] /usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet/vmxnet.o
>
> Skipping vmxnet and testing what else happens, I also run into issues
> compiling vmxnet3:
>
> make: Entering directory `/usr/src/linux-2.6.29-rc5-1-obj/i386/debug'
> make -C ../../../linux-2.6.29-rc5-1
> O=/usr/src/linux-2.6.29-rc5-1-obj/i386/debug/. modules Using 2.6.x kernel
> build system.
> CC [M] /usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3/vmxnet3.o
> /usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3/vmxnet3.c: In
> function 'vmxnet3_poll':
> /usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3/vmxnet3.c:389:
> warning: passing argument 1 of 'netif_rx_complete' from incompatible
> pointer type
> /usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3/vmxnet3.c:389:
> error: too many arguments to function 'netif_rx_complete'
> /usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3/vmxnet3.c: In
> function 'vmxnet3_intr':
> /usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3/vmxnet3.c:455:
> error: 'struct net_device' has no member named 'priv'
> /usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3/vmxnet3.c:471:
> warning: passing argument 1 of 'netif_rx_schedule' from incompatible
> pointer type
> /usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3/vmxnet3.c:471:
> error: too many arguments to function 'netif_rx_schedule' make[3]: ***
> [/usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3/vmxnet3.o] Error 1
> make[2]: ***
> [_module_/usr/src/packages/BUILD/obj/debug/modules/linux/vmxnet3] Error 2
> make[1]: *** [sub-make] Error 2
> make: *** [all] Error 2
> make: Leaving directory `/usr/src/linux-2.6.29-rc5-1-obj/i386/debug'
> error: Bad exit status from /var/tmp/rpm-tmp.49505 (%build)
>
Dominique,
The following patch should help with vmxnet3 compilation. I rediffed it
against the 2009.02.18 release so it should apply better than the vmxnet
patch.
--
Dmitry
diff -urN a/modules/linux/vmxnet3/autoconf/netif_num_params.c b/modules/linux/vmxnet3/autoconf/netif_num_params.c
--- a/modules/linux/vmxnet3/autoconf/netif_num_params.c 1969-12-31 16:00:00.000000000 -0800
+++ b/modules/linux/vmxnet3/autoconf/netif_num_params.c 2009-02-23 11:24:00.000000000 -0800
@@ -0,0 +1,37 @@
+/*********************************************************
+ * Copyright (C) 2009 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ *********************************************************/
+
+/*
+ * Detect whether netif_rx_complete (and netif_rx_schedule) take a single
+ * napi_struct argument. The foundation was laid whith introducing Generic
+ * Receive Offload infrastructure but sropping unneeded net_device argument
+ * did not happen till few commits later so we can't simply test for presence
+ * of NETIF_F_GRO.
+ */
+
+#include <linux/autoconf.h>
+#include <linux/netdevice.h>
+
+#ifndef NETIF_F_GRO
+# error This compile test intentionally fails.
+#endif
+
+void test_netif_rx_complete(struct napi_struct *napi)
+{
+ netif_rx_complete(napi);
+}
diff -urN a/modules/linux/vmxnet3/compat_netdevice.h b/modules/linux/vmxnet3/compat_netdevice.h
--- a/modules/linux/vmxnet3/compat_netdevice.h 2009-02-18 00:02:40.000000000 -0800
+++ b/modules/linux/vmxnet3/compat_netdevice.h 2009-02-23 11:24:00.000000000 -0800
@@ -178,6 +178,23 @@
# define compat_netdev_priv(netdev) netdev_priv(netdev)
#endif
+/*
+ * All compat_* business is good but when we can we should just provide
+ * missing implementation to ease upstreaming task.
+ */
+#ifndef HAVE_ALLOC_NETDEV
+#define alloc_netdev(sz, name, setup) compat_alloc_netdev(sz, name, setup)
+#define alloc_etherdev(sz) compat_alloc_etherdev(sz)
+#endif
+
+#ifndef HAVE_FREE_NETDEV
+#define free_netdev(dev) kfree(dev)
+#endif
+
+#ifndef HAVE_NETDEV_PRIV
+#define netdev_priv(dev) ((dev)->priv)
+#endif
+
#if defined(NETDEV_TX_OK)
# define COMPAT_NETDEV_TX_OK NETDEV_TX_OK
# define COMPAT_NETDEV_TX_BUSY NETDEV_TX_BUSY
@@ -186,55 +203,56 @@
# define COMPAT_NETDEV_TX_BUSY 1
#endif
-#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,3,43))
+#ifndef HAVE_NETIF_QUEUE
static inline void
-compat_netif_start_queue(struct device *dev)
+netif_start_queue(struct device *dev)
{
clear_bit(0, &dev->tbusy);
}
static inline void
-compat_netif_stop_queue(struct device *dev)
+netif_stop_queue(struct device *dev)
{
set_bit(0, &dev->tbusy);
}
static inline int
-compat_netif_queue_stopped(struct device *dev)
+netif_queue_stopped(struct device *dev)
{
return test_bit(0, &dev->tbusy);
}
static inline void
-compat_netif_wake_queue(struct device *dev)
+netif_wake_queue(struct device *dev)
{
clear_bit(0, &dev->tbusy);
mark_bh(NET_BH);
}
static inline int
-compat_netif_running(struct device *dev)
+netif_running(struct device *dev)
{
return dev->start == 0;
}
static inline int
-compat_netif_carrier_ok(struct device *dev)
+netif_carrier_ok(struct device *dev)
{
return 1;
}
static inline void
-compat_netif_carrier_on(struct device *dev)
+netif_carrier_on(struct device *dev)
{
}
static inline void
-compat_netif_carrier_off(struct device *dev)
+netif_carrier_off(struct device *dev)
{
}
+#endif
-#else
+/* Keep compat_* defines for now */
#define compat_netif_start_queue(dev) netif_start_queue(dev)
#define compat_netif_stop_queue(dev) netif_stop_queue(dev)
#define compat_netif_queue_stopped(dev) netif_queue_stopped(dev)
@@ -243,7 +261,6 @@
#define compat_netif_carrier_ok(dev) netif_carrier_ok(dev)
#define compat_netif_carrier_on(dev) netif_carrier_on(dev)
#define compat_netif_carrier_off(dev) netif_carrier_off(dev)
-#endif
/* unregister_netdevice_notifier was not safe prior to 2.6.17 */
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 17) && \
@@ -266,7 +283,15 @@
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 24)
#define compat_netif_napi_add(dev, napi, poll, quota) \
netif_napi_add(dev, napi, poll, quota)
+
+#ifdef VMW_NETIF_SINGLE_NAPI_PARM
+#define compat_netif_rx_complete(dev, napi) netif_rx_complete(napi)
+#define compat_netif_rx_schedule(dev, napi) netif_rx_schedule(napi)
+#else
+#define compat_netif_rx_complete(dev, napi) netif_rx_complete(dev, napi)
#define compat_netif_rx_schedule(dev, napi) netif_rx_schedule(dev, napi)
+#endif
+
#define compat_napi_enable(dev, napi) napi_enable(napi)
#define compat_napi_disable(dev, napi) napi_disable(napi)
#else
diff -urN a/modules/linux/vmxnet3/Makefile.kernel b/modules/linux/vmxnet3/Makefile.kernel
--- a/modules/linux/vmxnet3/Makefile.kernel 2009-02-18 00:02:40.000000000 -0800
+++ b/modules/linux/vmxnet3/Makefile.kernel 2009-02-23 11:24:00.000000000 -0800
@@ -26,6 +26,7 @@
EXTRA_CFLAGS := $(CC_OPTS) $(INCLUDE)
EXTRA_CFLAGS += $(call vm_check_build, $(SRCROOT)/autoconf/skblin.c, -DVMW_SKB_LINEARIZE_2618, )
+EXTRA_CFLAGS += $(call vm_check_build, $(SRCROOT)/autoconf/netif_num_params.c, -DVMW_NETIF_SINGLE_NAPI_PARM, )
obj-m += $(DRIVER).o
diff -urN a/modules/linux/vmxnet3/Makefile.normal b/modules/linux/vmxnet3/Makefile.normal
--- a/modules/linux/vmxnet3/Makefile.normal 2009-02-18 00:02:40.000000000 -0800
+++ b/modules/linux/vmxnet3/Makefile.normal 2009-02-23 11:24:00.000000000 -0800
@@ -61,6 +61,7 @@
| sed -n -e 's!^APATH!-I$(HEADER_DIR)/asm!p')
CC_OPTS += $(call vm_check_build, $(SRCROOT)/autoconf/skblin.c, -DVMW_SKB_LINEARIZE_2618, )
+CC_OPTS += $(call vm_check_build, $(SRCROOT)/autoconf/netif_num_params.c, -DVMW_NETIF_SINGLE_NAPI_PARM, )
OBJS := vmxnet3.o
diff -urN a/modules/linux/vmxnet3/vmxnet3.c b/modules/linux/vmxnet3/vmxnet3.c
--- a/modules/linux/vmxnet3/vmxnet3.c 2009-02-18 00:02:40.000000000 -0800
+++ b/modules/linux/vmxnet3/vmxnet3.c 2009-02-23 11:24:00.000000000 -0800
@@ -155,7 +155,7 @@
#endif
};
-static int disable_lro = 0;
+static int disable_lro;
/*
*----------------------------------------------------------------------------
@@ -381,12 +381,11 @@
{
struct vmxnet3_adapter *adapter = container_of(napi, struct vmxnet3_adapter, napi);
int rxd_done, txd_done;
- struct net_device *netdev = adapter->netdev;
vmxnet3_do_poll(adapter, budget, &txd_done, &rxd_done);
if (rxd_done < budget) {
- netif_rx_complete(netdev, napi);
+ compat_netif_rx_complete(adapter->netdev, napi);
vmxnet3_enable_intr(adapter, 0);
}
return rxd_done;
@@ -410,7 +409,7 @@
vmxnet3_poll(struct net_device *poll_dev, int *budget)
{
int rxd_done, txd_done, quota;
- struct vmxnet3_adapter *adapter = poll_dev->priv;
+ struct vmxnet3_adapter *adapter = netdev_priv(poll_dev);
quota = min(*budget, poll_dev->quota);
@@ -452,7 +451,7 @@
#endif
{
struct net_device *dev = dev_id;
- struct vmxnet3_adapter *adapter = dev->priv;
+ struct vmxnet3_adapter *adapter = netdev_priv(dev);
if (UNLIKELY(adapter->intr.type == VMXNET3_IT_INTX)) {
uint32 icr = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_ICR);
@@ -468,7 +467,7 @@
vmxnet3_disable_intr(adapter, 0);
}
- compat_netif_rx_schedule(dev, &adapter->napi);
+ compat_netif_rx_schedule(dev, &adapter->napi);
#else
vmxnet3_tq_tx_complete(&adapter->tx_queue, adapter);
diff -urN a/modules/linux/vmxnet3/vmxnet3_version.h b/modules/linux/vmxnet3/vmxnet3_version.h
--- a/modules/linux/vmxnet3/vmxnet3_version.h 2009-02-18 00:02:40.000000000 -0800
+++ b/modules/linux/vmxnet3/vmxnet3_version.h 2009-02-23 11:23:59.000000000 -0800
@@ -25,11 +25,11 @@
#ifndef _VMXNET3_VERSION_H_
#define _VMXNET3_VERSION_H_
-#define VMXNET3_DRIVER_VERSION 1.0.0.32
-#define VMXNET3_DRIVER_VERSION_COMMAS 1,0,0,32
-#define VMXNET3_DRIVER_VERSION_STRING "1.0.0.32"
+#define VMXNET3_DRIVER_VERSION 1.0.0.33
+#define VMXNET3_DRIVER_VERSION_COMMAS 1,0,0,33
+#define VMXNET3_DRIVER_VERSION_STRING "1.0.0.33"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01000020
+#define VMXNET3_DRIVER_VERSION_NUM 0x01000021
#endif /* _VMXNET3_VERSION_H_ */
|
|
From: Dominique L. <Dom...@TM...> - 2009-02-23 10:31:57
|
>>> On 2/20/2009 at 16:25, Dmitry Torokhov <dt...@vm...> wrote: > Hi Dominique, > > On Thursday 19 February 2009 01:06:29 Dominique Leuenberger wrote: >> Hi, >> >> Just downloaded the latest tarball and trying to build the new rpms for >> openSUSE. So far no luck. the vmxnet module seems not to be building >> anymore: >> > > The following should help with vmxnet, I will look in vmxnet3 in a bit. Dmitry, The patch you attached directly did not do the trick (did not apply), but it gave enough pointers to recreate a working one. For reference, in case anybody else needs it, I attach 'my' version here (It's the same as yours, just the line numbers seemed not to be correct and thus it could not apply the patch). Dominique |
|
From: Dominique L. <Dom...@TM...> - 2009-02-20 16:14:51
|
>>> On 2/20/2009 at 17:09, Dmitry Torokhov <dt...@vm...> wrote: > On Friday 20 February 2009 07:28:20 Dominique Leuenberger wrote: > How old is old? I think it should compile with most of 2.6 but not 2.4... I > have the other part of the patch that has compatibility glue but I didn't > think you would care for it. I see.. nono.. old is not that old in my case. I usually build on all supported openSUSE platforms. This means at the moment oldest one is openSUSE 10.3, which contains kernel 2.6.22 already... So everything is fine for me in this case. Dominique |
|
From: Dmitry T. <dt...@vm...> - 2009-02-20 16:09:28
|
On Friday 20 February 2009 07:28:20 Dominique Leuenberger wrote: > >>> On 2/20/2009 at 16:25, Dmitry Torokhov <dt...@vm...> wrote: > > > > Hi Dominique, > > > > On Thursday 19 February 2009 01:06:29 Dominique Leuenberger wrote: > >> Hi, > >> > >> Just downloaded the latest tarball and trying to build the new rpms for > >> openSUSE. So far no luck. the vmxnet module seems not to be building > >> anymore: > > > > The following should help with vmxnet, I will look in vmxnet3 in a bit. > > Dmitry, > > Thank you very much. Can this patch also be applied when building against > older kernels (I integrate it into RPM build process) or only against > 2.6.29? > > Both is possible for me, I can easily %if it and have the patch only on > newer versions if it would break the old ones. > How old is old? I think it should compile with most of 2.6 but not 2.4... I have the other part of the patch that has compatibility glue but I didn't think you would care for it. -- Dmitry |
|
From: Dominique L. <Dom...@TM...> - 2009-02-20 15:34:26
|
>>> On 2/20/2009 at 16:25, Dmitry Torokhov <dt...@vm...> wrote: > Hi Dominique, > > On Thursday 19 February 2009 01:06:29 Dominique Leuenberger wrote: >> Hi, >> >> Just downloaded the latest tarball and trying to build the new rpms for >> openSUSE. So far no luck. the vmxnet module seems not to be building >> anymore: >> > > The following should help with vmxnet, I will look in vmxnet3 in a bit. Dmitry, Thank you very much. Can this patch also be applied when building against older kernels (I integrate it into RPM build process) or only against 2.6.29? Both is possible for me, I can easily %if it and have the patch only on newer versions if it would break the old ones. Dominique |
|
From: Dmitry T. <dt...@vm...> - 2009-02-20 15:25:33
|
Hi Dominique,
On Thursday 19 February 2009 01:06:29 Dominique Leuenberger wrote:
> Hi,
>
> Just downloaded the latest tarball and trying to build the new rpms for
> openSUSE. So far no luck. the vmxnet module seems not to be building
> anymore:
>
The following should help with vmxnet, I will look in vmxnet3 in a bit.
--
Dmitry
--- a/modules/linux/vmxnet/vmxnet.c
+++ b/modules/linux/vmxnet/vmxnet.c
@@ -184,7 +184,7 @@
static int
vmxnet_change_mtu(struct net_device *dev, int new_mtu)
{
- struct Vmxnet_Private *lp = (struct Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
if (new_mtu < VMXNET_MIN_MTU || new_mtu > VMXNET_MAX_MTU) {
return -EINVAL;
@@ -258,7 +258,7 @@
vmxnet_get_drvinfo(struct net_device *dev,
struct ethtool_drvinfo *drvinfo)
{
- struct Vmxnet_Private *lp = dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
strncpy(drvinfo->driver, vmxnet_driver.name, sizeof(drvinfo->driver));
drvinfo->driver[sizeof(drvinfo->driver) - 1] = '\0';
@@ -296,7 +296,7 @@
vmxnet_set_tso(struct net_device *dev, u32 data)
{
if (data) {
- struct Vmxnet_Private *lp = (struct Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
if (!lp->tso) {
return -EINVAL;
@@ -448,7 +448,7 @@
}
if (value.data) {
- struct Vmxnet_Private *lp = (struct Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
if (!lp->tso) {
return -EINVAL;
@@ -620,7 +620,7 @@
static void
vmxnet_tx_timeout(struct net_device *dev)
{
- compat_netif_wake_queue(dev);
+ netif_wake_queue(dev);
}
#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,43) */
@@ -646,11 +646,10 @@
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,43)
struct net_device *dev = (struct net_device *)data;
- struct Vmxnet_Private *lp;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
uint32 status;
int ok;
- lp = dev->priv;
status = inl(dev->base_addr + VMXNET_STATUS_ADDR);
ok = (status & VMXNET_STATUS_CONNECTED) != 0;
if (ok != netif_carrier_ok(dev)) {
@@ -825,13 +824,13 @@
}
}
- dev = compat_alloc_etherdev(sizeof *lp);
+ dev = alloc_etherdev(sizeof *lp);
if (!dev) {
printk(KERN_ERR "Unable to allocate ethernet device\n");
goto morph_back;
}
- lp = dev->priv;
+ lp = netdev_priv(dev);
lp->pdev = pdev;
dev->base_addr = ioaddr;
@@ -1085,14 +1084,14 @@
#endif
compat_pci_unmap_single(lp->pdev, lp->ddPA, lp->ddSize,
PCI_DMA_BIDIRECTIONAL);
kfree(lp->dd);
-free_dev:;
- compat_free_netdev(dev);
-morph_back:;
+free_dev:
+ free_netdev(dev);
+morph_back:
if (morphed) {
/* Morph back to LANCE hw. */
outw(LANCE_CHIP, ioaddr - MORPH_PORT_SIZE);
}
-release_reg:;
+release_reg:
release_region(reqIOAddr, reqIOSize);
pci_disable:;
compat_pci_disable_device(pdev);
@@ -1119,7 +1118,7 @@
vmxnet_remove_device(struct pci_dev* pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
- struct Vmxnet_Private *lp = dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
/*
* Do this before device is gone so we never call netif_carrier_* after
@@ -1170,7 +1169,7 @@
compat_pci_unmap_single(lp->pdev, lp->ddPA, lp->ddSize,
PCI_DMA_BIDIRECTIONAL);
kfree(lp->dd);
- compat_free_netdev(dev);
+ free_netdev(dev);
compat_pci_disable_device(pdev);
}
@@ -1193,7 +1192,7 @@
static int
vmxnet_init_ring(struct net_device *dev)
{
- struct Vmxnet_Private *lp = (Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
Vmxnet2_DriverData *dd = lp->dd;
unsigned int i;
size_t offset;
@@ -1321,7 +1320,7 @@
static int
vmxnet_open(struct net_device *dev)
{
- struct Vmxnet_Private *lp = (Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
unsigned int ioaddr = dev->base_addr;
uint32 ddPA;
@@ -1351,7 +1350,7 @@
#endif
lp->dd->txStopped = FALSE;
- compat_netif_start_queue(dev);
+ netif_start_queue(dev);
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,43)
dev->interrupt = 0;
@@ -1575,7 +1574,7 @@
static void
check_tx_queue(struct net_device *dev)
{
- Vmxnet_Private *lp = (Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
Vmxnet2_DriverData *dd = lp->dd;
int completed = 0;
@@ -1611,8 +1610,8 @@
lp->numTxPending -= completed;
// XXX conditionally wake up the queue based on the # of freed entries
- if (compat_netif_queue_stopped(dev)) {
- compat_netif_wake_queue(dev);
+ if (netif_queue_stopped(dev)) {
+ netif_wake_queue(dev);
dd->txStopped = FALSE;
}
}
@@ -1643,7 +1642,7 @@
vmxnet_tx(struct sk_buff *skb, struct net_device *dev)
{
Vmxnet_TxStatus status = VMXNET_DEFER_TRANSMIT;
- struct Vmxnet_Private *lp = (struct Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
Vmxnet2_DriverData *dd = lp->dd;
unsigned long flags;
Vmxnet2_TxRingEntry *xre;
@@ -1684,7 +1683,7 @@
/* check for the availability of tx ring entries */
if (dd->txRingLength - lp->numTxPending < txEntries) {
dd->txStopped = TRUE;
- compat_netif_stop_queue(dev);
+ netif_stop_queue(dev);
check_tx_queue(dev);
spin_unlock_irqrestore(&lp->txLock, flags);
@@ -1814,7 +1813,7 @@
if (lp->txBufInfo[dd->txDriverNext].skb != NULL) {
dd->txStopped = TRUE;
- compat_netif_stop_queue(dev);
+ netif_stop_queue(dev);
check_tx_queue(dev);
spin_unlock_irqrestore(&lp->txLock, flags);
@@ -2043,7 +2042,7 @@
static int
vmxnet_rx(struct net_device *dev)
{
- Vmxnet_Private *lp = (Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
Vmxnet2_DriverData *dd = lp->dd;
if (!lp->devOpen) {
@@ -2173,7 +2172,7 @@
}
- lp = (struct Vmxnet_Private *)dev->priv;
+ lp = netdev_priv(dev);
outl(VMXNET_CMD_INTR_ACK, dev->base_addr + VMXNET_COMMAND_ADDR);
dd = lp->dd;
@@ -2194,8 +2193,8 @@
spin_unlock(&lp->txLock);
}
- if (compat_netif_queue_stopped(dev) && !lp->dd->txStopped) {
- compat_netif_wake_queue(dev);
+ if (netif_queue_stopped(dev) && !lp->dd->txStopped) {
+ netif_wake_queue(dev);
}
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,43)
@@ -2255,7 +2254,7 @@
vmxnet_close(struct net_device *dev)
{
unsigned int ioaddr = dev->base_addr;
- Vmxnet_Private *lp = (Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
int i;
unsigned long flags;
@@ -2267,7 +2266,7 @@
dev->start = 0;
#endif
- compat_netif_stop_queue(dev);
+ netif_stop_queue(dev);
lp->devOpen = FALSE;
@@ -2348,7 +2347,7 @@
static int
vmxnet_load_multicast (struct net_device *dev)
{
- Vmxnet_Private *lp = (Vmxnet_Private *) dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
volatile u16 *mcast_table = (u16 *)lp->dd->LADRF;
struct dev_mc_list *dmi = dev->mc_list;
char *addrs;
@@ -2409,7 +2408,7 @@
vmxnet_set_multicast_list(struct net_device *dev)
{
unsigned int ioaddr = dev->base_addr;
- Vmxnet_Private *lp = (Vmxnet_Private *)dev->priv;
+ struct Vmxnet_Private *lp = netdev_priv(dev);
lp->dd->ifflags = ~(VMXNET_IFF_PROMISC
|VMXNET_IFF_BROADCAST
@@ -2459,7 +2458,7 @@
unsigned int ioaddr = dev->base_addr;
int i;
- if (compat_netif_running(dev))
+ if (netif_running(dev))
return -EBUSY;
memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
@@ -2489,7 +2488,7 @@
static struct net_device_stats *
vmxnet_get_stats(struct net_device *dev)
{
- Vmxnet_Private *lp = (Vmxnet_Private *)dev->priv;
+ Vmxnet_Private *lp = netdev_priv(dev);
return &lp->stats;
}
|
58 messages has been excluded from this view by a project administrator.
