Workstation console question

Workstation console question

Post by Jason Phane » Thu, 23 Jan 2003 17:56:16



I have a headless Ultra 5 that's running an application that hangs
just about everyday.  Even though I hate rebooting, I have to in order
to get it back in service. When I find the application in a hung
state, I truss the process and find that the last thing it did was
write to stderr.  So as an experiment, I rebooted the system, and let
the application come back up, and then cat a large file to
/dev/console (which is actually linked to iwscn) and the application
immediately hangs. If I redirect the same file to /dev/term/a, it
doesn't affect the app. So my guess is that the console device has
some kind of buffer that is getting filled up and never clears.

I have a feeling that replacing the hardware might resolve the
problem, but that bothers me because I thought the console device is
just a pseudo device and ttya is the actual physical device. On the
other hand, the system drive is a clone of another working system that
this doesn't happen to, which casts doubt in my mind that it's an OS
issue.

Here's my real question:  Does anyone know if the console device (or
the workstation console in this case) is actually related to physical
hardware that might cause something like this?

lrwxrwxrwx   1 root     other         29 Oct  7 18:26 /dev/console ->

# prtconf -F
Console output device is not a framebuffer

Thanks,
Jason Phaneuf

 
 
 

Workstation console question

Post by Casper H.S. Di » Thu, 23 Jan 2003 18:20:29



>I have a headless Ultra 5 that's running an application that hangs
>just about everyday.  Even though I hate rebooting, I have to in order
>to get it back in service. When I find the application in a hung
>state, I truss the process and find that the last thing it did was
>write to stderr.  So as an experiment, I rebooted the system, and let
>the application come back up, and then cat a large file to
>/dev/console (which is actually linked to iwscn) and the application
>immediately hangs. If I redirect the same file to /dev/term/a, it
>doesn't affect the app. So my guess is that the console device has
>some kind of buffer that is getting filled up and never clears.

What is /dev/term/a connected to?

Where does the output go?

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

Workstation console question

Post by Greg Andre » Fri, 24 Jan 2003 00:47:40



>So as an experiment, I rebooted the system, and let
>the application come back up, and then cat a large file to
>/dev/console (which is actually linked to iwscn) and the application
>immediately hangs. If I redirect the same file to /dev/term/a, it
>doesn't affect the app. So my guess is that the console device has
>some kind of buffer that is getting filled up and never clears.

What is the output of the command:  eeprom | grep ttya

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

 
 
 

Workstation console question

Post by Jason Phane » Fri, 24 Jan 2003 02:34:20




> >I have a headless Ultra 5 that's running an application that hangs
> >just about everyday.  Even though I hate rebooting, I have to in order
> >to get it back in service. When I find the application in a hung
> >state, I truss the process and find that the last thing it did was
> >write to stderr.  So as an experiment, I rebooted the system, and let
> >the application come back up, and then cat a large file to
> >/dev/console (which is actually linked to iwscn) and the application
> >immediately hangs. If I redirect the same file to /dev/term/a, it
> >doesn't affect the app. So my guess is that the console device has
> >some kind of buffer that is getting filled up and never clears.

> What is /dev/term/a connected to?

> Where does the output go?

> Casper

It's actually connected to a Cyclades ts2000 terminal server, but I'm
fairly certain the term server isn't the problem because of my testing
to /dev/term/a.

Jason

 
 
 

Workstation console question

Post by Jason Phane » Fri, 24 Jan 2003 04:01:56




> >So as an experiment, I rebooted the system, and let
> >the application come back up, and then cat a large file to
> >/dev/console (which is actually linked to iwscn) and the application
> >immediately hangs. If I redirect the same file to /dev/term/a, it
> >doesn't affect the app. So my guess is that the console device has
> >some kind of buffer that is getting filled up and never clears.

> What is the output of the command:  eeprom | grep ttya

>   -Greg

ttya-rts-dtr-off=false
ttya-ignore-cd=false
ttya-mode=9600,8,n,1,-

thanks,
Jason

 
 
 

Workstation console question

Post by Greg Andre » Fri, 24 Jan 2003 04:07:16






>> >So as an experiment, I rebooted the system, and let
>> >the application come back up, and then cat a large file to
>> >/dev/console (which is actually linked to iwscn) and the application
>> >immediately hangs. If I redirect the same file to /dev/term/a, it
>> >doesn't affect the app. So my guess is that the console device has
>> >some kind of buffer that is getting filled up and never clears.

>> What is the output of the command:  eeprom | grep ttya

>ttya-ignore-cd=false

Change that parameter to true, reboot, and see how it works.

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

 
 
 

Workstation console question

Post by ML Starke » Fri, 24 Jan 2003 22:55:38


Quote:> It's actually connected to a Cyclades ts2000 terminal server, but I'm
> fairly certain the term server isn't the problem because of my testing
> to /dev/term/a.

Serial ports have a very small buffers (64 characters if I'm reading the
man page correctly).  Terminal servers can be configured to buffer
information.  I took a quick peek at the manual for the TS series and
sure enough there is a whole section on "data buffering" starting on
page 110.

(ftp://ftp.cyclades.com/pub/cyclades/cyclades-ts/doc/TS134-1_Manual.pdf)

"fairly certain" the TS isn't the problem could be enough to trip you up
here.  To be absolutely certain, just take the TS2000 out of the picture
and see if the problem remains.

Also, you have checked to make sure you don't have any unnecessary port
monitors on serial port "a", right?  Just to be sure they aren't skewing
things.

 
 
 

Workstation console question

Post by Chris Newpor » Sat, 25 Jan 2003 04:03:59



> > It's actually connected to a Cyclades ts2000 terminal server, but I'm
> > fairly certain the term server isn't the problem because of my testing
> > to /dev/term/a.

> Serial ports have a very small buffers (64 characters if I'm reading the
> man page correctly).  Terminal servers can be configured to buffer
> information.  I took a quick peek at the manual for the TS series and
> sure enough there is a whole section on "data buffering" starting on
> page 110.

> (ftp://ftp.cyclades.com/pub/cyclades/cyclades-ts/doc/TS134-1_Manual.pdf)

> "fairly certain" the TS isn't the problem could be enough to trip you up
> here.  To be absolutely certain, just take the TS2000 out of the picture
> and see if the problem remains.

> Also, you have checked to make sure you don't have any unnecessary port
> monitors on serial port "a", right?  Just to be sure they aren't skewing
> things.

I have seen this problem before where the terminal server sends a flow
control signal to the console port because its buffer is full.
Until someone logs into the accesses this port on the terminal server
there is nowhere for the data to go.
When too many characters are queued up the port will freeze.
If you disable all flow control data will be lost but the port
will stop freezing. If you cannot set flow control to NONE a sneaky
workaround is to set flow control to RTS/CTS and use a 3 wire cable.
 
 
 

Workstation console question

Post by Jason Phane » Sat, 25 Jan 2003 04:47:25







> >> >So as an experiment, I rebooted the system, and let
> >> >the application come back up, and then cat a large file to
> >> >/dev/console (which is actually linked to iwscn) and the application
> >> >immediately hangs. If I redirect the same file to /dev/term/a, it
> >> >doesn't affect the app. So my guess is that the console device has
> >> >some kind of buffer that is getting filled up and never clears.

> >> What is the output of the command:  eeprom | grep ttya

> >ttya-ignore-cd=false

> Change that parameter to true, reboot, and see how it works.

>   -Greg

Thanks Greg, but that didn't do the trick.  Replacing the SPARC did
however, I checked to make sure the eeprom settings were the same as
before.  So this leads me to believe that there is some kind of
hardware associated with /dev/console that is separate from
/dev/term/a.  Remember, I only reproduced the problem when I
redirected the file to /dev/console, didn't happen when I redirected
it to /dev/term/a.  Doesn't make sense to me though.