[RndTbl] Need help with serial connection

Daryl F wyatt at prairieturtle.ca
Sat May 28 11:58:39 CDT 2011

On Fri, 27 May 2011, Kevin McGregor wrote:

> Makes sense. I'll try it on Monday.
> On Fri, May 27, 2011 at 4:01 PM, Adam Thompson <athompso at athompso.net>wrote:
>> Usually it's the other way 'round, as the mgmt port is used for remote
>> "lights-out" installs.
>> You can connect to a virtual console port through the sun mgmt port, so you
>> should never need both.
>> Kevin McGregor <kevin.a.mcgregor at gmail.com> wrote:
>>> No frame buffer is present. I just want to manage the machine via serial
>>> port for now. You can't use the management port until you've installed the
>>> OS and configured it, is my understanding.

An installed OS is not needed to use a Remote System Control card (RSC) 
that runs the LOM firmware. It is a complete "computer" of its own with 
RAM/CPU/etc completely separated from the SPARC system itself. Note this a 
card. If you do have one the jacks will be in the card slots, not on the 
chassis of the server itself. If you think you do have an RSC, rscadm(1M) 
can be used from the Solaris host to manipulate it.

An RSC is not affected by rebooting the server through software or the 
hardware. It runs even when the server is powered off. A/C power must be 
removed on all chassis power supplies for at least 30 seconds to make it 
reset. rscadm can also reset it if you Solaris running.

The serial port is a different critter altogether. The boot PROM uses it 
during boot initialisation right up to the point where the loaded OS is 
given control. What happens then depends on the boot PROM settings. It may 
direct the console to the serial port or the framebuffer.

Any chance someone changed the boot PROM settings from factory default? It 
sounds like they've changed them to redirect the console to the 
framebuffer even if there isn't one installed. In that case you only see 
the hardware diagnostics, then when the loader passes control to the 
booting OS the console output may shifted to the framebuffer if the 
factory default has been changed.

>>> On Fri, May 27, 2011 at 2:28 PM, Adam Thompson <athompso at athompso.net
>>> wrote:
>>>> Not if there's a frame buffer installed.  And that sound like you're in
>> the
>>>> host serial port, not the management port.  Which do you want to be
>>>> connected to?
>>>> Kevin McGregor <kevin.a.mcgregor at gmail.com> wrote:
>>>>> Do I have the wrong cable? I think it's one of those ones used to
>> attach
>>>> to
>>>>> Cisco equipment, 9-pin RS-232 to RJ-45.
>>>>> I had it working, briefly, but it stopped again. I think it had booted
>>>> from
>>>>> the CD, and was pouring out messages about a buffer overflow plus a
>>>>> language-selection menu (repeatedly) as fast as 9600 bps would allow.
>> Then
>>>> I
>>>>> removed the CD and rebooted and now nothing. With a Sun Fire, shouldn't
>> I
>>>> be
>>>>> able to turn the front-panel switch to "Normal" and press the power
>>>> button?
>>>>> I did that, and I'm getting nothing on the serial interface. I should
>> be
>>>>> getting POST messages at least.

Cyan-colored Cisco cables don't work. The signal wires are not the 
same. They work for a bit but the first time the sending rate from the 
server gets too high the serial connection hangs.

You need a DB9-to-RJ45 adapter and a plain RJ-45 ribbon cable (not twisted 
pair -- it freaks out RS-232). I have a ton of them at work if you need 
one. Oracle (nee Sun) ships one with each server but we use only the 
network management port these days.

>>>>> On Fri, May 27, 2011 at 10:43 AM, Adam Thompson <athompso at athompso.net
>>>>> wrote:
>>>>>> Turn off hardware flow control (RTS/CTS or DTS/DSR) and use software
>>>> flow
>>>>>> control (XON/XOFF) instead.
>>>>>> Also, if you don't want to use minicom, (the modem AT initialization
>> is
>>>> a
>>>>>> pain to turn off completely) just use screen instead:
>>>>>> "screen /dev ttys0 9600"
>>>>>> -Adam
>>>>>> Kevin McGregor <kevin.a.mcgregor at gmail.com> wrote:
>>>>>>> This is driving me nuts, since it was working and now it isn't and I
>>>> have
>>>>>> no
>>>>>>> idea what has changed. I hope someone can help.
>>>>>>> I have a SunFire V490 at work. I also have a HP ProLiant server in
>> the
>>>>>> same
>>>>>>> rack, which is running Ubuntu Server 10.04. I've got the weird cyan
>>>> serial
>>>>>>> cable plugged in to the lone serial port on the ProLiant and the
>> other
>>>> end
>>>>>>> plugged into the V490 port ("SERIAL"). I've got minicom running on
>> the
>>>>>> Linux
>>>>>>> box configured for 9600, 8N1 on /dev/ttyS0. minicom's status line
>>>> reports
>>>>>>> "OFFLINE", and I get no response to any keyboard input.
>>>>>>> What's wrong? I can freely power off/on the SunFire and anything
>> else I
>>>>>> want
>>>>>>> to do with it. I have the keys for the front panel, too. Do I have
>> to
>>>>>> switch
>>>>>>> it to diagnostics mode or something? We had it working before, and
>> it
>>>> was
>>>>>>> quite easy.

Switching the key to diagnostics mode will only get you more diagnostics. 
Never run a production server in diagnostics mode. It greatly slows down 
system recovery in the event of a power outage/restoral. That assumes 
auto-boot? is set True in the boot PROM as it should be in a production 


More information about the Roundtable mailing list