[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Digi etherlite issue - i need feedback

> Date: Mon, 29 Aug 2005 12:53:17 -0400 (EDT)
> From: Michael C Garrison <mcgarr@xxxxxxxxx>
> X-X-Sender: mcgarr@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> To: umce.linux@xxxxxxxxx
> Subject: Digi etherlite issue - i need feedback
> Message-ID: <Pine.LNX.4.63.0508291252270.4230@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> At this point, Digi has admitted they are unable to fix sun break issue 
> with the Etherlite's. They've offered a few alternatives:
> 1) They can exchange the 32 port etherlites for 16 port TS Series. These 
> units are sun break safe and provide a little more functionality than the 
> etherlite 32's 
> (http://www.digi.com/products/terminalservers/portserverts816.jsp)
> 2) They can exchange the 32 port Etherlites for their CM series, which is 
> an all in one solution. The downside to this is that we would have to pay 
> 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 with 
> 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!
> --
> Mike Garrison

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.