- This topic is empty.
28. August 2007 at 0:21 #577
Ok, we’re using the V50L in a windows 2003 environment using Terminal Services. Running dual screen also using the cable provided by Wyse and two identical monitors. We’re also running quite a range of Wyse terminals, mostly CE and XPe boxes (this is our first run on the Linux ones).
The problem is that every morning when a select group of users login to their terminals (V50L’s), mid way through the beginning of the RDP session (more often than not during the login script) the terminal will crash leaving the screens frozen. They do not unfreeze after any given amount of time. To make this even more frustrating the terminal I have been using in the IT office (same config, dhcp etc) works perfectly fine for me, never had any problems.
We have tried the following to no avail:
- New firmware upgrade from Wyse (still froze)
New RDP Add-On upgrade from Wyse (still froze)
Static Configuration (still froze)
Changed terminals (still froze)
Different users logging in (still froze)
Different times of the day (still froze)
Left Terminal on overnight (still froze)
Change of Power Supply (still froze)
Ran a full screen movie to test the GPU (ran fine)
Ran the login script + startup applications during a live session (no freeze)
My only remaining trials are trying a Static IP Address with a static config or run Linux in Desktop mode instead of CE and hope for a log file that contains something useful. Although currently the OS appears to crash, hitting the power button doesn’t bring up the normal dialog so I’m doubtful I’ll be able to view much once it freezes.
As I only have a few options left it is not looking good. We only purchased a small amount of terminals and are looking to soon buy quite a few more but at this rate I’m doubtful that will happen.
If you require any other details just mention them and I’ll fill you in.
Our config is as follows:
TimeZone="ACDT" ManualOverride=yes Daylight=yes
The configs are hosted on an ftp server, the logins work fine as do the configs (bar dmonitor not being configurable via a remote config file apparantly). I have sent our config to Wyse Support and they are unable to replicate our problem so can’t help us much.
Thanks in advance,
Michael.28. August 2007 at 1:47 #10061thinkthinMember
- Total Post: 1707
- Jacked into The Matrix
A few suggestions…
So some terminals work and some don’t, do they have the same level of firmware?
Also, can you check the BIOS version, hit the TAB key while the Wyse BIOS splash screen is up and you can see the version.
Also, are the units that are playing up all the same build date as the ones that are not (flip them over and the build date is on the back)
I am suspecting a memory issue here, post back what you find,
-TT28. August 2007 at 2:07 #10062
Firstly… I upgraded two of the terminals to the new firmware I got sent to me from Wyse. They are having identical problems to the ones that have the firmware they came with. Also one of these I used the new RDP update as well but still the same problem.
I have found another issue with the ones using the new firmware however, they remember all settings correctly except the DMonitor ones, always defaulting back to a cloned setup instead of the spanning as set manually via Control Panel but that is an entirely different issue which I should probably post seperately about.
Firmware Verison is 6.3.2 build 44
OS Version is 22.214.171.124
BIOS Version is 1.12.
Build date for all the terminals is Feb ’07.
I swapped the terminal I’ve been using for around a month with one of the ones being used by our records department… which was causing them grief. I’ve been using it for just over a week now with no issues at all and the terminal I had for a month with no issues, caused problems first try when it was used in records. Same monitors, same config, same IP range, dhcp, ftp server etc.
I’m going to try having a records person login here in the IT office tomorrow morning and see what happens there but I fail to see how it could make much of a difference. Getting rather confused as to what could be the issue now.
Michael.28. August 2007 at 2:14 #10063
Oh, I forgot to mention that the actual Terminal Services Session continues to load fine each time. It’s only the terminal itself that freezes. Once the client reboots and logs in again 9/10 they simply see their session as it should appear once they had logged in fine. A remote view of the session during the login process shows us that the session itself is fine the entire time also.
The problem seems to be following these users around, regardless of the terminal or the setup.28. August 2007 at 3:52 #10064thinkthinMember
- Total Post: 1707
- Jacked into The Matrix
OK, its very strange that is follows users. Check this:
– Log in from your office as you suggest, it will rule out network issues.
– Is there a specific app that to runs on log in?
– Is there any information in the windows event log?
In a case like this the next option is to get a copy of Ethereal (Wire Shark) and do a packet capture of the unit failing. You will need to mirror the port that the unit is plugged into.
Once you have this contact Wyse support again and they will be able to log a call. I know this is a pain but if the problem is not easily re-produced the packet capture should reveal whats going on.
Good luck, post back how you got on!
-TT28. August 2007 at 3:59 #10065
Thanks for the suggestion. I’ll test them logging in here in the office tomorrow morning and try wireshark/ethereal tomorrow hopefully.
Only applications that run during the login are the same as myself, our corporate software, in/out board and outlook. I don’t see how that could be a problem but I thought it’s worth a try anyway. I thought it could have perhaps even been a faulty switch port or something of the like but I swapped myself over to the same switch they’re on and moved one of the records staff to my old port on a seperate switch and still receiving the same issues for him, but nothing for me.
I’ll be sure to let you know of any progress.28. August 2007 at 4:28 #10067
Another quick update (sorry about the repeat posts).
Just had a user report a problem with their terminal, went to investigate (I turned on “notify on disconnect” for the RDP session this morning after it froze mid session – don’t ask why I didn’t have it already) … their terminal had disconnected and prompted to reconnect. I checked on terminal services and sure enough the user was marked as disconnected not just idle.
The mouse on the terminal was very laggy and wouldn’t let me bring up any of the control panel dialogs or system information, not even the prompt to shutdown/restart the terminal… memory issue?
This is the second time a user has been disconnected mid session and I’m now assuming they’re going to get the same error when they login tomorrow. To make things even more awkward to work out, he logged out, logged back in again and it all worked fine which is usually the case. We shall see what happens tomorrow morning…
If I get another disconnect mid session I think I’ll have to run a packet capture and hope it shows why its disconnecting.28. August 2007 at 14:20 #10078
Michael, try opening the BIOS by pressing Del at the beginning of the boot process. Password is “Fireport” (case-sensitive).
Go to Frequency/Voltage Control and adjust DRAM Clock to 200 MHz.
Save everthing and try again.29. August 2007 at 1:41 #10088
I tried one of the records staff here this morning in the IT office and same problem so I’m leaning toward something todo with the dual screen/GPU/memory perhaps.
I’ll try a single screen setup shortly and see how that goes, also I’ll change that BIOS setting on a terminal as well and get back to you.
Michael.29. August 2007 at 4:48 #10089
An update on something I tried. Using the terminal on a single monitor worked completely fine, as soon as a second monitor was introduced the terminal disconnected (froze) a couple of seconds after the RDP login.
A thought in my mind was perhaps the monitor resolution? The monitors we’re using run natively at 1280×1024 but we have to use them at 1024×768 for all clients (Yes the monitors do support that resolution but it isn’t it’s native res).
I’ll try out one of the terminals setup to run at 1280×1024 and see if the errors still occur and I’m yet to try changing the BIOS configuration as confgen suggested.
Is there a way I can use the resolution= setting in my wlx.ini to auto detect for the monitor it’s using, like resolution=DDC or something similar?29. August 2007 at 5:58 #10091
You should start using my tool to generate or look up parameters.
The parameter you are looking for is really “Resolution=DDC”
And again, try the BIOS setting. Believe me, its worth trying.29. August 2007 at 6:24 #10093
Thanks I will do… and I used your tool for our initial config but have since been making slight modifications without it based on the linux parameters pdf.29. August 2007 at 6:41 #10094
I changed the BIOS setting, it froze again once it rebooted (yes I did save it, even checked it again and the setting was correct).
I’ll be off work for the next 2 days but will post back once I’m back and have some more progress.
Thanks for your patience thus far,
Oh, and a side note: heard anything about if/when they might make DMonitor configurable via the wlx.ini?29. August 2007 at 7:34 #10095
The DMonitor parameters are available:
;* Display *
But they do not work on every firmware. I don’t know right out of my head which firmware is working. You may contact Wyse Support to get the right one.
ConfGen5. September 2007 at 1:38 #10138
I still havn’t had anymore luck on this issue on a whole. I’ve tried everything we’ve spoken about and more and can’t seem to even pinpoint what’s wrong let alone resolve it.
I’ve contacted Wyse about the firmware versions that support the DMonitor remote config and am yet to get a reply but thanks for the info.
We’re almost at the point now where we’re considering a different terminal as the issues we’ve had with these are more trouble than it’s worth…
- You must be logged in to reply to this topic.