We have Windows 10 machine connected to Sparc T5440 server via serial cable.
We access the server from the Windows 10 machine using putty via serial connection. This allows us to access ILOM and Unix.
We have recently noticed that whenever we reboot the windows machine (Windows 10), the Sparc server (connected from Windows machine via serial cable) goes to "continue, sync, reset" mode.
Does any know why this is the case? and how to prevent the unix server from getting into "continue, sync, reset" mode?
I suspect one of the serial data lines which Windows asserts when it opens a serial connection, possibly DTR. Is it possible to unplug the cable before you restart Windows?
Unfortunately we cannot disconnect the serial cable as we have these machines at a data center where we access them through secure vpn/remote desktop to the Windows machine.
After windows machine reboots, we would go into the Windows machine and putty to the Sparc server through serial connection. We see "continue, sync, reset" prompt.
Thanks for the suggestion.
You are getting "continue, sync, reset?" because the Solaris system has seen a 'break' signal. So, yes, this is caused by the cable you are using and perhaps it's not the correct one.
Anyway, the fact that this happens, what problem does it cause you? Surely you can still reconnect to Solaris? Or is it some automated process you are trying to run falls over?
Thank you all for the replies.
The sparc server is our production server and it impacts customers when it goes into "continue, sync, reset" mode as the server serving up the customer facing apps.
still trying to find the source ...
@jasonu.......I've read your last post and I must admit that I'm scratching my head on this one. IF you are indeed connected to the console port, sending a break (no matter how you do it, on purpose or by accident) should not bring down an up and running Solaris at this point. You should be able to '(c) continue' and recover from the break signal. So I don't know how it's bringing down Solaris, if that's what you're saying and I don't have a SPARC system here right now to try it.
@Solaris experts on here.....anybody know how this could happen please???
What Sparc hardware is it exactly?
---------- Post updated 01-10-16 at 10:18 AM ---------- Previous update was 30-09-16 at 06:15 PM ----------
It's also occurred to me that after entering (c) to continue you might be left connected to the ILOM/ALOM with a 'ok' prompt depending on exactly which SPARC machine this is.
So do note that a console terminal can talk to either the ILOM or the console (ie, the running operating system) on request.
If the console terminal is talking to the ILOM ('ok' prompt) and you want to talk to the main OS enter the command:
ok> console
If the console terminal is talking to the OS (Solaris) and you want to talk to the ILOM enter:
#.
Do understand that the console terminal can talk to either on demand.
Just a thought. Do let us all know how you get on.
Also, does the change documented by MadeInGermany in his post not stop the 'break' occurring at all?
The serial connection on newer Oralce/Sun hardware should only be used to configure the ILOM with an IP address. After that you should use SSH or https to connect to the ILOM through the netMgmt port! The serial line can still be used as a failsafe but should only be used with a terminal server.
The server is Sparc Enterprise T5440 running Solaris 10.
I have not had to reboot the windows machine since I posted. For now my solution is to avoid rebooting the windows machine. I will also look into setting up the management port, but if the existence of a serial connection (cable) itself somehow sends break signal to the server, it is a concern. I am also wondering if windows 10 somehow causes this (sends some signal to serial port during reboot).
The problem is,
a classic terminal, when it is in a classic terminal application, and when you reboot, still thinks that you are in the terminal application. And you have problems to run shell commands.
Therefore, the classic method is to send a break=reset during the serial port initialization (reboot) so the command line works again.
Unfortunately the Sun-Sparcs have implemented the break=reset to halt(pause) the OS. And another Sun-Sparc will not send a hardware-break signal.
Sun and partners offered serial cables where the hardware-break signal is not wired, for the case a non-Sparc device (Windows, or a serial Terminal Server) sends the classic break=reset signal.
So you could use such a cable, or use my suggested fix for the kbd driver, or use an ssh connection to the console port (from Windows e.g. via putty.exe).