Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

problem with netra t 105 LOM

45 views
Skip to first unread message

Gorkhan

unread,
Apr 24, 2008, 12:45:12 PM4/24/08
to
I have a Netra T 105 that I am unable to login thru ttya (the LOM).
My keystrokes are ignored. I cannot access the LOM, nor can I do
anything at the "ok" prompt. This machine is the only "T 105" at my
disposal, so I do not have anything to compare it to.

We are running Solaris-9 on the affected box.

I have checked and rechecked my serial cables & adapters. If I tip
from another machine to the bad machine's ("baddog") ttya, then reboot
baddog, I see the expected traffic across the serial port, including
it prompting for a login at the end of the boot.

I added this entry into /etc/inittab:
conb:1234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` login: " -T
vt100 -d /dev/term/b -l contty -m ldterm,ttcompat

Logins to ttyb work just fine (using the same cables & adapters).

Thinking I was on to something, I added a similar line for /dev/term/
a.
No change.

If I tip from baddog out ttya, as in:

# tip -9600 /dev/term/a

On the machine I am tip'ing into I can do this:

# echo "HELLO" >> /dev/term/b

And I will see HELLO on baddog. I take this to mean that physically
the hardware is fine - it is capable of both sending and receiving
characters.

I then thought I could just use ttyb as the console, using "consadm".
No such luck, consadm reports that no carrier is present on ttyb, even
when I am logged in thru the port. Also, consadm refuses to accept
/dev/term/b in it's permanent list:

(s) root@nvsun3 [~] 531# consadm -a /dev/term/b -p
consadm: invalid device /dev/term/b
(s) root@nvsun3 [~] 532# consadm
(s) root@nvsun3 [~] 533# consadm -p

We are running the most current firmware for this model of LOM:

---

(s) root@nvsun3 [~] 528# lom -a
PSUs:
1 OK

Fans:
1 OK speed 92%
2 OK speed 95%
3 OK speed 100%
4 OK speed 100%

LOM configuration settings:
serial escape sequence=#.
serial event reporting=on
Event reporting level=fatal, warning & information
Serial security=enabled
Disable watchdog on break=disabled
Automatic return to console=disabled
alarm3 mode=user controlled
firmware version=3.14
firmware checksum=1190
product revision=0.1
product ID=Netra T1 200

LOM Event Log:
+326d+23h58m52s host reset
+333d+23h55m2s host reset
+340d+23h51m11s host reset
+347d+23h47m26s host reset
+354d+23h43m28s host reset
+361d+23h39m32s host reset
4/22/2008 21:29:21 GMT LOM time reference
+0h0m0s LOM reset
+0h0m0s host power on
4/22/2008 21:33:48 GMT LOM time reference

LOM alarm states:
Alarm1=off
Alarm2=off
Alarm3=on
Fault LED=off

LOM watchdog (ASR) settings:
Watchdog=off
Hardware reset=off
Timeout=127 s
Supply voltages:
1 5V status=ok
2 3V3 status=ok
3 +12V status=ok
4 -12V status=ok
5 CPU core status=ok
6 +3VSB status=ok

System status flags:
1 SCSI-Term status=ok
2 USB0 status=ok
3 USB1 status=ok
4 SCC status=ok

System Temperature Sensors:
1 Enclosure 36 degC : warning 67 degC : shutdown 72 degC
System Over-temperature Sensors:
1 CPU status=ok

Console output prior to last reset:
an't find host ntp2.usno.navy.mil
Apr 21 18:29:57 nvsun3 ntpdate[178]: can't find host
tick.usno.navy.mil
Apr 21 18:30:25 nvsun3 ntpdate[178]: can't find host
tock.usno.navy.mil
Apr 21 18:30:25 nvsun3 ntpdate[178]: no servers can be used, exiting

---

So I am stuck for an answer. Thanks in advance for any suggestions!

-smh

Wolfgang

unread,
Apr 24, 2008, 4:52:19 PM4/24/08
to
Gorkhan schrieb:

>
>
> So I am stuck for an answer. Thanks in advance for any suggestions!
>

what does eeprom show, are the console and keyboard settings correct? Do
you have a Framebuffer and Keybord connected or only serial?

W.

Gorkhan

unread,
Apr 24, 2008, 4:54:47 PM4/24/08
to

Thanks for responding!

Only serial.


(s) root@nvsun3 [~] 545# eeprom
ras-shutdown-enabled?=false
shutdown-temp=75
warning-temp=70
env-monitor=disabled
diag-passes=1
diag-continue?=0
diag-targets=0
diag-verbosity=0
keyboard-click?=false
keymap: data not available.
scsi-initiator-id=7
#power-cycles=0
system-board-serial#: data not available.
system-board-date: data not available.
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
pcia-probe-list=8,5,6,7
pcib-probe-list=7,c,3,d,5
mfg-mode=off
diag-level=min
fcode-debug?=false
output-device=ttya
input-device=ttya
load-base=16384
auto-boot-retry?=false
boot-command=boot
auto-boot?=true
watchdog-reboot?=false
diag-file: data not available.
diag-device=disk
boot-file: data not available.
boot-device=disk net
local-mac-address?=false
net-timeout=0
ansi-terminal?=true
screen-#columns=80
screen-#rows=34
silent-mode?=false
use-nvramrc?=false
nvramrc: data not available.
security-mode=none
security-password: data not available.
security-#badlogins=0
oem-logo: data not available.
oem-logo?=false
oem-banner: data not available.
oem-banner?=false
hardware-revision: data not available.
last-hardware-update: data not available.
diag-switch?=false

Greg Andrews

unread,
Apr 29, 2008, 9:37:51 AM4/29/08
to
Gorkhan <steveh...@gmail.com> writes:
>I have a Netra T 105 that I am unable to login thru ttya (the LOM).
>My keystrokes are ignored. I cannot access the LOM, nor can I do
>anything at the "ok" prompt. This machine is the only "T 105" at my
>disposal, so I do not have anything to compare it to.
>
[...]

>
>And I will see HELLO on baddog. I take this to mean that physically
>the hardware is fine - it is capable of both sending and receiving
>characters.
>

You've verified the hardware in all respects except for one: You
haven't verified that the circuitry that handles the receive pin
on ttya is working.

When I worked at Sun in the tech support group that handled serial
ports, we got a slow but steady trickle of calls where the console
serial port couldn't accept keystrokes because the circuitry on the
receive pin was burnt out by an overvoltage condition. The first
generation of servers with RJ45 serial ports (like your Netra t 105)
seemed to be more vulnerable to this kind of overvoltage than their
predecessors with DB25 serial ports.

The usual event that created the problem was connecting a device that
was plugged into a different power circuit than the server. Not just
any different power circuit, but one that somehow creates a voltage
difference between the server and the device you connect. A couple
of typical cases were a laptop plugged into a nearby wall outlet and
a server plugged into the rack power circuit, and two servers in
nearby racks but supplied by different power circuits. Connect the
serial ports together and the difference in voltage reference caused
the voltage applied to the receive pin to be 70, or 120, or even 200
volts rather than 5-25 volts. The result was a dead receive pin on
the console port, though all the other pins (transmit, control) were
fine.

That may have happened to your server.

-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.

0 new messages