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: Dmitry T. <dt...@vm...> - 2012-12-19 18:24:17
|
On Wednesday, December 19, 2012 03:52:08 PM Lennart Poettering wrote: > On Fri, 14.12.12 06:04, Reindl Harald (h.r...@th...) wrote: > > WARNING: at fs/ext4/super.c:339 ext4_journal_start_sb+0x11e/0x130() > > Hardware name: VMware Virtual Platform > > Modules linked in: binfmt_misc cls_u32 sch_htb xt_hl xt_LOG xt_limit > > xt_recent nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack > > xt_iprange xt_multiport vmw_balloon crc32c_intel ghash_clmulni_intel > > vmxnet3 vmw_pvscsi > This doesnt look in anyway related to systemd... The warnigns are coming from ext4 driver so I'd start there... Thanks, Dmitry |
|
From: Lennart P. <le...@po...> - 2012-12-19 15:08:14
|
On Fri, 14.12.12 06:04, Reindl Harald (h.r...@th...) wrote: > WARNING: at fs/ext4/super.c:339 ext4_journal_start_sb+0x11e/0x130() > Hardware name: VMware Virtual Platform > Modules linked in: binfmt_misc cls_u32 sch_htb xt_hl xt_LOG xt_limit xt_recent nf_conntrack_ipv4 nf_defrag_ipv4 > xt_state nf_conntrack xt_iprange xt_multiport vmw_balloon crc32c_intel ghash_clmulni_intel vmxnet3 vmw_pvscsi This doesnt look in anyway related to systemd... Lennart -- Lennart Poettering - Red Hat, Inc. |
|
From: Reindl H. <h.r...@th...> - 2012-12-14 16:52:28
|
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1189 this is all nice but why can this not be configured in a config-file on the guest which could be distributed with shell-scripts to any machine in the cluster? _______________________________________________ GENERALLY: sync time backwards is a BUG yesterday we got a new DL380 and forget to corect hardware clock due setup resulting in 2012/08/20 and a ton of problems with mailservers, cronjobs, crashing applications and running crazy webapps - you NEVER want sync BACKWARD the system time by any autoamtism on a linux-system, really NEVER the only case where a time-sync is acceptable is after wakeup a suspended guest and in this case it is invalid to sync time backwards, but in all other cases like vmotion if timesync is disabled open-vm-tools must not touch systemtime on machines if the chckbox is disabled because you are using ntpd |
|
From: Reindl H. <h.r...@th...> - 2012-12-14 05:04:41
|
i spent from 6 PM until now to find out why after hardware upgrade Fedora 17 VM's are crashing on vSpere5 cluster while make snapshot / suspend filesystem for VMware-Datarecovery * EVC Intel® "Westmere" Generation (Xeon® 32nm Core™ i7) * UUID=.... /boot ext4 defaults,comment=systemd.automount,noauto 0 1 * open-vm-tools-9.2.2.893683 * vSphere5 build 821926 * Fedora 17 x86_64 with any 3.6.8 to 3.6.10 Kernel (i guess others too) * /boot was a ext2 without journal mounted as ext4, other FS native ext4 with EVC "Xeon 45 nm Core2" on the same host no problem without systemd.automount also no problem, even with 32nm i7 EVC with manual snapshots no problem in any case this happens really only in this combination on both hosts one with dual socket E5-2640, one with dual socket E5640 below the stacktrace, may somebody have fun to debug this, i am done after a whole night finding the workaround not use systemd.automount in this environment killing the joy of new hardware...... ------------[ cut here ]------------ WARNING: at fs/ext4/super.c:339 ext4_journal_start_sb+0x11e/0x130() Hardware name: VMware Virtual Platform Modules linked in: binfmt_misc cls_u32 sch_htb xt_hl xt_LOG xt_limit xt_recent nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_iprange xt_multiport vmw_balloon crc32c_intel ghash_clmulni_intel vmxnet3 vmw_pvscsi Pid: 606, comm: master Not tainted 3.6.10-2.fc17.x86_64 #1 Call Trace: [<ffffffff8105c8ef>] warn_slowpath_common+0x7f/0xc0 [<ffffffff81216296>] ? ext4_dirty_inode+0x26/0x60 [<ffffffff8105c94a>] warn_slowpath_null+0x1a/0x20 [<ffffffff8123152e>] ext4_journal_start_sb+0x11e/0x130 [<ffffffff81216296>] ext4_dirty_inode+0x26/0x60 [<ffffffff811b85df>] __mark_inode_dirty+0x3f/0x200 [<ffffffff811a97a1>] update_time+0x81/0xc0 [<ffffffff811ade40>] ? __mnt_want_write+0x40/0x60 [<ffffffff811a9878>] file_update_time+0x98/0xf0 [<ffffffff811997b0>] pipe_write+0x420/0x540 [<ffffffff8118f9e7>] do_sync_write+0xa7/0xe0 [<ffffffff8119026c>] vfs_write+0xac/0x180 [<ffffffff8119059a>] sys_write+0x4a/0x90 [<ffffffff816270e9>] system_call_fastpath+0x16/0x1b ---[ end trace 4af44fba571309d1 ]--- ------------[ cut here ]------------ WARNING: at fs/ext4/super.c:339 ext4_journal_start_sb+0x11e/0x130() Hardware name: VMware Virtual Platform Modules linked in: binfmt_misc cls_u32 sch_htb xt_hl xt_LOG xt_limit xt_recent nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_iprange xt_multiport vmw_balloon crc32c_intel ghash_clmulni_intel vmxnet3 vmw_pvscsi Pid: 606, comm: master Tainted: G W 3.6.10-2.fc17.x86_64 #1 Call Trace: [<ffffffff8105c8ef>] warn_slowpath_common+0x7f/0xc0 [<ffffffff81216296>] ? ext4_dirty_inode+0x26/0x60 [<ffffffff8105c94a>] warn_slowpath_null+0x1a/0x20 [<ffffffff8123152e>] ext4_journal_start_sb+0x11e/0x130 [<ffffffff81216296>] ext4_dirty_inode+0x26/0x60 [<ffffffff811b85df>] __mark_inode_dirty+0x3f/0x200 [<ffffffff811a97a1>] update_time+0x81/0xc0 [<ffffffff811ade40>] ? __mnt_want_write+0x40/0x60 [<ffffffff811a9878>] file_update_time+0x98/0xf0 [<ffffffff811997b0>] pipe_write+0x420/0x540 [<ffffffff8118f9e7>] do_sync_write+0xa7/0xe0 [<ffffffff8119026c>] vfs_write+0xac/0x180 [<ffffffff8119059a>] sys_write+0x4a/0x90 [<ffffffff816270e9>] system_call_fastpath+0x16/0x1b ---[ end trace 4af44fba571309d2 ]-- |
|
From: Reindl H. <h.r...@th...> - 2012-11-18 12:12:24
|
Am 18.11.2012 12:47, schrieb Konrad Vrba: > Dear all, > I am trying to compile open-vm-tools-9.0.0-782409 against linux 3.6.6 and get the following error: > I have also tried to compile open-vm-tools-9.2.2-893683, which works, but apparently only because it compiles > without the vmsync module > > could somebody please advise how to fix this? there is no need to fix this the vmsync moule is NOT NEEDED at all on recenct kernels |
|
From: Konrad V. <kon...@gm...> - 2012-11-18 11:47:13
|
Dear all, I am trying to compile open-vm-tools-9.0.0-782409 against linux 3.6.6 and get the following error: /home/src/open-vm-tools/open-vm-tools-9.0.0-782409/modules/linux/vmsync/sync.c: In function ‘VmSyncThawDevices’: /home/src/open-vm-tools/open-vm-tools-9.0.0-782409/modules/linux/vmsync/sync.c:165: error: ‘struct super_block’ has no member named ‘s_frozen’ /home/src/open-vm-tools/open-vm-tools-9.0.0-782409/modules/linux/vmsync/sync.c: In function ‘VmSyncAddPath’: /home/src/open-vm-tools/open-vm-tools-9.0.0-782409/modules/linux/vmsync/sync.c:240: error: ‘struct super_block’ has no member named ‘s_frozen’ make[4]: *** [/home/src/open-vm-tools/open-vm-tools-9.0.0-782409/modules/linux/vmsync/sync.o] Error 1 make[3]: *** [_module_/home/src/open-vm-tools/open-vm-tools-9.0.0-782409/modules/linux/vmsync] Error 2 make[2]: *** [vmsync.ko] Error 2 make[1]: *** [vmsync] Error 2 make: *** [all-recursive] Error 1 I have also tried to compile open-vm-tools-9.2.2-893683, which works, but apparently only because it compiles without the vmsync module could somebody please advise how to fix this? many thanks, Konrad |
|
From: SourceForge.net <no...@so...> - 2012-11-15 18:48:37
|
Tracker item #3587492, was opened at 2012-11-15 04:52 Message generated for change (Comment added) made by dtor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3587492&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: misc Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Watnuss (watnuss) Assigned to: Nobody/Anonymous (nobody) Summary: vmtoolsd does not close on poweroff/reboot Initial Comment: I am using ArchLinux (using systemd) as guest system. Everytime I poweroff or reboot the system it holds for a minute coming to the sequence "Stopped target Remote File Systems." Looking to journalctl give following hint: " Nov 15 11:45:01 warch systemd[1]: Stopped target Remote File Systems. Nov 15 11:46:06 warch systemd[1]: vmtoolsd.service stopping timed out. Killing. Nov 15 11:46:06 warch systemd[1]: vmtoolsd.service: main process exited,code=killed, status=9/KILL Nov 15 11:46:06 warch systemd[1]: Stopped Open Virtual Machine Tools (VMwareTools). Nov 15 11:46:06 warch systemd[1]: Unit vmtoolsd.service entered failed state " So it looks like the service could not be closed as it should. If you need any further logs or any checks I can offer them to you. Just tell me what you need. I did not find anything else by myself. I am running Linux kernel 3.6.6 with open-vm-tools 9.2.0.-2 and open-vm-tools-modules 9.2.2-3. ---------------------------------------------------------------------- >Comment By: Dmitry Torokhov (dtor) Date: 2012-11-15 10:48 Message: Open VM Tools does not provide systemd (or upstart) integration, it was done by Archlinux package owner and should be reported there. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3587492&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-15 12:52:03
|
Tracker item #3587492, was opened at 2012-11-15 04:52 Message generated for change (Tracker Item Submitted) made by watnuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3587492&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: misc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Watnuss (watnuss) Assigned to: Nobody/Anonymous (nobody) Summary: vmtoolsd does not close on poweroff/reboot Initial Comment: I am using ArchLinux (using systemd) as guest system. Everytime I poweroff or reboot the system it holds for a minute coming to the sequence "Stopped target Remote File Systems." Looking to journalctl give following hint: " Nov 15 11:45:01 warch systemd[1]: Stopped target Remote File Systems. Nov 15 11:46:06 warch systemd[1]: vmtoolsd.service stopping timed out. Killing. Nov 15 11:46:06 warch systemd[1]: vmtoolsd.service: main process exited,code=killed, status=9/KILL Nov 15 11:46:06 warch systemd[1]: Stopped Open Virtual Machine Tools (VMwareTools). Nov 15 11:46:06 warch systemd[1]: Unit vmtoolsd.service entered failed state " So it looks like the service could not be closed as it should. If you need any further logs or any checks I can offer them to you. Just tell me what you need. I did not find anything else by myself. I am running Linux kernel 3.6.6 with open-vm-tools 9.2.0.-2 and open-vm-tools-modules 9.2.2-3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3587492&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-07 22:58:42
|
Tracker item #3584834, was opened at 2012-11-06 12:16 Message generated for change (Comment added) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584834&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: 8 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs kernel module panics on FreeBSD Initial Comment: The problem reported in bug 3584833 suggests, the module has not been tested on FreeBSD in a while... Indeed, after fixing the build, and trying to use the module I get the following kernel panic (this is FreeBSD/x86 8.3, 32-bit): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x4 ... #6 0xc07c0d2c in calltrap () at /mi/src/sys/i386/i386/exception.s:168 #7 0xc83add06 in DblLnkLst_Link (l1=0xc6ff3644, l2=0xc7560000) at dbllnklst.h:153 #8 0xc83adcdb in DblLnkLst_LinkLast (head=0xc6ff3644, l=0xc7560000) at dbllnklst.h:286 #9 0xc83adcab in HgfsKReq_AllocateRequest (container=0xc6ff3640, errorRet=0xe9461994) at request.c:418 #10 0xc83b2da6 in HgfsStatfsInt (vp=0xc831ca78, stat=0xc727ecf4) at vfsopscommon.c:77 #11 0xc83aa44b in HgfsVfsMount (mp=0xc727ec94) at vfsops.c:258 #12 0xc0670732 in vfs_donmount (td=0xc78825c0, fsflags=0, fsoptions=0xc728bd00) at /mi/src/sys/kern/vfs_mount.c:1011 #13 0xc0671011 in nmount (td=0xc78825c0, uap=0xe9461cec) at /mi/src/sys/kern/vfs_mount.c:447 ... Examining frame #7 reveals: (kgdb) p *l1 $1 = {prev = 0x0, next = 0xc7560000} (kgdb) p *l2 $2 = {prev = 0x0, next = 0x0} And then: (kgdb) up #8 0xc83adcdb in DblLnkLst_LinkLast (head=0xc6ff3644, l=0xc7560000) at dbllnklst.h:286 286 in dbllnklst.h (kgdb) p *head $3 = {prev = 0x0, next = 0xc7560000} (kgdb) p *l $4 = {prev = 0x0, next = 0x0} (It is possible, the problem reported in bug 3580633 is related.) I have the core-dump with debug symbols, so, if anybody cares for more variables, etc. let me know. ---------------------------------------------------------------------- >Comment By: Mikhail Teterin (kot) Date: 2012-11-07 14:58 Message: FWIW, I just tried the 9.2.2-893683 and got the exact same panic. ---------------------------------------------------------------------- Comment By: Mikhail Teterin (kot) Date: 2012-11-06 12:20 Message: I should add, that I experienced this problem with 9.2.0-799703. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584834&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 21:35:59
|
Tracker item #3584860, was opened at 2012-11-06 13:32 Message generated for change (Settings changed) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584860&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: None Group: None >Status: Deleted Resolution: Duplicate Priority: 5 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: configure script still searches for gtkmm.h Initial Comment: It seems, vmware-toolbox was the only user of gtkmm and friends. After its removal, perhaps, references to this and other GNOME headers can be removed from configure and sources? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584860&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 21:32:26
|
Tracker item #3584860, was opened at 2012-11-06 13:32 Message generated for change (Settings changed) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584860&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: None Group: None Status: Open >Resolution: Duplicate Priority: 5 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: configure script still searches for gtkmm.h Initial Comment: It seems, vmware-toolbox was the only user of gtkmm and friends. After its removal, perhaps, references to this and other GNOME headers can be removed from configure and sources? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584860&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 21:32:06
|
Tracker item #3584860, was opened at 2012-11-06 13:32 Message generated for change (Tracker Item Submitted) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584860&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: configure script still searches for gtkmm.h Initial Comment: It seems, vmware-toolbox was the only user of gtkmm and friends. After its removal, perhaps, references to this and other GNOME headers can be removed from configure and sources? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584860&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 20:43:30
|
Tracker item #3584849, was opened at 2012-11-06 12:43 Message generated for change (Tracker Item Submitted) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584849&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: configure script still searches for gtkmm.h Initial Comment: It seems, vmware-toolbox was the only user of gtkmm and friends. After its removal, perhaps, references to this and other GNOME headers can be removed from configure and sources? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584849&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 20:20:40
|
Tracker item #3584834, was opened at 2012-11-06 12:16 Message generated for change (Comment added) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584834&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: 8 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs kernel module panics on FreeBSD Initial Comment: The problem reported in bug 3584833 suggests, the module has not been tested on FreeBSD in a while... Indeed, after fixing the build, and trying to use the module I get the following kernel panic (this is FreeBSD/x86 8.3, 32-bit): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x4 ... #6 0xc07c0d2c in calltrap () at /mi/src/sys/i386/i386/exception.s:168 #7 0xc83add06 in DblLnkLst_Link (l1=0xc6ff3644, l2=0xc7560000) at dbllnklst.h:153 #8 0xc83adcdb in DblLnkLst_LinkLast (head=0xc6ff3644, l=0xc7560000) at dbllnklst.h:286 #9 0xc83adcab in HgfsKReq_AllocateRequest (container=0xc6ff3640, errorRet=0xe9461994) at request.c:418 #10 0xc83b2da6 in HgfsStatfsInt (vp=0xc831ca78, stat=0xc727ecf4) at vfsopscommon.c:77 #11 0xc83aa44b in HgfsVfsMount (mp=0xc727ec94) at vfsops.c:258 #12 0xc0670732 in vfs_donmount (td=0xc78825c0, fsflags=0, fsoptions=0xc728bd00) at /mi/src/sys/kern/vfs_mount.c:1011 #13 0xc0671011 in nmount (td=0xc78825c0, uap=0xe9461cec) at /mi/src/sys/kern/vfs_mount.c:447 ... Examining frame #7 reveals: (kgdb) p *l1 $1 = {prev = 0x0, next = 0xc7560000} (kgdb) p *l2 $2 = {prev = 0x0, next = 0x0} And then: (kgdb) up #8 0xc83adcdb in DblLnkLst_LinkLast (head=0xc6ff3644, l=0xc7560000) at dbllnklst.h:286 286 in dbllnklst.h (kgdb) p *head $3 = {prev = 0x0, next = 0xc7560000} (kgdb) p *l $4 = {prev = 0x0, next = 0x0} (It is possible, the problem reported in bug 3580633 is related.) I have the core-dump with debug symbols, so, if anybody cares for more variables, etc. let me know. ---------------------------------------------------------------------- >Comment By: Mikhail Teterin (kot) Date: 2012-11-06 12:20 Message: I should add, that I experienced this problem with 9.2.0-799703. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584834&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 20:17:29
|
Tracker item #3584834, was opened at 2012-11-06 12:16 Message generated for change (Settings changed) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584834&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: 8 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs kernel module panics on FreeBSD Initial Comment: The problem reported in bug 3584833 suggests, the module has not been tested on FreeBSD in a while... Indeed, after fixing the build, and trying to use the module I get the following kernel panic (this is FreeBSD/x86 8.3, 32-bit): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x4 ... #6 0xc07c0d2c in calltrap () at /mi/src/sys/i386/i386/exception.s:168 #7 0xc83add06 in DblLnkLst_Link (l1=0xc6ff3644, l2=0xc7560000) at dbllnklst.h:153 #8 0xc83adcdb in DblLnkLst_LinkLast (head=0xc6ff3644, l=0xc7560000) at dbllnklst.h:286 #9 0xc83adcab in HgfsKReq_AllocateRequest (container=0xc6ff3640, errorRet=0xe9461994) at request.c:418 #10 0xc83b2da6 in HgfsStatfsInt (vp=0xc831ca78, stat=0xc727ecf4) at vfsopscommon.c:77 #11 0xc83aa44b in HgfsVfsMount (mp=0xc727ec94) at vfsops.c:258 #12 0xc0670732 in vfs_donmount (td=0xc78825c0, fsflags=0, fsoptions=0xc728bd00) at /mi/src/sys/kern/vfs_mount.c:1011 #13 0xc0671011 in nmount (td=0xc78825c0, uap=0xe9461cec) at /mi/src/sys/kern/vfs_mount.c:447 ... Examining frame #7 reveals: (kgdb) p *l1 $1 = {prev = 0x0, next = 0xc7560000} (kgdb) p *l2 $2 = {prev = 0x0, next = 0x0} And then: (kgdb) up #8 0xc83adcdb in DblLnkLst_LinkLast (head=0xc6ff3644, l=0xc7560000) at dbllnklst.h:286 286 in dbllnklst.h (kgdb) p *head $3 = {prev = 0x0, next = 0xc7560000} (kgdb) p *l $4 = {prev = 0x0, next = 0x0} (It is possible, the problem reported in bug 3580633 is related.) I have the core-dump with debug symbols, so, if anybody cares for more variables, etc. let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584834&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 20:16:42
|
Tracker item #3584833, was opened at 2012-11-06 12:07 Message generated for change (Settings changed) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584833&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: 7 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs kernel module does not build right on FreeBSD Initial Comment: It seems, due to a typo the debug.o is never linked into the module. This prevents the module from being loaded into kernel, because HgfsDebugPrintVattr() remains an unknown symbol. This simple patch fixes the issue: --- modules/freebsd/vmhgfs/Makefile 2010-10-20 05:19:54.000000000 +0900 +++ modules/freebsd/vmhgfs/Makefile 2010-11-11 23:06:07.000000000 +0900 @@ -48,5 +48,5 @@ COMMON_HGFS_SRCS := debug.c -COMMON_HGFS_SRCS := bdhandler.c +COMMON_HGFS_SRCS += bdhandler.c COMMON_HGFS_SRCS += request.c COMMON_HGFS_SRCS += worker.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584833&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 20:16:16
|
Tracker item #3584834, was opened at 2012-11-06 12:16 Message generated for change (Tracker Item Submitted) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584834&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: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs kernel module panics on FreeBSD Initial Comment: The problem reported in bug 3584833 suggests, the module has not been tested on FreeBSD in a while... Indeed, after fixing the build, and trying to use the module I get the following kernel panic (this is FreeBSD/x86 8.3, 32-bit): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x4 ... #6 0xc07c0d2c in calltrap () at /mi/src/sys/i386/i386/exception.s:168 #7 0xc83add06 in DblLnkLst_Link (l1=0xc6ff3644, l2=0xc7560000) at dbllnklst.h:153 #8 0xc83adcdb in DblLnkLst_LinkLast (head=0xc6ff3644, l=0xc7560000) at dbllnklst.h:286 #9 0xc83adcab in HgfsKReq_AllocateRequest (container=0xc6ff3640, errorRet=0xe9461994) at request.c:418 #10 0xc83b2da6 in HgfsStatfsInt (vp=0xc831ca78, stat=0xc727ecf4) at vfsopscommon.c:77 #11 0xc83aa44b in HgfsVfsMount (mp=0xc727ec94) at vfsops.c:258 #12 0xc0670732 in vfs_donmount (td=0xc78825c0, fsflags=0, fsoptions=0xc728bd00) at /mi/src/sys/kern/vfs_mount.c:1011 #13 0xc0671011 in nmount (td=0xc78825c0, uap=0xe9461cec) at /mi/src/sys/kern/vfs_mount.c:447 ... Examining frame #7 reveals: (kgdb) p *l1 $1 = {prev = 0x0, next = 0xc7560000} (kgdb) p *l2 $2 = {prev = 0x0, next = 0x0} And then: (kgdb) up #8 0xc83adcdb in DblLnkLst_LinkLast (head=0xc6ff3644, l=0xc7560000) at dbllnklst.h:286 286 in dbllnklst.h (kgdb) p *head $3 = {prev = 0x0, next = 0xc7560000} (kgdb) p *l $4 = {prev = 0x0, next = 0x0} (It is possible, the problem reported in bug 3580633 is related.) I have the core-dump with debug symbols, so, if anybody cares for more variables, etc. let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584834&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 20:07:38
|
Tracker item #3584833, was opened at 2012-11-06 12:07 Message generated for change (Tracker Item Submitted) made by kot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584833&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mikhail Teterin (kot) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs kernel module does not build right on FreeBSD Initial Comment: It seems, due to a typo the debug.o is never linked into the module. This prevents the module from being loaded into kernel, because HgfsDebugPrintVattr() remains an unknown symbol. This simple patch fixes the issue: --- modules/freebsd/vmhgfs/Makefile 2010-10-20 05:19:54.000000000 +0900 +++ modules/freebsd/vmhgfs/Makefile 2010-11-11 23:06:07.000000000 +0900 @@ -48,5 +48,5 @@ COMMON_HGFS_SRCS := debug.c -COMMON_HGFS_SRCS := bdhandler.c +COMMON_HGFS_SRCS += bdhandler.c COMMON_HGFS_SRCS += request.c COMMON_HGFS_SRCS += worker.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3584833&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-10-28 21:38:14
|
Tracker item #3580075, was opened at 2012-10-25 02:22 Message generated for change (Comment added) made by yaberauneya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580075&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: misc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Garrett Cooper (yaberauneya) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance util/misc.c to divine paths on FreeBSD Initial Comment: The attached patch was obtained from svn://svn.freebsd.org/ports/head/emulators/open-vm-tools/files/patch-util_misc.c and was according to the report fixed shutdown utility pathing on VMware ESXi 3.5. ---------------------------------------------------------------------- >Comment By: Garrett Cooper (yaberauneya) Date: 2012-10-28 14:38 Message: Uh, I see where the agreement form is now. I'll submit it in a while, and I guess you can put all of my items on hold until then. ---------------------------------------------------------------------- Comment By: Garrett Cooper (yaberauneya) Date: 2012-10-28 14:33 Message: Not sure about the first case, because it really doesn't make sense to use msdosfs IMO, but the second case still seems usable. Signed-off-by: Garrett Cooper <yan...@gm...> ---------------------------------------------------------------------- Comment By: Dmitry Torokhov (dtor) Date: 2012-10-25 09:16 Message: This is weird. Since when FreeBSD uses case-insensitive filesystems? Also, please note that we unfortunately can not take patches in unless you sign a contribution agreement. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580075&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-10-28 21:33:26
|
Tracker item #3580075, was opened at 2012-10-25 02:22 Message generated for change (Comment added) made by yaberauneya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580075&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: misc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Garrett Cooper (yaberauneya) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance util/misc.c to divine paths on FreeBSD Initial Comment: The attached patch was obtained from svn://svn.freebsd.org/ports/head/emulators/open-vm-tools/files/patch-util_misc.c and was according to the report fixed shutdown utility pathing on VMware ESXi 3.5. ---------------------------------------------------------------------- >Comment By: Garrett Cooper (yaberauneya) Date: 2012-10-28 14:33 Message: Not sure about the first case, because it really doesn't make sense to use msdosfs IMO, but the second case still seems usable. Signed-off-by: Garrett Cooper <yan...@gm...> ---------------------------------------------------------------------- Comment By: Dmitry Torokhov (dtor) Date: 2012-10-25 09:16 Message: This is weird. Since when FreeBSD uses case-insensitive filesystems? Also, please note that we unfortunately can not take patches in unless you sign a contribution agreement. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580075&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-10-28 21:31:14
|
Tracker item #3580078, was opened at 2012-10-25 02:32 Message generated for change (Comment added) made by yaberauneya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580078&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: Garrett Cooper (yaberauneya) Assigned to: Nobody/Anonymous (nobody) Summary: "Fix locking in vmmemctl" on FreeBSD 9.x+ Initial Comment: Fix obtained from svn://svn.freebsd.org/ports/head/emulators/open-vm-tools/files/patch-vmmemctl-os.c . ---------------------------------------------------------------------- >Comment By: Garrett Cooper (yaberauneya) Date: 2012-10-28 14:31 Message: Signed-off-by: Garrett Cooper <yan...@gm...> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580078&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-10-26 23:22:55
|
Tracker item #3576588, was opened at 2012-10-11 23:10 Message generated for change (Comment added) made by robmcginley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3576588&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: Dustin C. Hatch (admiralnemo) Assigned to: Nobody/Anonymous (nobody) Summary: HGFS module fails to build against kernel 3.6.1 Initial Comment: Trying to build open-vm-tools-kmod-2012.05.21.724730 against gentoo-sources-3.6.1 fails with the following error: CC [M] /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/cpName.o /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/inode.c: In function ‘HgfsPermission’: /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/inode.c:1820:7: error: ‘struct hlist_head’ has no member named ‘next’ /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/inode.c:1820:7: warning: comparison of distinct pointer types lacks a cast [enabled by default] /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/inode.c:1821:19: warning: initialization from incompatible pointer type [enabled by default] make[2]: *** [/var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/inode.o] Error 1 make[2]: *** Waiting for unfinished jobs.... /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/dentry.c:43:4: warning: initialization from incompatible pointer type [enabled by default] /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/dentry.c:43:4: warning: (near initialization for ‘HgfsDentryOperations.d_revalidate’) [enabled by default] /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/page.c: In function ‘HgfsDoWriteBegin’: /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/page.c:896:39: error: ‘KM_USER0’ undeclared (first use in this function) /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/page.c:896:39: note: each undeclared identifier is reported only once for each function it appears in /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/page.c:896:7: error: too many arguments to function ‘kmap_atomic’ include/linux/highmem.h:66:21: note: declared here /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/page.c:904:36: error: macro "kunmap_atomic" passed 2 arguments, but takes just 1 /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/page.c:904:7: error: ‘kunmap_atomic’ undeclared (first use in this function) make[2]: *** [/var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs/page.o] Error 1 make[1]: *** [_module_/var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmhgfs] Error 2 make[1]: Leaving directory `/usr/src/linux-3.6.1-gentoo' make: *** [vmhgfs.ko] Error 2 See also Gentoo bug #437450 (https://bugs.gentoo.org/show_bug.cgi?id=437450) ---------------------------------------------------------------------- Comment By: Robert McGinley (robmcginley) Date: 2012-10-26 16:22 Message: Also fails against 3.6.2. This was from the ArchLinux open-vm-tools-dkms package version 2012.08.01 When dkms failed to build, i went in and ran make manually to see what the damage is. I find the very first line interesting. -------- Build log -------- Using 2.6.x kernel build system. make -C /lib/modules/3.6.2-1-ARCH/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \ MODULEBUILDDIR= modules make[1]: Entering directory `/usr/src/linux-3.6.2-1-ARCH' CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/message.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/dir.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/rpcout.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/hgfsUtil.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/cpName.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/request.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/module.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/stubs.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/cpNameUtil.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/tcp.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/link.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/bdhandler.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/backdoor.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/transport.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/file.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/super.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/vmci.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/fsutil.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/cpNameLinux.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/cpNameUtilLinux.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/hgfsBd.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/filesystem.o CC [M] /usr/src/open-vm-tools-2012.08.01/vmhgfs/page.o /usr/src/open-vm-tools-2012.08.01/vmhgfs/page.c: In function ‘HgfsDoWriteBegin’: /usr/src/open-vm-tools-2012.08.01/vmhgfs/page.c:896:39: error: ‘KM_USER0’ undeclared (first use in this function) /usr/src/open-vm-tools-2012.08.01/vmhgfs/page.c:896:39: note: each undeclared identifier is reported only once for each function it appears in /usr/src/open-vm-tools-2012.08.01/vmhgfs/page.c:896:7: error: too many arguments to function ‘kmap_atomic’ In file included from include/linux/pagemap.h:10:0, from /usr/src/open-vm-tools-2012.08.01/vmhgfs/page.c:28: include/linux/highmem.h:66:21: note: declared here /usr/src/open-vm-tools-2012.08.01/vmhgfs/page.c:904:36: error: macro "kunmap_atomic" passed 2 arguments, but takes just 1 /usr/src/open-vm-tools-2012.08.01/vmhgfs/page.c:904:7: error: ‘kunmap_atomic’ undeclared (first use in this function) make[2]: *** [/usr/src/open-vm-tools-2012.08.01/vmhgfs/page.o] Error 1 make[1]: *** [_module_/usr/src/open-vm-tools-2012.08.01/vmhgfs] Error 2 make[1]: Leaving directory `/usr/src/linux-3.6.2-1-ARCH' make: *** [vmhgfs.ko] Error 2 -- make 15.30s user 3.50s system 97% cpu 19.325 total ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3576588&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-10-26 22:46:17
|
Tracker item #3580633, was opened at 2012-10-26 14:35 Message generated for change (Comment added) made by commanderk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580633&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: Andrei Homescu (commanderk) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs kernel oops Initial Comment: I keep getting a kernel oops accessing my shared folder, since updating to 9.2.0. I'm running Arch Linux with kernel 3.6.3. Here's the output of dmesg: [ 212.818875] BUG: unable to handle kernel NULL pointer dereference at 0000000000000078 [ 212.818882] IP: [<ffffffffa01e1986>] HgfsDentryRevalidate+0x16/0x80 [vmhgfs] [ 212.818889] PGD 112453067 PUD 113f07067 PMD 0 [ 212.818893] Oops: 0000 [#1] PREEMPT SMP [ 212.818896] Modules linked in: vmhgfs(O) ppdev parport_pc parport snd_ens1371 snd_ac97_codec ac97_bus gameport snd_rawmidi snd_seq_device btusb bluetooth snd_pcm snd_page_alloc snd_timer rfkill snd e1000 soundcore joydev hid_generic usbhid hid vmw_balloon vmwgfx coretemp ttm crc32c_intel evdev drm ghash_clmulni_intel aesni_intel aes_x86_64 aes_generic ablk_helper cryptd processor microcode battery ac i2c_piix4 intel_agp i2c_core shpchp pci_hotplug container button intel_gtt psmouse pcspkr serio_raw vmci(O) ext4 crc16 jbd2 mbcache uhci_hcd sd_mod sr_mod cdrom pata_acpi ehci_hcd ata_generic usbcore usb_common floppy ata_piix libata scsi_mod [ 212.818933] CPU 0 [ 212.818936] Pid: 800, comm: ls Tainted: G O 3.6.3-1-ARCH #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform [ 212.818938] RIP: 0010:[<ffffffffa01e1986>] [<ffffffffa01e1986>] HgfsDentryRevalidate+0x16/0x80 [vmhgfs] [ 212.818942] RSP: 0018:ffff88011b819c68 EFLAGS: 00010202 [ 212.818944] RAX: ffffffffa01e5280 RBX: ffff880131b54cc0 RCX: 0000000000000038 [ 212.818945] RDX: ffff880131b54cc0 RSI: 0000000000000040 RDI: ffff880131b54cc0 [ 212.818946] RBP: ffff88011b819c78 R08: 00736b6f6f427363 R09: ffff88011b819de8 [ 212.818947] R10: ffff880136c49000 R11: 0000000000000007 R12: ffff88011b819d30 [ 212.818948] R13: 0000000000000000 R14: ffff88011b819dd8 R15: ffff88011b819d38 [ 212.818950] FS: 00007f60684be700(0000) GS:ffff88013ae00000(0000) knlGS:0000000000000000 [ 212.818952] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 212.818953] CR2: 0000000000000078 CR3: 000000013775a000 CR4: 00000000000407f0 [ 212.819018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 212.819040] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 212.819042] Process ls (pid: 800, threadinfo ffff88011b818000, task ffff880113d79830) [ 212.819043] Stack: [ 212.819044] ffff88011b819dd8 ffff88010ca69c80 ffff88011b819ce8 ffffffff8118b115 [ 212.819047] 0000000000025658 ffff88010b3b2e20 000000076fb5ded2 ffff880131b54cc0 [ 212.819050] ffff8801124c1048 00000002125edb00 0000000000000028 0000000000000000 [ 212.819053] Call Trace: [ 212.819059] [<ffffffff8118b115>] lookup_fast+0x265/0x310 [ 212.819062] [<ffffffff8118ccbf>] path_lookupat+0x10f/0x7f0 [ 212.819066] [<ffffffff81144fc5>] ? handle_pte_fault+0x95/0xaa0 [ 212.819068] [<ffffffff8118d3d1>] do_path_lookup+0x31/0xc0 [ 212.819070] [<ffffffff8118ac33>] ? getname_flags+0x53/0xf0 [ 212.819073] [<ffffffff8118faad>] user_path_at_empty+0x5d/0xa0 [ 212.819077] [<ffffffff81495d54>] ? do_page_fault+0x2c4/0x580 [ 212.819079] [<ffffffff8118fb01>] user_path_at+0x11/0x20 [ 212.819082] [<ffffffff81184255>] vfs_fstatat+0x35/0x70 [ 212.819085] [<ffffffff81192150>] ? sys_ioctl+0xa0/0xa0 [ 212.819088] [<ffffffff811842ae>] vfs_lstat+0x1e/0x20 [ 212.819091] [<ffffffff8118444a>] sys_newlstat+0x1a/0x40 [ 212.819095] [<ffffffff81492ee5>] ? page_fault+0x25/0x30 [ 212.819098] [<ffffffff81499b6d>] system_call_fastpath+0x1a/0x1f [ 212.819099] Code: 87 f4 e0 84 c0 75 9e eb 98 90 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 85 f6 48 89 fb 74 06 <f6> 46 38 40 75 54 48 89 df e8 4c b7 ff ff 85 c0 ba 01 00 00 00 [ 212.819132] RIP [<ffffffffa01e1986>] HgfsDentryRevalidate+0x16/0x80 [vmhgfs] [ 212.819138] RSP <ffff88011b819c68> [ 212.819140] CR2: 0000000000000078 [ 212.819143] ---[ end trace ebbe0e013c1e496a ]--- [ 212.819147] note: ls[800] exited with preempt_count 1 ---------------------------------------------------------------------- >Comment By: Andrei Homescu (commanderk) Date: 2012-10-26 15:46 Message: Bug seems fixed in development release, 2012-10-14 doesn't crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580633&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-10-26 21:35:16
|
Tracker item #3580633, was opened at 2012-10-26 14:35 Message generated for change (Tracker Item Submitted) made by commanderk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580633&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: Andrei Homescu (commanderk) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs kernel oops Initial Comment: I keep getting a kernel oops accessing my shared folder, since updating to 9.2.0. I'm running Arch Linux with kernel 3.6.3. Here's the output of dmesg: [ 212.818875] BUG: unable to handle kernel NULL pointer dereference at 0000000000000078 [ 212.818882] IP: [<ffffffffa01e1986>] HgfsDentryRevalidate+0x16/0x80 [vmhgfs] [ 212.818889] PGD 112453067 PUD 113f07067 PMD 0 [ 212.818893] Oops: 0000 [#1] PREEMPT SMP [ 212.818896] Modules linked in: vmhgfs(O) ppdev parport_pc parport snd_ens1371 snd_ac97_codec ac97_bus gameport snd_rawmidi snd_seq_device btusb bluetooth snd_pcm snd_page_alloc snd_timer rfkill snd e1000 soundcore joydev hid_generic usbhid hid vmw_balloon vmwgfx coretemp ttm crc32c_intel evdev drm ghash_clmulni_intel aesni_intel aes_x86_64 aes_generic ablk_helper cryptd processor microcode battery ac i2c_piix4 intel_agp i2c_core shpchp pci_hotplug container button intel_gtt psmouse pcspkr serio_raw vmci(O) ext4 crc16 jbd2 mbcache uhci_hcd sd_mod sr_mod cdrom pata_acpi ehci_hcd ata_generic usbcore usb_common floppy ata_piix libata scsi_mod [ 212.818933] CPU 0 [ 212.818936] Pid: 800, comm: ls Tainted: G O 3.6.3-1-ARCH #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform [ 212.818938] RIP: 0010:[<ffffffffa01e1986>] [<ffffffffa01e1986>] HgfsDentryRevalidate+0x16/0x80 [vmhgfs] [ 212.818942] RSP: 0018:ffff88011b819c68 EFLAGS: 00010202 [ 212.818944] RAX: ffffffffa01e5280 RBX: ffff880131b54cc0 RCX: 0000000000000038 [ 212.818945] RDX: ffff880131b54cc0 RSI: 0000000000000040 RDI: ffff880131b54cc0 [ 212.818946] RBP: ffff88011b819c78 R08: 00736b6f6f427363 R09: ffff88011b819de8 [ 212.818947] R10: ffff880136c49000 R11: 0000000000000007 R12: ffff88011b819d30 [ 212.818948] R13: 0000000000000000 R14: ffff88011b819dd8 R15: ffff88011b819d38 [ 212.818950] FS: 00007f60684be700(0000) GS:ffff88013ae00000(0000) knlGS:0000000000000000 [ 212.818952] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 212.818953] CR2: 0000000000000078 CR3: 000000013775a000 CR4: 00000000000407f0 [ 212.819018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 212.819040] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 212.819042] Process ls (pid: 800, threadinfo ffff88011b818000, task ffff880113d79830) [ 212.819043] Stack: [ 212.819044] ffff88011b819dd8 ffff88010ca69c80 ffff88011b819ce8 ffffffff8118b115 [ 212.819047] 0000000000025658 ffff88010b3b2e20 000000076fb5ded2 ffff880131b54cc0 [ 212.819050] ffff8801124c1048 00000002125edb00 0000000000000028 0000000000000000 [ 212.819053] Call Trace: [ 212.819059] [<ffffffff8118b115>] lookup_fast+0x265/0x310 [ 212.819062] [<ffffffff8118ccbf>] path_lookupat+0x10f/0x7f0 [ 212.819066] [<ffffffff81144fc5>] ? handle_pte_fault+0x95/0xaa0 [ 212.819068] [<ffffffff8118d3d1>] do_path_lookup+0x31/0xc0 [ 212.819070] [<ffffffff8118ac33>] ? getname_flags+0x53/0xf0 [ 212.819073] [<ffffffff8118faad>] user_path_at_empty+0x5d/0xa0 [ 212.819077] [<ffffffff81495d54>] ? do_page_fault+0x2c4/0x580 [ 212.819079] [<ffffffff8118fb01>] user_path_at+0x11/0x20 [ 212.819082] [<ffffffff81184255>] vfs_fstatat+0x35/0x70 [ 212.819085] [<ffffffff81192150>] ? sys_ioctl+0xa0/0xa0 [ 212.819088] [<ffffffff811842ae>] vfs_lstat+0x1e/0x20 [ 212.819091] [<ffffffff8118444a>] sys_newlstat+0x1a/0x40 [ 212.819095] [<ffffffff81492ee5>] ? page_fault+0x25/0x30 [ 212.819098] [<ffffffff81499b6d>] system_call_fastpath+0x1a/0x1f [ 212.819099] Code: 87 f4 e0 84 c0 75 9e eb 98 90 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 85 f6 48 89 fb 74 06 <f6> 46 38 40 75 54 48 89 df e8 4c b7 ff ff 85 c0 ba 01 00 00 00 [ 212.819132] RIP [<ffffffffa01e1986>] HgfsDentryRevalidate+0x16/0x80 [vmhgfs] [ 212.819138] RSP <ffff88011b819c68> [ 212.819140] CR2: 0000000000000078 [ 212.819143] ---[ end trace ebbe0e013c1e496a ]--- [ 212.819147] note: ls[800] exited with preempt_count 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580633&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-10-25 16:16:15
|
Tracker item #3580075, was opened at 2012-10-25 02:22 Message generated for change (Comment added) made by dtor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580075&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: misc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Garrett Cooper (yaberauneya) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance util/misc.c to divine paths on FreeBSD Initial Comment: The attached patch was obtained from svn://svn.freebsd.org/ports/head/emulators/open-vm-tools/files/patch-util_misc.c and was according to the report fixed shutdown utility pathing on VMware ESXi 3.5. ---------------------------------------------------------------------- >Comment By: Dmitry Torokhov (dtor) Date: 2012-10-25 09:16 Message: This is weird. Since when FreeBSD uses case-insensitive filesystems? Also, please note that we unfortunately can not take patches in unless you sign a contribution agreement. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3580075&group_id=204462 |
58 messages has been excluded from this view by a project administrator.
