Ok. Below is my original question and original Summary.
After I thought I solved the problem I did discover something didn't
work right. And fixed it. My initial tests were faulty. I wasn't testing fully.
There did seem to be a problem with the 2.6 serial port driver and the Voyager.
Once I got the port working, I had tried the 2.6 drivers again. It actually
seemed like it was working but I was paying attention to what was going on. The
second I had sensed life from it with the 2.6 driver I thought, yah it works
too. And left it at that.
So the point of this SUMMARY 2 is to say I did need to use the 2.5.1
drivers. I just copied the following file from a similar machine(sun4m) with
2.5.1 installed. Rebooted and it works.
/platform/sun4m/kernel/drv/zs
Take care.
-grant
I was having trouble getting my serial port to work on a Voyager with 2.6.
Problem solved.
Thanks to:
Roger Fujii
Charlie Mnegler
Mark Hokkanen
David Evans
and especialy
Casper Dik, for some great commands that helped me figure things out.
Here was a simple way to test the problem. When I did a tip /dev/cua/a, it
would come back with an "All Ports Busy" message, and it wasn't busy, not
locked or anything.
Casper Dik pointed out that the had been a problem with the Solaris 2.6
zs driver on the Voyagers. So he had me try out the 2.5.1 version. This would
be the file /platform/sun4m/kernel/drv/zs To see what version your system is
using you can use the following command, note that patches may affect these.
modinfo | grep zs
4.116 is the 2.6 version
4.109 is the 2.5.1 version
This didn't seem to solve the problem.
I then did a bit more searching and came across SunSolve's Info Doc 13713. It
directed me to do the following.
1. I disabled the serial port monitor in Admintool(something I thought I
did before) and tested it.
No luck.
2. I then set the permissions that the article states.
chmod 666 /dev/cua/a
chown uucp /dev/cua/a
Still No Luck.
3. I then locked for the lock file, /var/spool/locks. Hey! There is one there.
cat'ed the lock file, and killed the process(I don't remeber now, I think it
was dtlogin.)
Tried my command again.
tip /dev/cua/a
and got a <connected>
Hooray!
I later tried going back to the 2.6 versions of the driver and it still
worked. I believe what seems to have been happening. Is that the port monitor
locks up the serial port. I could NOT get the serial port to work with that
port monitor on. If I disabled it, I would still have to go kill the process
that was in the lock file, just disabling the monitor would not allow me to use
it.
So I think the fix for others would be to go into admintool and disable
the port monitors, then, to make sure to delete the process that owns the lock
file. And it should all work great.
What I really don't know, is disabling the port in admintool will
affect. It seems to work fine for what we do. I did notice that on all the
other machines I tried SS5, SS20, Ultra2, Ultra60's that I could use the serial
port just fine with out having to disable the port monitor. A bug in the port
monitor I think?
-grant
-----original question------------------
We have an old Sparc Voyager that we used on site to log into a serial port on
another type of machine we design. The Voyager was running Solaris 2.4 and they
always just hooked up a serial cable in between the two machines, and logged
into this other machine from the Voyager.
We recently had to upgrade the Voyager to 2.6, and now they can no
longer log in. We put a breakout box on the serial port of the voyager, and it
looks like there is activity on the port when I am at the "new command line
mode". But as soon as I do a boot, at some point the activity on the port just
disappears. And we can no longer use it. I did a kill HUP -1 and the port was
active again.
I have the latest 2.6 patches on IT, and I did the patch 105924-08,
which a Sun Engineer thought would help. But nothing did.
I'm not anywhere near knowledgeable about serial port
communications. So
I don't know of good ways to test it, but the guys that work with the machine
tell me that they can't redirect anything to the port, and tip doesn't work on
it.
My idea is this, Solaris 2.6 doesn't automatic configuration of the
devices installed right? If they don't have something connected to the serial
port on boot up, is that why it is disabling the serial port? It seems to me
the serial port just gets shut off. I watch the breakout box on the boot of the
machine, and part way through the boot up(when its configuring devices) the
lights on the breakout box just shut off. Any ideas?
Thanks.
-grant
---------------------------------------------------------------------------
Grant Schoep, grant@storm.com
System/Network Administrator
L3 Communications Telemetry & Instrumentation
San Jose,CA (408)271-0800, Ext. 135
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:19 CDT