Hi,
I was recently debugging a problem where one of the units we make was having
problems with one of its serial ports. /dev/ser2 has both incoming and
outgoing data, and is used for control of our product from certain control
systems. One process in our system handles incoming commands from the
serial port as well as ethernet connections.
Over time (approximately 10 days) that serial port became unusable. What we
noticed is commands being sent from an ethernet-based connection wouldn’t
produce any feedback. Being connected via telnet to the unit, we saw that
the process that handles these connections was Reply blocked on Dev. If I
“kill -SIGALRM” the process, the ethernet-based connections receive
feedback.
I wrote a quick test app to try to determine what was going on. I tried to
write() data out the serial port, but write never returned (my test app
becomes Reply blocked on Dev as well). The process that reads data from
that port never received any data from the connected device either.
Hardware and software flow control is disabled. DTR and RTS are not used
either (disabled with -D and -R options, they must be held low). We
configure the port with the following command:
I was looking for info as to what might cause a process to become reply
blocked on Dev. Specifically, what in a serial device may cause the driver
to become unresponsive?
I have also found some issues (similar) using the serial ports with the
standard Dev.ser driver. There seems to be a problem but not much help in
getting it resolved.
Hi,
I was recently debugging a problem where one of the units we make was
having
problems with one of its serial ports. /dev/ser2 has both incoming and
outgoing data, and is used for control of our product from certain control
systems. One process in our system handles incoming commands from the
serial port as well as ethernet connections.
Over time (approximately 10 days) that serial port became unusable. What
we
noticed is commands being sent from an ethernet-based connection wouldn’t
produce any feedback. Being connected via telnet to the unit, we saw that
the process that handles these connections was Reply blocked on Dev. If I
“kill -SIGALRM” the process, the ethernet-based connections receive
feedback.
I wrote a quick test app to try to determine what was going on. I tried
to
write() data out the serial port, but write never returned (my test app
becomes Reply blocked on Dev as well). The process that reads data from
that port never received any data from the connected device either.
Hardware and software flow control is disabled. DTR and RTS are not used
either (disabled with -D and -R options, they must be held low). We
configure the port with the following command:
I was looking for info as to what might cause a process to become reply
blocked on Dev. Specifically, what in a serial device may cause the
driver
to become unresponsive?
Are you using the integrated (onboad) serial port on your motherboard/SBC?
If so, what chipset?
I have seen this problem (or similar) and in the end the resolution was to
use a plug-in (PCI) serial port card (but still using standard Dev.ser to
drive it). In other words, the problem was not in Dev.ser but in the actual
hardware implementation of the onboard (integrated) serial port.
Of course we could never get anyone to acknowledge that there was a problem
in the chipset…
I have also found some issues (similar) using the serial ports with the
standard Dev.ser driver. There seems to be a problem but not much help in
getting it resolved.
Augie
“Ron Cococcia” <> ron.nospam@request.nospam.com> > wrote in message
news:becr9s$27e$> 1@inn.qnx.com> …
Hi,
I was recently debugging a problem where one of the units we make was
having
problems with one of its serial ports. /dev/ser2 has both incoming and
outgoing data, and is used for control of our product from certain
control
systems. One process in our system handles incoming commands from the
serial port as well as ethernet connections.
Over time (approximately 10 days) that serial port became unusable.
What
we
noticed is commands being sent from an ethernet-based connection
wouldn’t
produce any feedback. Being connected via telnet to the unit, we saw
that
the process that handles these connections was Reply blocked on Dev. If
I
“kill -SIGALRM” the process, the ethernet-based connections receive
feedback.
I wrote a quick test app to try to determine what was going on. I tried
to
write() data out the serial port, but write never returned (my test app
becomes Reply blocked on Dev as well). The process that reads data from
that port never received any data from the connected device either.
Hardware and software flow control is disabled. DTR and RTS are not
used
either (disabled with -D and -R options, they must be held low). We
configure the port with the following command:
I was looking for info as to what might cause a process to become reply
blocked on Dev. Specifically, what in a serial device may cause the
driver
to become unresponsive?
Hi,
I was recently debugging a problem where one of the units we make was
having
problems with one of its serial ports. /dev/ser2 has both incoming and
outgoing data, and is used for control of our product from certain control
systems. One process in our system handles incoming commands from the
serial port as well as ethernet connections.
Over time (approximately 10 days) that serial port became unusable. What
we
noticed is commands being sent from an ethernet-based connection wouldn’t
produce any feedback. Being connected via telnet to the unit, we saw that
the process that handles these connections was Reply blocked on Dev. If I
“kill -SIGALRM” the process, the ethernet-based connections receive
feedback.
I wrote a quick test app to try to determine what was going on. I tried
to
write() data out the serial port, but write never returned (my test app
becomes Reply blocked on Dev as well). The process that reads data from
that port never received any data from the connected device either.
Hardware and software flow control is disabled. DTR and RTS are not used
either (disabled with -D and -R options, they must be held low). We
configure the port with the following command:
I was looking for info as to what might cause a process to become reply
blocked on Dev. Specifically, what in a serial device may cause the
driver
to become unresponsive?
Yeah, we’ve been using that for a while. I just got patch G installed and
noticed that Dev32.ser had an update dealing with the -t option, I’ll be
running some tests with it to see if it helps.
One thing that might help is to play with the ‘-t’ option for Dev.ser (at
least in my case). Try using ‘-t1’.
Augie
“Ron Cococcia” <> ron.nospam@request.nospam.com> > wrote in message
news:becr9s$27e$> 1@inn.qnx.com> …
Hi,
I was recently debugging a problem where one of the units we make was
having
problems with one of its serial ports. /dev/ser2 has both incoming and
outgoing data, and is used for control of our product from certain
control
systems. One process in our system handles incoming commands from the
serial port as well as ethernet connections.
Over time (approximately 10 days) that serial port became unusable.
What
we
noticed is commands being sent from an ethernet-based connection
wouldn’t
produce any feedback. Being connected via telnet to the unit, we saw
that
the process that handles these connections was Reply blocked on Dev. If
I
“kill -SIGALRM” the process, the ethernet-based connections receive
feedback.
I wrote a quick test app to try to determine what was going on. I tried
to
write() data out the serial port, but write never returned (my test app
becomes Reply blocked on Dev as well). The process that reads data from
that port never received any data from the connected device either.
Hardware and software flow control is disabled. DTR and RTS are not
used
either (disabled with -D and -R options, they must be held low). We
configure the port with the following command:
I was looking for info as to what might cause a process to become reply
blocked on Dev. Specifically, what in a serial device may cause the
driver
to become unresponsive?