Logged In: NO
Browser: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m18) Gecko/20001107 Netscape6/6.0
Kernel freeze with multiport serial card
Environment tested
------------------
Serial driver:
serial-5.05
Operating system:
RedHat 6.2 on kernel 2.2.16
RedHat 6.2 on kernel 2.4.0
PC-Hardware:
Siemens-Fujitsu Pentium III ~500 MHz
Unisys Pentium II ~266 MHz
Serial Card:
Exsys EX-4065A 8 serial RS-232 PCI Card 4 x 16C550
Chips with 16-Byte buffer
Tools:
setserial-2.17
Problem description
-------------------
We have all 8 serial lines, of the serial card,
connected to console ports
of remote VME crates, using 10m serial extension cables
(TP Typ 5).
<Serial Card>[]<fan-out>[]-------- TP Typ 5 (9m)
------[]<VME Crate>
| []-------- TP Typ 5 (9m)
------[]<VME Crate>
| []-------- TP Typ 5 (9m)
------[]<VME Crate>
| []-------- TP Typ 5 (9m)
------[]<VME Crate>
|
[]<fan-out>[]-------- TP Typ 5 (9m)
------[]<VME Crate>
[]-------- TP Typ 5 (9m)
------[]<VME Crate>
[]-------- TP Typ 5 (9m)
------[]<VME Crate>
[]-------- TP Typ 5 (9m)
------[]<VME Crate>
Things work fine if all the cables and extensions are
connected to the remote
devices.
However, if we disconnect one of the extension, at the
VME site, but leave the
same cable still connected to the fan-out cable, at the
serial card on the PC,
the kernel will deadly freeze when executing 'setserial
-a /dev/ttySn'.
<Serial Card>[]<fan-out>[]-------- TP Typ 5 (9m)
------[ ]<VME Crate>
If the cable extension is also disconnected, on the
fan-out cable, on the PC
site, executing 'setserial -a /dev/ttySn' works fine.
<Serial Card>[]<fan-out>[ ]-------- TP Typ 5 (9m)
------[]<VME Crate>
This happens on ports 2-8 on the EX-4065A 8 serial
card, but not on port 1.
The kernel doesn't write any panic to the console or to
a log file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This suspisciously sounds like a problem with unterminated
signals. If you ever have to disconnect one of the cables
from your device(s), attach a loopback device up to the
hanging line. Due to the cable length, density, and nature
of the signals, crosstalk is a very perplexing and real
threat to normal ops. Make sure you terminate both the
data, and modem control signals to ensure no extraneous
interrupt occur. The reason it only causes a problem on
ports 2-8, is because on port 1, more than likely, is the
ISP (Interrupt Status Port) within the SPR (Scratch Pad
Register) on the primary UART which in turn is *supposed*
to inform the driver as to which port is actually
generating the interrupt. Another possible problem which
could possibly be adding to this problem and causing a real
mess of a troubleshoot, is from what I noticed (or lack
there of) on your post, is that you didn't mention
the "^fourport autoconfig" in any of the setserial
information (which needs to be set for multiport stuff); as
well as the ISP masking information something similar
to "portX 0xYY maskZZ 0xAA matchZZ 0xAA" which (in most
cases) resides on the first UART-Port of the card. One
last thing, you need to make sure that your kernel config
has multiport boards and a few other things included in
there. Hope it helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
Browser: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m18) Gecko/20001107 Netscape6/6.0
Kernel freeze with multiport serial card
Environment tested
------------------
Serial driver:
serial-5.05
Operating system:
RedHat 6.2 on kernel 2.2.16
RedHat 6.2 on kernel 2.4.0
PC-Hardware:
Siemens-Fujitsu Pentium III ~500 MHz
Unisys Pentium II ~266 MHz
Serial Card:
Exsys EX-4065A 8 serial RS-232 PCI Card 4 x 16C550
Chips with 16-Byte buffer
Tools:
setserial-2.17
Problem description
-------------------
We have all 8 serial lines, of the serial card,
connected to console ports
of remote VME crates, using 10m serial extension cables
(TP Typ 5).
<Serial Card>[]<fan-out>[]-------- TP Typ 5 (9m)
------[]<VME Crate>
| []-------- TP Typ 5 (9m)
------[]<VME Crate>
| []-------- TP Typ 5 (9m)
------[]<VME Crate>
| []-------- TP Typ 5 (9m)
------[]<VME Crate>
|
[]<fan-out>[]-------- TP Typ 5 (9m)
------[]<VME Crate>
[]-------- TP Typ 5 (9m)
------[]<VME Crate>
[]-------- TP Typ 5 (9m)
------[]<VME Crate>
[]-------- TP Typ 5 (9m)
------[]<VME Crate>
Things work fine if all the cables and extensions are
connected to the remote
devices.
However, if we disconnect one of the extension, at the
VME site, but leave the
same cable still connected to the fan-out cable, at the
serial card on the PC,
the kernel will deadly freeze when executing 'setserial
-a /dev/ttySn'.
<Serial Card>[]<fan-out>[]-------- TP Typ 5 (9m)
------[ ]<VME Crate>
If the cable extension is also disconnected, on the
fan-out cable, on the PC
site, executing 'setserial -a /dev/ttySn' works fine.
<Serial Card>[]<fan-out>[ ]-------- TP Typ 5 (9m)
------[]<VME Crate>
This happens on ports 2-8 on the EX-4065A 8 serial
card, but not on port 1.
The kernel doesn't write any panic to the console or to
a log file.
Logged In: YES
user_id=91184
This suspisciously sounds like a problem with unterminated
signals. If you ever have to disconnect one of the cables
from your device(s), attach a loopback device up to the
hanging line. Due to the cable length, density, and nature
of the signals, crosstalk is a very perplexing and real
threat to normal ops. Make sure you terminate both the
data, and modem control signals to ensure no extraneous
interrupt occur. The reason it only causes a problem on
ports 2-8, is because on port 1, more than likely, is the
ISP (Interrupt Status Port) within the SPR (Scratch Pad
Register) on the primary UART which in turn is *supposed*
to inform the driver as to which port is actually
generating the interrupt. Another possible problem which
could possibly be adding to this problem and causing a real
mess of a troubleshoot, is from what I noticed (or lack
there of) on your post, is that you didn't mention
the "^fourport autoconfig" in any of the setserial
information (which needs to be set for multiport stuff); as
well as the ISP masking information something similar
to "portX 0xYY maskZZ 0xAA matchZZ 0xAA" which (in most
cases) resides on the first UART-Port of the card. One
last thing, you need to make sure that your kernel config
has multiport boards and a few other things included in
there. Hope it helps.