The next listing, on a hung printer serial port;
The port has disappeared here, but is actually com3l. /dev/lp
is linked to /dev/com3l;
TTY PID PPID UID K F S EVENT COMMAND
null 1 0 root 20 4001 w init
------- 894 1 daemon 74 6001 S ttydrain sh
------- 1013 1 daemon 47 1 S pause lpsched
------- 1015 1013 daemon 47 1 S asyblk lpsched
------- 1025 1 root 20 1 S need CD init
again, some lines deleted, but the ones of interest left in.
Again, in the next listing;
TTY PID PPID UID K F S EVENT COMMAND
null 1 0 root 20 4001 w init
------- 894 1 daemon 74 6001 S ttydrain sh
------- 1013 1 daemon 47 1 S pause lpsched
------- 1025 1 root 20 1 S need CD init
------- 1038 1013 daemon 47 1 S asyblk lpsched
Does anyone know ;
a) what causes the com port to hang with the ttydrain event?
Which means you have to REBOOT to clear it. It also causes
damage to the root file system, in that some i-nodes are trashed.
b) what is 'need CD' telling me?
c) what is asyblk telling me?
d) Is it absolutly necessary for lpsched to be owned by daemon? which
makes it impossible to kill anything related to it, without a reset.
and other things that are related to this area of great moment and import!
I'd appreciate an answer onto this newsgroup if you know, as I am sure I
can't be the only one in the dark here. At least I hope not!
bob
--
____________________________________________________________________________
|Robert Chalmers. ,-._|\*<-Mackay rob...@nanguo.cstpl.com.au |
| / \ |
| \_.-\__/ *Auto-Info Server, in...@cstpl.com.au |
| v *Auto-Sales Server, sa...@cstpl.com.au|
|---------------------* ao zhong you yi wan sui *--------------------------|
Need carrier detect. the modems dcd line causes getty to be run
by init. This copy of init is wating for action on the modem.
>
> The next listing, on a hung printer serial port;
> The port has disappeared here, but is actually com3l. /dev/lp
> is linked to /dev/com3l;
>
> TTY PID PPID UID K F S EVENT COMMAND
> null 1 0 root 20 4001 w init
> ------- 894 1 daemon 74 6001 S ttydrain sh
> ------- 1013 1 daemon 47 1 S pause lpsched
> ------- 1015 1013 daemon 47 1 S asyblk lpsched
> ------- 1025 1 root 20 1 S need CD init
>
> again, some lines deleted, but the ones of interest left in.
>
> Again, in the next listing;
>
> TTY PID PPID UID K F S EVENT COMMAND
> null 1 0 root 20 4001 w init
> ------- 894 1 daemon 74 6001 S ttydrain sh
> ------- 1013 1 daemon 47 1 S pause lpsched
> ------- 1025 1 root 20 1 S need CD init
> ------- 1038 1013 daemon 47 1 S asyblk lpsched
>
>
> Does anyone know ;
> a) what causes the com port to hang with the ttydrain event?
> Which means you have to REBOOT to clear it. It also causes
> damage to the root file system, in that some i-nodes are trashed.
hmmm.... I sometimes get this ttydrain blockage as well. I haven't tracked
it down yet, but I figure it is probably the result of misconfigured
"stty" settings.
ttydrain sleep occurs in the tty driver not the asy driver. It
is a sleep that is done in order to allow all the characters to
be transmitted before the close is completed. It is not clear to
me exactly what occurance is supposed to awaken this sleep.
>
> b) what is 'need CD' telling me?
>
> c) what is asyblk telling me?
"asyblk" occurs when the asy driver sleeps in an open. According to
the comments it is supposed to happen if:
1. there is another process that is also trying to open
the port and awaiting CD;
2. another process is closing the port after loosing CD;
3. a remote process opened the port, spawned a daemon, and
disconnected, and the daemon ignored SIGHUP and is improperly
keeping the port open.
It should be noted that comments are not always accurate. They tend to
state the intention of a segment of code, and the result may not be
what was intended.
Do you have the printer port enabled for loggins? I am no expert on
printers and I can't imagine why a printer needs to watch for carrier
unless that is used in some crazy way for flow control, paper indication
or on-line indication.
>
> d) Is it absolutly necessary for lpsched to be owned by daemon? which
> makes it impossible to kill anything related to it, without a reset.
>
> and other things that are related to this area of great moment and import!
> I'd appreciate an answer onto this newsgroup if you know, as I am sure I
> can't be the only one in the dark here. At least I hope not!
>
Well, perhaps it is indeed possible that a previous close is
blocking the current open because the ttydrain is not being
awakened. If the beast is awaiting CD in order to continue
transmission.. hell might freeze over, etc.
In your ps readout, I wonder exactly what process 894 was
supposed to do have done?
--Randy
____________________________________________________________________________
r...@rwsys.wimsey.bc.ca (Randy Wright) (604) 581-0518
ICBM address = 49d 12m 5s N 122d 51m 49s W
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Init 'needs' the 'carrier detect' line before spawning a getty on the
com-port. If your modem rises CD, getty will invoke login...
> The next listing, on a hung printer serial port;
Sorry, I don't know it for sure but it seems that com3 is used in polled
mode and can't handle the data as fast as it arrives.
Michael
--
mic...@jester.GUN.de * Michael Gerhards * Voice: +49 2131 82238
-=> FreeBSD 1.0.2 <=- * Preussenstrasse 59 * Modem: +49 2131 80923
* Germany 41464 Neuss * Login guest, no passwd
If Xon/Xoff flow control (or hardware f/c for that matter) is in effect on
the port and the device goes down, the port may still have data to send to
the device, so it will wait for the data to 'drain' away.
> b) what is 'need CD' telling me?
It is waiting for Carrier Detect on the device before unblocking.
> c) what is asyblk telling me?
Hmm... not sure but would guess that the asy driver is in a blocked state.
> d) Is it absolutly necessary for lpsched to be owned by daemon? which
> makes it impossible to kill anything related to it, without a reset.
Sorry, I can't help on this one ....
Andrew MacIntyre
<and...@happy.dotc.gov.au>
These thoughts are mine alone ...