[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Digi etherlite issue - i need feedback
We are going to need a console solution for some Solaris servers at
least into November, perhaps longer, preferably Sun break safe. That
said, how many units would have to be this way? Is it possible to only
have a couple of boxes of whichever option 1-3 is considered the most
viable? How many others have Solaris boxes remaining that won't be
decommissioned in the near future?
On Aug 29, 2005, at 5:13 PM, Marcus Watts wrote:
Date: Mon, 29 Aug 2005 12:53:17 -0400 (EDT)
From: Michael C Garrison <mcgarr@xxxxxxxxx>
Subject: Digi etherlite issue - i need feedback
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
At this point, Digi has admitted they are unable to fix sun break
with the Etherlite's. They've offered a few alternatives:
1) They can exchange the 32 port etherlites for 16 port TS Series.
units are sun break safe and provide a little more functionality than
2) They can exchange the 32 port Etherlites for their CM series,
an all in one solution. The downside to this is that we would have to
money to upgrade to these units.
3) Another solution would be to have them exchange our 32 ports for 16
ports and purchase the power adapter from ASP Technologies, which is
supposed to solve the issue.
4) We can just 'deal with it' and know that we can't unplug the units
sun hardware plugged in..
I require feedback so that we can figure out what route we should go
concerning this.. so please give me your feedback!
Of these choices, I think I'd pick 4. It's not clear to me if they're
proposing to halve the # of ports in this -- if not, I'd have to learn
more about those other two choices. But they are almost certainly
completely different beasts than the etherlites -- I believe they use
different rs-232 cabling, connectors, and the whole bit.
For option 4 - we're phasing the suns out. The Linux boxes, even
with sysrq, should not be as sensitive. This would be worth testing
out, but I believe if the linux boxes don't see an appropriate
ascii character in the right time frame after a break, they don't
do anything. I suppose we could also always rewrite the sysrq code to
use something other than break if that proved desirable.