New web-site issues and Mac Pro/Windows issue

Michael,

I don't know if it's just me, but since the web site changed I haven't been able to log in without requesting a new password each time...?

Secondly, where has the search function gone?

Thirdly, I started a thread a few months ago in relation to random drop outs for unknown reasons... It's still happening every now and again, but I don't believe it's directly related to our Synology NAS or VirtualHere itself, but you may be able to assist.

I get a feeling an issue is arising on our Windows 7 installations which run on Mac Pro's. I sometimes see the VH client struggling or failing to locate the hubs after those machines have been rebooted. I've also seen an issue, on those machines only, where an error has been reported stating the drivers were unable to be installed! Only after often several reboots do i get VH back up and running as it does smoothly on our other Server 2012 machines (which never fail to connect).

I suspect whatever the Mac/Windows issue is is somehow producing a problem in the network which caused VH to become unusable by any machine. The only way to clear the problem is a NAS reboot.

The NAS (DS216se) VH server and clients are all upto date.

Have you had any contact from other VH users suggesting similar issues/faults on Macs running Windows?

We've been keeping verbose logs on our domain but so far nothing has flagged up when VH becomes unusable. Neither does VH log any issue.

It's very strange.

Thanks

Richard

#2

Hi Richard, actually there have been a few changes and database restores in the last few days as we updated the website, but the website is basically done now and the search back in so it should be ok from now on...

OK so the scenario is you have bootcamp running win7 on an older mac pro(over i assume wifi) and when you reboot the mac it takes a while to find the virtualhere servers again.

Could you try one thing, on one of the macpros and you turn off auto-find in the virutalhere client and Right click USB Hubs->Specify Hubs -> And put in the IP address of the DS216se server. Then when that macbook reboots see if it quickly finds the server ok and reconnects.

Also on the machine that fails to "install the drivers" can you send me the c:\windows\inf\setupapi.dev.log file. That shows detailed install messages of what is going on.

I run virtualhere on my macair 2015 under win10 with no issues but i do notice sometimes it takes a while (1-2mins) to autofind the virtualhere server again when the air reboots. It might be some bonjour setting i need to investigate further. At the moment i ask bonjour every 30 seconds to look for virtualhere servers on the network ...

#3

Michael,

Glad to see the search bar has returned - much easier - however I still have to renew my password every time i want to log in...?

I've modified all the clients on the Mac Pro/Windows7 installs to specify the hubs to the IP:port address and, so far are finding the hub much quicker, as you expected.

Unfortunately, due to the type of work we do, i can't supply the setupapi log... that 'failure to install drivers' issue was eventually resolved by several reboots of the MAC - which is why i suspect there are issues with those machines.

As you correctly assumed, these are 2009 Mac Pros running Windows 7 under bootcamp, but connected to our domain through fibre. They can't be connected to the internet and therefore never get firmware updates!

We're moving away from them soon, back to pure intel/windows installations, so that may well sort us out.

Thanks again

Richard

#4

Michael,

I'm going to keep this thread going, if you don't mind, with some updates... Something I type may well trigger a query from you which may assist with our current issue.

Until we get replacements for the Mac Pro (2011 - i rechecked) running Windows 7 in bootcamp, we're having to struggle on, but i'm becoming more certain that these are what are causing our VH server to become unresponsive. The number of times the failure/fault has now occurred when either trying to select a dongle, or remove one on one of these machines cannot be a coincidence.

The latest event this morning provided some previously unseen log entries.

The scenario was; a license dongle was selected for 'stop using' by another user (on a Mac/Windows machine) but failed to clear. That dongle had been connected for about 4 days. I immediately tried to select a dongle (on an Intel/Server2012 machine) but got no response. No one else in the office could select or deselect a device on any machine.

When the initial Mac/Windows machine was rebooted (as it was unusable/unresponsive), the VH hub was not found - it is set to a specific hub address as we previously discussed.

I accessed the DS216se, stopped and restarted the VH server. It was not found by the clients and showed the following in the log.

LOG_ERR VirtualHere 2.8.4 caught signal 11 (Segmentation Fault) and must exit. Sorry... etc. Contact... etc
LOG_ERR Backtrace:
LOG_ERR ip=2123f0, sp=40331b50
LOG_ERR ip=2047e0, sp=40331e40
LOG_ERR End Backtrace

I then rebooted the DS. The VH server started automatically, but again was not found by any client:

LOG_ERR VirtualHere 2.8.4 caught signal 11 (Segmentation Fault) and must exit. Sorry... etc. Contact... etc
LOG_ERR Backtrace:
LOG_ERR ip=2123f0, sp=4036ab20
LOG_ERR ip=204678, sp=4036ae10
LOG_ERR End Backtrace

The DS then failed to reboot automatically - don't know what it was hanging on - so i pulled the plug.

Now, all is fine.

We're going to remove that particular Mac/Windows machine from the VH method, use physical dongles, and see how that goes. Unfortunately, we have 6 machines exactly the same on the domain without enough dongles to go round - hence VH!

Richard

#5

Actually that log is useful, what is shows is that there is a bug in the linux kernel of the DSM version that runs on that 216se. What is happening is that the kernel usb stack is crashing due to a bug in the kernel/usb host chipset and that then basically locks the USB bus. So im pretty sure that its not a client issue, but its a issue with the linux kernel on the server. The reason virtualhere gets a "segmentation fault" is because the DSM kernel is returning an invalid address with data in it, virtualhere doesnt know its invalid as it looks ok and tries to read it and then crashes.

Unfortunately my only advise is to mention this to synology and hopefully they can put a fix in for the usb host controller they use in their chips. The chip in that synology appears to be a marvell armada ARM processor. So basically the host controller that chip uses, i think musb, has the bug and that needs to be updated by synology.

(That synology appears to have only a usb 2.0 port so we cannot try replugging into a usb3.0 port (that uses a different driver in the kernel))

#6

...but, as per my additional thread where i've requested other VH users advise me of alternative (more reliable) NAS's, i'm not holding my breath!

I wrote to you a few months ago as we have a spare DS213+ in the office - it's a peculiar model, you suggested, as it uses a different chip set to most Synology's and therefore wasn't supported by VH. Looking at the list, I presume that's still the case...?

I'm really stuck here. I either wait for Synology and hope they improve the DSM or look elsewhere for a different NAS, get work to fork out for that and then another license!

Am I right in thinking the licenses aren't transferable if i did buy a new NAS?

Can I also check what NAS you use in your offices for testing? Are they required 24/7/365?

Thanks

Richard Blomley

#7

Yes you can transfer the license if you get another nas, email mail [at] virtualhere.com (mail[at]virtualhere[dot]com)

I test with these NAS's

Synology DS213j, ASUSTOR AS-202T, QNAP TS-120, Readynas 102.

I have a DLINK and THECUS but both are too unreliable to run virtualhere.