devc-ser8250 problem

[Brian Meinke]

While developing a devc driver, I encountered a little intermittent problem
with devc-ser8250 on 6.20A PE SMP(Dual 1.8 GHz Xeons, 512MB, 3COM 3C905C
NIC)

I am trying to develop a character driver for a multi-port VME Bus serial
board (NEC 7201 DUART) and have written a small test application which
simply writes a string out one serial port of the VME serial card and is
received on COM1 on a different computer. The VME based computer (PIII850
256 MB) running my devc driver (devc-mz8300) and the Dual Xeon box is simply
running devc-ser8250. Serial ports on both boxes set to 9600,N,8,1 raw with
no hardware/software handshaking (this is due to legacy configurations of
the VME serial board already being used in the field).

The problem I am seeing is that the Dual Xeon box stops
transmitting.receiving data after some random amount of time (anywhere from
5 minutes to several hours) and all network connections are lost (I have to
slay/restart io-net to access the network).

I have tried using the non-SMP kernel which only extends the amount of time
which passes before the problem occurs. I have disabled hyper-threading both
with and without the SMP kernel which seems to have a similar effect as
using the non-SMP kernel (more time passes before problem occurs).

I have attached the output from 'pci -v'. Any ideas are greatly appreciated.

TIA
Brian


begin 666 pci.txt
M"E!#22!V97)S:6]N(" @(#T@,BXQ, H*0VQA<W,@(" @(" @(" @/2!"<FED
M9V4@*$AO<W0O4$-)*0I696YD;W(@240@(" @(" ](#@P.#9H+"!);G1E;"!#
M;W)P;W)A=&EO;B *1&5V:6-E($E$(" @(" @/2 R-3,Q:"P@.#(X-C @2&]S
M="U(=6(@26YT97)F86-E7T$@0G)I9&=E("A$4"!M;V1E*0I00TD@:6YD97@@
M(" @(" ](#!H"D-L87-S($-O9&5S(" @(#T@,#8P,# P: I2979I<VEO;B!)
M1" @(" ](#1H"D)U<R!N=6UB97(@(" @(#T@, I$979I8V4@;G5M8F5R(" ]
M(# *1G5N8W1I;VX@;G5M(" @/2 P"E-T871U<R!296<@(" @(#T@83 Y,&@*
M0V]M;6%N9"!296<@(" @/2 Q,#9H"DAE861E<B!T>7!E(" @(#T@,&@@4VEN
M9VQE+69U;F-T:6]N"D))4U0@(" @(" @(" @(#T@,&@@0G5I;&0M:6XM<V5L
M9BUT97-T(&YO="!S=7!P;W)T960*3&%T96YC>2!4:6UE<B @/2 P: I#86-H
M92!,:6YE(%-I>F4](#!H( I3=6)S>7-T96T@5F5N9&]R($E$(#T@,3 R.&@*
M4W5B<WES=&5M($E$(" @(" @(" ](&0X: I-87@@3&%T(" @(" @(" ](#!N
M<PI-:6X@1VYT(" @(" @(" ](#!N<PI00TD@26YT(%!I;B @(" ]($Y#"DEN
M=&5R<G5P="!L:6YE(#T@, I#87!A8FEL:71I97,@4&]I;G1E<B ](&$P: I#
M87!A8FEL:71Y($E$(" @(" @(" ](#)H"D-A<&%B:6QI=&EE<R @(" @(" @
M(#T@,C!H("T@,68P,# R,3=H"@I#;&%S<R @(" @(" @(" ]($)R:61G92 H
M4$-)+U!#22D*5F5N9&]R($E$(" @(" @/2 X,#@V:"P@26YT96P@0V]R<&]R
M871I;VX@"D1E=FEC92!)1" @(" @(#T@,C4S,F@L(#@R.#4P+S@R.#8P($%'
M4"!"<FED9V4*4$-)(&EN9&5X(" @(" @/2 P: I#;&%S<R!#;V1E<R @(" ]
M(# V,#0P,&@*4F5V:7-I;VX@240@(" @/2 T: I"=7,@;G5M8F5R(" @(" ]
M(# *1&5V:6-E(&YU;6)E<B @/2 Q"D9U;F-T:6]N(&YU;2 @(#T@, I3=&%T
M=7,@4F5G(" @(" ](&$P: I#;VUM86YD(%)E9R @(" ](#$P-V@*2&5A9&5R
M('1Y<&4@(" @/2 Q:"!3:6YG;&4M9G5N8W1I;VX*0DE35" @(" @(" @(" @
M/2 P:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T('-U<'!O<G1E9 I,871E;F-Y
M(%1I;65R(" ](#0P: I#86-H92!,:6YE(%-I>F4](#!H( I0<FEM87)Y($)U
M<R!.=6UB97(@(" @(" @/2 P: I396-O;F1A<GD@0G5S($YU;6)E<B @(" @
M/2 Q: I3=6)O<F1I;F%T92!"=7,@3G5M8F5R(" @/2 Q: I396-O;F1A<GD@
M3&%T96YC>2!4:6UE<B @/2 T,&@*22]/($)A<V4@(" @(" @(" @(" @(" @
M(#T@93!H"DDO3R!,:6UI=" @(" @(" @(" @(" @(" ](&4P: I396-O;F1A
M<GD@4W1A='5S(" @(" @(" @/2 R,F$P: I-96UO<GD@0F%S92 @(" @(" @
M(" @(" @/2!F8S0P: I-96UO<GD@3&EM:70@(" @(" @(" @(" @/2!F8S4P
M: I0<F5F971C:&%B;&4@365M;W)Y($)A<V4@/2!E.# P: I0<F5F971C:&%B
M;&4@365M;W)Y($QI;6ET/2!E9F8P: I0<F5F971C:&%B;&4@0F%S92!5<'!E
M<B S,B!":71S(" ](#!H"E!R969E=&-H86)L92!,:6UI="!5<'!E<B S,B!"
M:71S(#T@,&@*22]/($)A<V4@57!P97(@,38@0FET<R @(#T@9F9F9F@*22]/
M($QI;6ET(%5P<&5R(#$V($)I=',@(#T@9F9F9F@*0G)I9&=E($-O;G1R;VP@
M(" @(" @(" @(#T@,31N<PI00TD@26YT(%!I;B @(" @(" @(" @(" @/2!.
M0PI);G1E<G)U<'0@;&EN92 @(" @(" @(" @/2 P"@I#;&%S<R @(" @(" @
M(" ]($)R:61G92 H4$-)+U!#22D*5F5N9&]R($E$(" @(" @/2 X,#@V:"P@
M26YT96P@0V]R<&]R871I;VX@"D1E=FEC92!)1" @(" @(#T@,C4S,V@L(#@R
M.#8P($AU8B!);G1E<F9A8V5?0B!"<FED9V4*4$-)(&EN9&5X(" @(" @/2 P
M: I#;&%S<R!#;V1E<R @(" ](# V,#0P,&@*4F5V:7-I;VX@240@(" @/2 T
M: I"=7,@;G5M8F5R(" @(" ](# *1&5V:6-E(&YU;6)E<B @/2 R"D9U;F-T
M:6]N(&YU;2 @(#T@, I3=&%T=7,@4F5G(" @(" ](&$P: I#;VUM86YD(%)E
M9R @(" ](#$P-V@*2&5A9&5R('1Y<&4@(" @/2 Q:"!3:6YG;&4M9G5N8W1I
M;VX*0DE35" @(" @(" @(" @/2 P:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T
M('-U<'!O<G1E9 I,871E;F-Y(%1I;65R(" ](#0P: I#86-H92!,:6YE(%-I
M>F4](#!H( I0<FEM87)Y($)U<R!.=6UB97(@(" @(" @/2 P: I396-O;F1A
M<GD@0G5S($YU;6)E<B @(" @/2 R: I3=6)O<F1I;F%T92!"=7,@3G5M8F5R
M(" @/2 S: I396-O;F1A<GD@3&%T96YC>2!4:6UE<B @/2 P: I)+T\@0F%S
M92 @(" @(" @(" @(" @(" @/2!F,&@*22]/($QI;6ET(" @(" @(" @(" @
M(" @(#T@,&@*4V5C;VYD87)Y(%-T871U<R @(" @(" @(#T@,C)A,&@*365M
M;W)Y($)A<V4@(" @(" @(" @(" @(#T@9F,Q,&@*365M;W)Y($QI;6ET(" @
M(" @(" @(" @(#T@9F,S,&@*4')E9F5T8VAA8FQE($UE;6]R>2!"87-E(#T@
M9F9F,&@*4')E9F5T8VAA8FQE($UE;6]R>2!,:6UI=#T@,&@*4')E9F5T8VAA
M8FQE($)A<V4@57!P97(@,S(@0FET<R @/2 P: I0<F5F971C:&%B;&4@3&EM
M:70@57!P97(@,S(@0FET<R ](#!H"DDO3R!"87-E(%5P<&5R(#$V($)I=',@
M(" ](&9F9F9H"DDO3R!,:6UI="!5<'!E<B Q-B!":71S(" ](&9F9F9H"D)R
M:61G92!#;VYT<F]L(" @(" @(" @(" ](#9N<PI00TD@26YT(%!I;B @(" @
M(" @(" @(" @/2!.0PI);G1E<G)U<'0@;&EN92 @(" @(" @(" @/2 P"@I#
M;&%S<R @(" @(" @(" ]($)R:61G92 H4$-)+U!#22D*5F5N9&]R($E$(" @
M(" @/2 X,#@V:"P@26YT96P@0V]R<&]R871I;VX@"D1E=FEC92!)1" @(" @
M(#T@,C0T96@L(#@R.# Q0D$O0T$@2'5B($EN=&5R9F%C92!T;R!00TD@0G)I
M9&=E"E!#22!I;F1E>" @(" @(#T@,&@*0VQA<W,@0V]D97,@(" @/2 P-C T
M,#!H"E)E=FES:6]N($E$(" @(#T@-&@*0G5S(&YU;6)E<B @(" @/2 P"D1E
M=FEC92!N=6UB97(@(#T@,S *1G5N8W1I;VX@;G5M(" @/2 P"E-T871U<R!2
M96<@(" @(#T@.#!H"D-O;6UA;F0@4F5G(" @(#T@,3 W: I(96%D97(@='EP
M92 @(" ](#%H(%-I;F=L92UF=6YC=&EO;@I"25-4(" @(" @(" @(" ](#!H
M($)U:6QD+6EN+7-E;&8M=&5S="!N;W0@<W5P<&]R=&5D"DQA=&5N8WD@5&EM
M97(@(#T@,&@*0V%C:&4@3&EN92!3:7IE/2 P:" *4')I;6%R>2!"=7,@3G5M
M8F5R(" @(" @(#T@,&@*4V5C;VYD87)Y($)U<R!.=6UB97(@(" @(#T@-&@*
M4W5B;W)D:6YA=&4@0G5S($YU;6)E<B @(#T@-&@*4V5C;VYD87)Y($QA=&5N
M8WD@5&EM97(@(#T@-#!H"DDO3R!"87-E(" @(" @(" @(" @(" @(" ](&0P
M: I)+T\@3&EM:70@(" @(" @(" @(" @(" @/2!D,&@*4V5C;VYD87)Y(%-T
M871U<R @(" @(" @(#T@,C(X,&@*365M;W)Y($)A<V4@(" @(" @(" @(" @
M(#T@9C0P,&@*365M;W)Y($QI;6ET(" @(" @(" @(" @(#T@9F)F,&@*4')E
M9F5T8VAA8FQE($UE;6]R>2!"87-E(#T@9F9F,&@*4')E9F5T8VAA8FQE($UE
M;6]R>2!,:6UI=#T@,&@*4')E9F5T8VAA8FQE($)A<V4@57!P97(@,S(@0FET
M<R @/2 P: I0<F5F971C:&%B;&4@3&EM:70@57!P97(@,S(@0FET<R ](#!H
M"DDO3R!"87-E(%5P<&5R(#$V($)I=',@(" ](&9F9F9H"DDO3R!,:6UI="!5
M<'!E<B Q-B!":71S(" ](&9F9F9H"D)R:61G92!#;VYT<F]L(" @(" @(" @
M(" ](#9N<PI00TD@26YT(%!I;B @(" @(" @(" @(" @/2!.0PI);G1E<G)U
M<'0@;&EN92 @(" @(" @(" @/2 P"@I#;&%S<R @(" @(" @(" ]($)R:61G
M92 H4$-)+TE302D*5F5N9&]R($E$(" @(" @/2 X,#@V:"P@26YT96P@0V]R
M<&]R871I;VX@"D1E=FEC92!)1" @(" @(#T@,C0T,&@L(#@R.# Q0D$@3%!#
M($EN=&5R9F%C92!"<FED9V4L($E#2#(*4$-)(&EN9&5X(" @(" @/2 P: I#
M;&%S<R!#;V1E<R @(" ](# V,#$P,&@*4F5V:7-I;VX@240@(" @/2 T: I"
M=7,@;G5M8F5R(" @(" ](# *1&5V:6-E(&YU;6)E<B @/2 S,0I&=6YC=&EO
M;B!N=6T@(" ](# *4W1A='5S(%)E9R @(" @/2 R.#!H"D-O;6UA;F0@4F5G
M(" @(#T@9F@*2&5A9&5R('1Y<&4@(" @/2 P:"!-=6QT:2UF=6YC=&EO;@I"
M25-4(" @(" @(" @(" ](#!H($)U:6QD+6EN+7-E;&8M=&5S="!N;W0@<W5P
M<&]R=&5D"DQA=&5N8WD@5&EM97(@(#T@,&@*0V%C:&4@3&EN92!3:7IE/2 P
M:" *36%X($QA=" @(" @(" @/2 P;G,*36EN($=N=" @(" @(" @/2 P;G,*
M4$-)($EN="!0:6X@(" @/2!.0PI);G1E<G)U<'0@;&EN92 ](# *"D-L87-S
M(" @(" @(" @(#T@36%S<R!3=&]R86=E("A)1$4I"E9E;F1O<B!)1" @(" @
M(#T@.# X-F@L($EN=&5L($-O<G!O<F%T:6]N( I$979I8V4@240@(" @(" ]
M(#(T-&)H+" X,C@P,4)!($E$12!#;VYT<F]L;&5R"E!#22!I;F1E>" @(" @
M(#T@,&@*0VQA<W,@0V]D97,@(" @/2 P,3 Q.#!H"E)E=FES:6]N($E$(" @
M(#T@-&@*0G5S(&YU;6)E<B @(" @/2 P"D1E=FEC92!N=6UB97(@(#T@,S$*
M1G5N8W1I;VX@;G5M(" @/2 Q"E-T871U<R!296<@(" @(#T@,C@P: I#;VUM
M86YD(%)E9R @(" ](#5H"DAE861E<B!T>7!E(" @(#T@,&@@4VEN9VQE+69U
M;F-T:6]N"D))4U0@(" @(" @(" @(#T@,&@@0G5I;&0M:6XM<V5L9BUT97-T
M(&YO="!S=7!P;W)T960*3&%T96YC>2!4:6UE<B @/2 P: I#86-H92!,:6YE
M(%-I>F4](#!H( I00TD@24\@061D<F5S<R @/2!F9F$P:"!L96YG=&@@,38@
M96YA8FQE9 I3=6)S>7-T96T@5F5N9&]R($E$(#T@,3 R.&@*4W5B<WES=&5M
M($E$(" @(" @(" ](&0X: I-87@@3&%T(" @(" @(" ](#!N<PI-:6X@1VYT
M(" @(" @(" ](#!N<PI00TD@26YT(%!I;B @(" ]($Y#"DEN=&5R<G5P="!L
M:6YE(#T@, H*0VQA<W,@(" @(" @(" @/2!397)I86P@0G5S("A5;FEV97)S
M86P@4V5R:6%L($)U<RD*5F5N9&]R($E$(" @(" @/2 X,#@V:"P@26YT96P@
M0V]R<&]R871I;VX@"D1E=FEC92!)1" @(" @(#T@,C0T,F@L(#@R.# Q0D$O
M0D%-(%530B!#;VYT<F]L;&5R+"!54T(M00I00TD@:6YD97@@(" @(" ](#!H
M"D-L87-S($-O9&5S(" @(#T@,&,P,S P: I2979I<VEO;B!)1" @(" ](#1H
M"D)U<R!N=6UB97(@(" @(#T@, I$979I8V4@;G5M8F5R(" ](#,Q"D9U;F-T
M:6]N(&YU;2 @(#T@,@I3=&%T=7,@4F5G(" @(" ](#(X,&@*0V]M;6%N9"!2
M96<@(" @/2 T: I(96%D97(@='EP92 @(" ](#!H(%-I;F=L92UF=6YC=&EO
M;@I"25-4(" @(" @(" @(" ](#!H($)U:6QD+6EN+7-E;&8M=&5S="!N;W0@
M<W5P<&]R=&5D"DQA=&5N8WD@5&EM97(@(#T@,&@*0V%C:&4@3&EN92!3:7IE
M/2 P:" *4$-)($E/($%D9')E<W,@(#T@,&@@;&5N9W1H(#,R(&1I<V%B;&5D
M"E-U8G-Y<W1E;2!696YD;W(@240@/2 Q,#(X: I3=6)S>7-T96T@240@(" @
M(" @(#T@9#AH"DUA>"!,870@(" @(" @(#T@,&YS"DUI;B!';G0@(" @(" @
M(#T@,&YS"E!#22!);G0@4&EN(" @(#T@24Y4($0*26YT97)R=7!T(&QI;F4@
M/2 Q,0H*0VQA<W,@(" @(" @(" @/2!397)I86P@0G5S("A334)U<RD*5F5N
M9&]R($E$(" @(" @/2 X,#@V:"P@26YT96P@0V]R<&]R871I;VX@"D1E=FEC
M92!)1" @(" @(#T@,C0T,V@L(#@R.# Q0D$O0D%-(%--0G5S($-O;G1R;VQL
M97(*4$-)(&EN9&5X(" @(" @/2 P: I#;&%S<R!#;V1E<R @(" ](#!C,#4P
M,&@*4F5V:7-I;VX@240@(" @/2 T: I"=7,@;G5M8F5R(" @(" ](# *1&5V
M:6-E(&YU;6)E<B @/2 S,0I&=6YC=&EO;B!N=6T@(" ](#,*4W1A='5S(%)E
M9R @(" @/2 R.#!H"D-O;6UA;F0@4F5G(" @(#T@,6@*2&5A9&5R('1Y<&4@
M(" @/2 P:"!3:6YG;&4M9G5N8W1I;VX*0DE35" @(" @(" @(" @/2 P:"!"
M=6EL9"UI;BUS96QF+71E<W0@;F]T('-U<'!O<G1E9 I,871E;F-Y(%1I;65R
M(" ](#!H"D-A8VAE($QI;F4@4VEZ93T@,&@@"E!#22!)3R!!9&1R97-S(" ]
M(&-C9#!H(&QE;F=T:" Q-B!E;F%B;&5D"E-U8G-Y<W1E;2!696YD;W(@240@
M/2 Q,#(X: I3=6)S>7-T96T@240@(" @(" @(#T@9#AH"DUA>"!,870@(" @
M(" @(#T@,&YS"DUI;B!';G0@(" @(" @(#T@,&YS"E!#22!);G0@4&EN(" @
M(#T@24Y4($(*26YT97)R=7!T(&QI;F4@/2 Q, H*0VQA<W,@(" @(" @(" @
M/2!397)I86P@0G5S("A5;FEV97)S86P@4V5R:6%L($)U<RD*5F5N9&]R($E$
M(" @(" @/2 X,#@V:"P@26YT96P@0V]R<&]R871I;VX@"D1E=FEC92!)1" @
M(" @(#T@,C0T-&@L(#@R.# Q0D$O0D%-(%530B!#;VYT<F]L;&5R+"!54T(M
M0@I00TD@:6YD97@@(" @(" ](#!H"D-L87-S($-O9&5S(" @(#T@,&,P,S P
M: I2979I<VEO;B!)1" @(" ](#1H"D)U<R!N=6UB97(@(" @(#T@, I$979I
M8V4@;G5M8F5R(" ](#,Q"D9U;F-T:6]N(&YU;2 @(#T@- I3=&%T=7,@4F5G
M(" @(" ](#(X,&@*0V]M;6%N9"!296<@(" @/2 T: I(96%D97(@='EP92 @
M(" ](#!H(%-I;F=L92UF=6YC=&EO;@I"25-4(" @(" @(" @(" ](#!H($)U
M:6QD+6EN+7-E;&8M=&5S="!N;W0@<W5P<&]R=&5D"DQA=&5N8WD@5&EM97(@
M(#T@,&@*0V%C:&4@3&EN92!3:7IE/2 P:" *4$-)($E/($%D9')E<W,@(#T@
M,&@@;&5N9W1H(#,R(&1I<V%B;&5D"E-U8G-Y<W1E;2!696YD;W(@240@/2 Q
M,#(X: I3=6)S>7-T96T@240@(" @(" @(#T@9#AH"DUA>"!,870@(" @(" @
M(#T@,&YS"DUI;B!';G0@(" @(" @(#T@,&YS"E!#22!);G0@4&EN(" @(#T@
M24Y4($,*26YT97)R=7!T(&QI;F4@/2 Y"@I#;&%S<R @(" @(" @(" ]($UU
M;'1I;65D:6$@*$%U9&EO*0I696YD;W(@240@(" @(" ](#@P.#9H+"!);G1E
M;"!#;W)P;W)A=&EO;B *1&5V:6-E($E$(" @(" @/2 R-#0U:"P@.#(X,#%"
M02]"04T@04,Y-R!!=61I;R!#;VYT<F]L;&5R"E!#22!I;F1E>" @(" @(#T@
M,&@*0VQA<W,@0V]D97,@(" @/2 P-# Q,#!H"E)E=FES:6]N($E$(" @(#T@
M-&@*0G5S(&YU;6)E<B @(" @/2 P"D1E=FEC92!N=6UB97(@(#T@,S$*1G5N
M8W1I;VX@;G5M(" @/2 U"E-T871U<R!296<@(" @(#T@,C@P: I#;VUM86YD
M(%)E9R @(" ](#5H"DAE861E<B!T>7!E(" @(#T@,&@@4VEN9VQE+69U;F-T
M:6]N"D))4U0@(" @(" @(" @(#T@,&@@0G5I;&0M:6XM<V5L9BUT97-T(&YO
M="!S=7!P;W)T960*3&%T96YC>2!4:6UE<B @/2 P: I#86-H92!,:6YE(%-I
M>F4](#!H( I00TD@24\@061D<F5S<R @/2!C.# P:"!L96YG=&@@,C4V(&5N
M86)L960*4$-)($E/($%D9')E<W,@(#T@8V,T,&@@;&5N9W1H(#8T(&5N86)L
M960*4W5B<WES=&5M(%9E;F1O<B!)1" ](#$P,CAH"E-U8G-Y<W1E;2!)1" @
M(" @(" @/2!D.&@*36%X($QA=" @(" @(" @/2 P;G,*36EN($=N=" @(" @
M(" @/2 P;G,*4$-)($EN="!0:6X@(" @/2!)3E0@0@I);G1E<G)U<'0@;&EN
M92 ](#$P"@I#;&%S<R @(" @(" @(" ]($1I<W!L87D@*%9'02D*5F5N9&]R
M($E$(" @(" @/2 Q,# R:"P@051)(%1E8VAN;VQO9VEE<R *1&5V:6-E($E$
M(" @(" @/2 U,34Y:"P@4F%D96]N(%9%( I00TD@:6YD97@@(" @(" ](#!H
M"D-L87-S($-O9&5S(" @(#T@,#,P,# P: I2979I<VEO;B!)1" @(" ](#!H
M"D)U<R!N=6UB97(@(" @(#T@,0I$979I8V4@;G5M8F5R(" ](# *1G5N8W1I
M;VX@;G5M(" @/2 P"E-T871U<R!296<@(" @(#T@,F(P: I#;VUM86YD(%)E
M9R @(" ](#$X-V@*2&5A9&5R('1Y<&4@(" @/2 P:"!3:6YG;&4M9G5N8W1I
M;VX*0DE35" @(" @(" @(" @/2 P:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T
M('-U<'!O<G1E9 I,871E;F-Y(%1I;65R(" ](#0P: I#86-H92!,:6YE(%-I
M>F4](#$P:"!U;BUC86-H96%B;&4*4$-)($UE;2!!9&1R97-S(#T@93@P,# P
M,#!H('!R969E=&-H86)L92 S,F)I="!L96YG=&@@,3,T,C$W-S(X(&5N86)L
M960*4$-)($E/($%D9')E<W,@(#T@96,P,&@@;&5N9W1H(#(U-B!E;F%B;&5D
M"E!#22!-96T@061D<F5S<R ](&9C-&8P,# P:" S,F)I="!L96YG=&@@-C4U
M,S8@96YA8FQE9 I3=6)S>7-T96T@5F5N9&]R($E$(#T@,3 P,F@*4W5B<WES
M=&5M($E$(" @(" @(" ](#%B.&%H"E!#22!%>'!A;G-I;VX@4D]-(#T@8S$P
M,# P,#!H(&QE;F=T:" Q,S$P-S(@9&ES86)L960*36%X($QA=" @(" @(" @
M/2 P;G,*36EN($=N=" @(" @(" @/2 X;G,*4$-)($EN="!0:6X@(" @/2!)
M3E0@00I);G1E<G)U<'0@;&EN92 ](#$Q"D-A<&%B:6QI=&EE<R!0;VEN=&5R
M(#T@-3AH"D-A<&%B:6QI='D@240@(" @(" @(#T@,F@*0V%P86)I;&ET:65S
M(" @(" @(" @/2 R,&@@+2 R9C P,#(P-V@*0V%P86)I;&ET>2!)1" @(" @
M(" @/2 Q: I#87!A8FEL:71I97,@(" @(" @(" ](#8P,F@@+2 P: H*0VQA
M<W,@(" @(" @(" @/2!"<FED9V4@*%!#22]00TDI"E9E;F1O<B!)1" @(" @
M(#T@.# X-F@L($EN=&5L($-O<G!O<F%T:6]N( I$979I8V4@240@(" @(" ]
M(#$S-C!H+" X,C@P-D%!($AU8B!);G1E<F9A8V4@=&\@4$-)($)R:61G90I0
M0TD@:6YD97@@(" @(" ](#!H"D-L87-S($-O9&5S(" @(#T@,#8P-# P: I2
M979I<VEO;B!)1" @(" ](#-H"D)U<R!N=6UB97(@(" @(#T@,@I$979I8V4@
M;G5M8F5R(" ](#,Q"D9U;F-T:6]N(&YU;2 @(#T@, I3=&%T=7,@4F5G(" @
M(" ](#(P: I#;VUM86YD(%)E9R @(" ](#$P-V@*2&5A9&5R('1Y<&4@(" @
M/2 Q:"!3:6YG;&4M9G5N8W1I;VX*0DE35" @(" @(" @(" @/2 P:"!"=6EL
M9"UI;BUS96QF+71E<W0@;F]T('-U<'!O<G1E9 I,871E;F-Y(%1I;65R(" ]
M(#!H"D-A8VAE($QI;F4@4VEZ93T@,&@@"E!R:6UA<GD@0G5S($YU;6)E<B @
M(" @(" ](#)H"E-E8V]N9&%R>2!"=7,@3G5M8F5R(" @(" ](#-H"E-U8F]R
M9&EN871E($)U<R!.=6UB97(@(" ](#-H"E-E8V]N9&%R>2!,871E;F-Y(%1I
M;65R(" ](#0P: I)+T\@0F%S92 @(" @(" @(" @(" @(" @/2!F,&@*22]/
M($QI;6ET(" @(" @(" @(" @(" @(#T@,&@*4V5C;VYD87)Y(%-T871U<R @
M(" @(" @(#T@,C)A,&@*365M;W)Y($)A<V4@(" @(" @(" @(" @(#T@9F,R
M,&@*365M;W)Y($QI;6ET(" @(" @(" @(" @(#T@9F,S,&@*4')E9F5T8VAA
M8FQE($UE;6]R>2!"87-E(#T@9F9F,&@*4')E9F5T8VAA8FQE($UE;6]R>2!,
M:6UI=#T@,&@*4')E9F5T8VAA8FQE($)A<V4@57!P97(@,S(@0FET<R @/2 P
M: I0<F5F971C:&%B;&4@3&EM:70@57!P97(@,S(@0FET<R ](#!H"DDO3R!"
M87-E(%5P<&5R(#$V($)I=',@(" ](&9F9F9H"DDO3R!,:6UI="!5<'!E<B Q
M-B!":71S(" ](&9F9F9H"D)R:61G92!#;VYT<F]L(" @(" @(" @(" ](#,R
M-S<T;G,*4$-)($EN="!0:6X@(" @(" @(" @(" @(#T@3D,*26YT97)R=7!T
M(&QI;F4@(" @(" @(" @(#T@, H*0VQA<W,@(" @(" @(" @/2!3>7-T96T@
M4&5R:7!H97)A;',@*%!)0RD*5F5N9&]R($E$(" @(" @/2 X,#@V:"P@26YT
M96P@0V]R<&]R871I;VX@"D1E=FEC92!)1" @(" @(#T@,3$V,6@L(#@R.# V
M04$@22]/($%024,@1&5V:6-E"E!#22!I;F1E>" @(" @(#T@,&@*0VQA<W,@
M0V]D97,@(" @/2 P.# P,C!H"E)E=FES:6]N($E$(" @(#T@,6@*0G5S(&YU
M;6)E<B @(" @/2 S"D1E=FEC92!N=6UB97(@(#T@, I&=6YC=&EO;B!N=6T@
M(" ](# *4W1A='5S(%)E9R @(" @/2 P: I#;VUM86YD(%)E9R @(" ](#!H
M"DAE861E<B!T>7!E(" @(#T@,&@@375L=&DM9G5N8W1I;VX*0DE35" @(" @
M(" @(" @/2 P:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T('-U<'!O<G1E9 I,
M871E;F-Y(%1I;65R(" ](#!H"D-A8VAE($QI;F4@4VEZ93T@,&@@"E-U8G-Y
M<W1E;2!696YD;W(@240@/2 X,#@V: I3=6)S>7-T96T@240@(" @(" @(#T@
M,3$V,6@*36%X($QA=" @(" @(" @/2 P;G,*36EN($=N=" @(" @(" @/2 P
M;G,*4$-)($EN="!0:6X@(" @/2!.0PI);G1E<G)U<'0@;&EN92 ](# *"D-L
M87-S(" @(" @(" @(#T@3F5T=V]R:R H171H97)N970I"E9E;F1O<B!)1" @
M(" @(#T@,3!B-V@L(#-#;VT@0V]R<&]R871I;VX@"D1E=FEC92!)1" @(" @
M(#T@.3(P,&@L(#-#.3 U0RU46"!&87-T($5T:&5R3&EN:R!F;W(@4$,@36%N
M86=E;65N="!.24,*4$-)(&EN9&5X(" @(" @/2 P: I#;&%S<R!#;V1E<R @
M(" ](# R,# P,&@*4F5V:7-I;VX@240@(" @/2 W.&@*0G5S(&YU;6)E<B @
M(" @/2 T"D1E=FEC92!N=6UB97(@(#T@,3$*1G5N8W1I;VX@;G5M(" @/2 P
M"E-T871U<R!296<@(" @(#T@,C$P: I#;VUM86YD(%)E9R @(" ](#$Q-V@*
M2&5A9&5R('1Y<&4@(" @/2 P:"!3:6YG;&4M9G5N8W1I;VX*0DE35" @(" @
M(" @(" @/2 P:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T('-U<'!O<G1E9 I,
M871E;F-Y(%1I;65R(" ](#0P: I#86-H92!,:6YE(%-I>F4](#$P:"!U;BUC
M86-H96%B;&4*4$-)($E/($%D9')E<W,@(#T@9&,X,&@@;&5N9W1H(#$R."!E
M;F%B;&5D"E!#22!-96T@061D<F5S<R ](&9B969F8S P:" S,F)I="!L96YG
M=&@@,3(X(&5N86)L960*4W5B<WES=&5M(%9E;F1O<B!)1" ](#$P,CAH"E-U
M8G-Y<W1E;2!)1" @(" @(" @/2!D.&@*4$-)($5X<&%N<VEO;B!23TT@/2!F
M8F8P,# P,&@@;&5N9W1H(#$S,3 W,B!D:7-A8FQE9 I-87@@3&%T(" @(" @
M(" ](#$P;G,*36EN($=N=" @(" @(" @/2 Q,&YS"E!#22!);G0@4&EN(" @
M(#T@24Y4($$*26YT97)R=7!T(&QI;F4@/2 Y"D-A<&%B:6QI=&EE<R!0;VEN
M=&5R(#T@9&-H"D-A<&%B:6QI='D@240@(" @(" @(#T@,6@*0V%P86)I;&ET
M:65S(" @(" @(" @/2!F93 R:" M(#8X,# T,3 P: H*0VQA<W,@(" @(" @
M(" @/2!397)I86P@0G5S("A&:7)E5VER92D*5F5N9&]R($E$(" @(" @/2 Q
M,#1C:"P@5&5X87,@26YS=')U;65N=',@"D1E=FEC92!)1" @(" @(#T@.# R
M,&@L(%130C$R3%8R-B!/2$-)+4QY;G@@4$-)($E%144@,3,Y-"!(;W-T($-O
M;G1R;VQL97(*4$-)(&EN9&5X(" @(" @/2 P: I#;&%S<R!#;V1E<R @(" ]
M(#!C,# Q,&@*4F5V:7-I;VX@240@(" @/2 P: I"=7,@;G5M8F5R(" @(" ]
M(#0*1&5V:6-E(&YU;6)E<B @/2 Q,@I&=6YC=&EO;B!N=6T@(" ](# *4W1A
M='5S(%)E9R @(" @/2 R,3!H"D-O;6UA;F0@4F5G(" @(#T@,3$V: I(96%D
M97(@='EP92 @(" ](#!H(%-I;F=L92UF=6YC=&EO;@I"25-4(" @(" @(" @
M(" ](#!H($)U:6QD+6EN+7-E;&8M=&5S="!N;W0@<W5P<&]R=&5D"DQA=&5N
M8WD@5&EM97(@(#T@-#!H"D-A8VAE($QI;F4@4VEZ93T@,3!H('5N+6-A8VAE
M86)L90I00TD@365M($%D9')E<W,@/2!F8F5F9C P,&@@,S)B:70@;&5N9W1H
M(#(P-#@@96YA8FQE9 I00TD@365M($%D9')E<W,@/2!F8F5F.# P,&@@,S)B
M:70@;&5N9W1H(#$V,S@T(&5N86)L960*4W5B<WES=&5M(%9E;F1O<B!)1" ]
M(#$P,CAH"E-U8G-Y<W1E;2!)1" @(" @(" @/2!D.&@*36%X($QA=" @(" @
M(" @/2 T;G,*36EN($=N=" @(" @(" @/2 R;G,*4$-)($EN="!0:6X@(" @
M/2!)3E0@00I);G1E<G)U<'0@;&EN92 ](#$Q"D-A<&%B:6QI=&EE<R!0;VEN
M=&5R(#T@-#1H"D-A<&%B:6QI='D@240@(" @(" @(#T@,6@*0V%P86)I;&ET
M:65S(" @(" @(" @/2 V-#$Q:" M(#!H"@I#;&%S<R @(" @(" @(" ]($-O
M;6UU;FEC871I;VX@*%!)0RD*5F5N9&]R($E$(" @(" @/2 Q,S5C:"P@475A
M=&5C:"!);F,@"D1E=FEC92!)1" @(" @(#T@-3!H+"!5;FMN;W=N(%5N:VYO
M=VX*4$-)(&EN9&5X(" @(" @/2 P: I#;&%S<R!#;V1E<R @(" ](# W,#(P
M,&@*4F5V:7-I;VX@240@(" @/2 S,F@*0G5S(&YU;6)E<B @(" @/2 T"D1E
M=FEC92!N=6UB97(@(#T@,3,*1G5N8W1I;VX@;G5M(" @/2 P"E-T871U<R!2
M96<@(" @(#T@,C@P: I#;VUM86YD(%)E9R @(" ](#$P,V@*2&5A9&5R('1Y
M<&4@(" @/2 P:"!3:6YG;&4M9G5N8W1I;VX*0DE35" @(" @(" @(" @/2 P
M:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T('-U<'!O<G1E9 I,871E;F-Y(%1I
M;65R(" ](#!H"D-A8VAE($QI;F4@4VEZ93T@,&@@"E!#22!)3R!!9&1R97-S
M(" ](&1C,#!H(&QE;F=T:" Q,C@@96YA8FQE9 I00TD@24\@061D<F5S<R @
M/2!D.&,P:"!L96YG=&@@-C0@96YA8FQE9 I3=6)S>7-T96T@5F5N9&]R($E$
M(#T@,3,U8V@*4W5B<WES=&5M($E$(" @(" @(" ](#4P: I00TD@17AP86YS
M:6]N(%)/32 ](&9B9C P,# P:"!L96YG=&@@,C T."!D:7-A8FQE9 I-87@@
M3&%T(" @(" @(" ](#!N<PI-:6X@1VYT(" @(" @(" ](#!N<PI00TD@26YT
M(%!I;B @(" ]($E.5"!!"DEN=&5R<G5P="!L:6YE(#T@,3 *"D-L87-S(" @
M(" @(" @(#T@0V]M;75N:6-A=&EO;B H4$E#*0I696YD;W(@240@(" @(" ]
M(#$S-6-H+"!1=6%T96-H($EN8R *1&5V:6-E($E$(" @(" @/2 T,&@L(%5N
M:VYO=VX@56YK;F]W;@I00TD@:6YD97@@(" @(" ](#!H"D-L87-S($-O9&5S
M(" @(#T@,#<P,C P: I2979I<VEO;B!)1" @(" ](#1H"D)U<R!N=6UB97(@
M(" @(#T@- I$979I8V4@;G5M8F5R(" ](#$T"D9U;F-T:6]N(&YU;2 @(#T@
M, I3=&%T=7,@4F5G(" @(" ](#(X,&@*0V]M;6%N9"!296<@(" @/2 Q,#-H
M"DAE861E<B!T>7!E(" @(#T@,&@@4VEN9VQE+69U;F-T:6]N"D))4U0@(" @
M(" @(" @(#T@,&@@0G5I;&0M:6XM<V5L9BUT97-T(&YO="!S=7!P;W)T960*
M3&%T96YC>2!4:6UE<B @/2 P: I#86-H92!,:6YE(%-I>F4](#!H( I00TD@
M24\@061D<F5S<R @/2!D.# P:"!L96YG=&@@,3(X(&5N86)L960*4$-)($E/
M($%D9')E<W,@(#T@9#AA,&@@;&5N9W1H(#,R(&5N86)L960*4W5B<WES=&5M
M(%9E;F1O<B!)1" ](#$S-6-H"E-U8G-Y<W1E;2!)1" @(" @(" @/2 T,&@*
M4$-)($5X<&%N<VEO;B!23TT@/2!F8F8P,# P,&@@;&5N9W1H(#(P-#@@9&ES
M86)L960*36%X($QA=" @(" @(" @/2 P;G,*36EN($=N=" @(" @(" @/2 P
M;G,*4$-)($EN="!0:6X@(" @/2!)3E0@00I);G1E<G)U<'0@;&EN92 ](#$Q
M"@I#;&%S<R @(" @(" @(" ]($)R:61G92 H56YK;F]W;BD*5F5N9&]R($E$
M(" @(" @/2 Q,C1B:"P@1W)E96Y3<')I;F<@0V]M<'5T97)S( I$979I8V4@
M240@(" @(" ](#0P:"P@56YK;F]W;B!5;FMN;W=N"E!#22!I;F1E>" @(" @
M(#T@,&@*0VQA<W,@0V]D97,@(" @/2 P-C@P,#!H"E)E=FES:6]N($E$(" @
M(#T@8F@*0G5S(&YU;6)E<B @(" @/2 T"D1E=FEC92!N=6UB97(@(#T@,34*
M1G5N8W1I;VX@;G5M(" @/2 P"E-T871U<R!296<@(" @(#T@,C@P: I#;VUM
M86YD(%)E9R @(" ](#$Q-V@*2&5A9&5R('1Y<&4@(" @/2 P:"!3:6YG;&4M
M9G5N8W1I;VX*0DE35" @(" @(" @(" @/2 P:"!"=6EL9"UI;BUS96QF+71E
M<W0@;F]T('-U<'!O<G1E9 I,871E;F-Y(%1I;65R(" ](#0P: I#86-H92!,
M:6YE(%-I>F4](#$P:"!U;BUC86-H96%B;&4*4W5B<WES=&5M(%9E;F1O<B!)
M1" ](#$R-&)H"E-U8G-Y<W1E;2!)1" @(" @(" @/2 Y,#@P: I-87@@3&%T
M(" @(" @(" ](#!N<PI-:6X@1VYT(" @(" @(" ](#!N<PI00TD@26YT(%!I
B;B @(" ]($E.5"!!"DEN=&5R<G5P="!L:6YE(#T@,3$*"@``
`
end

[David Gibbs]

Brian Meinke <RoverFan_SE7@hotmail.com> wrote:

The problem I am seeing is that the Dual Xeon box stops
transmitting.receiving data after some random amount of time (anywhere from
5 minutes to several hours) and all network connections are lost (I have to
slay/restart io-net to access the network).

Hm...your serial card and the network card wouldn't happen to be sharing
an interupt would they?

-David

--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Brian Meinke]

The problem is not occurring on the system with my VME Bus serial card...it
occurrs on COM1 ($3F8, 4) and COM2 ($2F8, 3) of the dual Xeon Dell (can you
tell I like the Dual Xeon ). Would it be a problem if they did share the
same interrupt (just for future reference)?

thanks again

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:avi8kg$dch$1@nntp.qnx.com...

Brian Meinke <RoverFan_SE7@hotmail.com> wrote:

The problem I am seeing is that the Dual Xeon box stops
transmitting.receiving data after some random amount of time (anywhere
from
5 minutes to several hours) and all network connections are lost (I have
to
slay/restart io-net to access the network).

Hm...your serial card and the network card wouldn't happen to be sharing
an interupt would they?

-David

--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Geoff]

While developing the QNX6 RocketPort driver I found that until I sorted
out my interrupt unmasking properly, my ethernet driver would stop. The
ethernet card happened to share IRQ9 (in my case) with one of the
RocketPorts. Both of course being PCI.

Basically, you have to identify/determine in your ISR if it was your
hardware that resulted in you being there. If not, quietly return NULL.
Otherwise, mask the interrupt proceed with whatever you have to do to
service it. You shouyld also unmask when finished, which may or may not
be in the ISR itself.

Geoff.



Brian Meinke wrote:

The problem is not occurring on the system with my VME Bus serial card...it
occurrs on COM1 ($3F8, 4) and COM2 ($2F8, 3) of the dual Xeon Dell (can you
tell I like the Dual Xeon ). Would it be a problem if they did share the
same interrupt (just for future reference)?

thanks again

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:avi8kg$dch$1@nntp.qnx.com...
Brian Meinke <RoverFan_SE7@hotmail.com> wrote:

The problem I am seeing is that the Dual Xeon box stops
transmitting.receiving data after some random amount of time (anywhere
from
5 minutes to several hours) and all network connections are lost (I have
to
slay/restart io-net to access the network).

Hm...your serial card and the network card wouldn't happen to be sharing
an interupt would they?

-David

--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

--

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: geoff@rtts.com.au

[Brian Meinke]

Thanks for the feedback. That was my assumption with shared interrupt
processing and subsequently what my driver does. However, the box with which
I am experiencing the "network-no-more-worky" problem is not the box running
my driver - it is occurring on a standard Intel PC talking on COM1 (IRQ
4...nic uses IRQ 9).

Brian


"Geoff" <geoff@rtts.com.au> wrote in message
news:3E1CEF4C.9271E1F4@rtts.com.au...

While developing the QNX6 RocketPort driver I found that until I sorted
out my interrupt unmasking properly, my ethernet driver would stop. The
ethernet card happened to share IRQ9 (in my case) with one of the
RocketPorts. Both of course being PCI.

Basically, you have to identify/determine in your ISR if it was your
hardware that resulted in you being there. If not, quietly return NULL.
Otherwise, mask the interrupt proceed with whatever you have to do to
service it. You shouyld also unmask when finished, which may or may not
be in the ISR itself.

Geoff.



Brian Meinke wrote:

The problem is not occurring on the system with my VME Bus serial
card...it
occurrs on COM1 ($3F8, 4) and COM2 ($2F8, 3) of the dual Xeon Dell (can
you
tell I like the Dual Xeon ). Would it be a problem if they did share
the
same interrupt (just for future reference)?

thanks again

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:avi8kg$dch$1@nntp.qnx.com...
Brian Meinke <RoverFan_SE7@hotmail.com> wrote:

The problem I am seeing is that the Dual Xeon box stops
transmitting.receiving data after some random amount of time
(anywhere
from
5 minutes to several hours) and all network connections are lost (I
have
to
slay/restart io-net to access the network).

Hm...your serial card and the network card wouldn't happen to be
sharing
an interupt would they?

-David

--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

--

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: geoff@rtts.com.au

[Brian Meinke]

Another question regarding access to global memory from the ISR:

In order to access the VME serial card, I have to mmap() a range of physical
memory (to access the VME bus short I/O range). I store the pointer returned
from mmap() in a global pointer which I assumed would be available in the
ISR. Is this assumption correct or is it possible that the mmap()'d region
might not always be valid within the ISR?

TIA
Brian


"Brian Meinke" <RoverFan_SE7@Hotmail.com> wrote in message
news:avi5hv$ard$1@inn.qnx.com...

While developing a devc driver, I encountered a little intermittent
problem
with devc-ser8250 on 6.20A PE SMP(Dual 1.8 GHz Xeons, 512MB, 3COM 3C905C
NIC)

I am trying to develop a character driver for a multi-port VME Bus serial
board (NEC 7201 DUART) and have written a small test application which
simply writes a string out one serial port of the VME serial card and is
received on COM1 on a different computer. The VME based computer (PIII850
256 MB) running my devc driver (devc-mz8300) and the Dual Xeon box is
simply
running devc-ser8250. Serial ports on both boxes set to 9600,N,8,1 raw
with
no hardware/software handshaking (this is due to legacy configurations of
the VME serial board already being used in the field).

The problem I am seeing is that the Dual Xeon box stops
transmitting.receiving data after some random amount of time (anywhere
from
5 minutes to several hours) and all network connections are lost (I have
to
slay/restart io-net to access the network).

I have tried using the non-SMP kernel which only extends the amount of
time
which passes before the problem occurs. I have disabled hyper-threading
both
with and without the SMP kernel which seems to have a similar effect as
using the non-SMP kernel (more time passes before problem occurs).

I have attached the output from 'pci -v'. Any ideas are greatly
appreciated.

TIA
Brian

[Geoff]

I suspect that even with a physical address (as opposed to a virtual
address) you might have problems when referencing from within the ISR.
Fortunately I didn't have this problem. But I had similar issues to
contend with. Essentially, from within the ISR I am able to reference
both the memory area I passed into the ISR when I set it up, and I also
am able to reference a global pointer to an object that allows me to
obtain some essential and specific information about the hardware device
that actually initiated the interrupt. The driver supports multiple
cards with shared or unshared interrupts, PCI or ISA, using the one ISR.

To access some memory (mmap) I would probably not be inclined to try it
from within the ISR. Rather I would (and do) fire a pulse and have my
application do the work in its handler outside of the ISR context.


Geoff.

Brian Meinke wrote:

Another question regarding access to global memory from the ISR:

In order to access the VME serial card, I have to mmap() a range of physical
memory (to access the VME bus short I/O range). I store the pointer returned
from mmap() in a global pointer which I assumed would be available in the
ISR. Is this assumption correct or is it possible that the mmap()'d region
might not always be valid within the ISR?

TIA
Brian

"Brian Meinke" <RoverFan_SE7@Hotmail.com> wrote in message
news:avi5hv$ard$1@inn.qnx.com...
While developing a devc driver, I encountered a little intermittent
problem
with devc-ser8250 on 6.20A PE SMP(Dual 1.8 GHz Xeons, 512MB, 3COM 3C905C
NIC)

I am trying to develop a character driver for a multi-port VME Bus serial
board (NEC 7201 DUART) and have written a small test application which
simply writes a string out one serial port of the VME serial card and is
received on COM1 on a different computer. The VME based computer (PIII850
256 MB) running my devc driver (devc-mz8300) and the Dual Xeon box is
simply
running devc-ser8250. Serial ports on both boxes set to 9600,N,8,1 raw
with
no hardware/software handshaking (this is due to legacy configurations of
the VME serial board already being used in the field).

The problem I am seeing is that the Dual Xeon box stops
transmitting.receiving data after some random amount of time (anywhere
from
5 minutes to several hours) and all network connections are lost (I have
to
slay/restart io-net to access the network).

I have tried using the non-SMP kernel which only extends the amount of
time
which passes before the problem occurs. I have disabled hyper-threading
both
with and without the SMP kernel which seems to have a similar effect as
using the non-SMP kernel (more time passes before problem occurs).

I have attached the output from 'pci -v'. Any ideas are greatly
appreciated.

TIA
Brian

--

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: geoff@rtts.com.au

[David Gibbs]

Brian Meinke <RoverFan_SE7@hotmail.com> wrote:

Another question regarding access to global memory from the ISR:

In order to access the VME serial card, I have to mmap() a range of physical
memory (to access the VME bus short I/O range). I store the pointer returned
from mmap() in a global pointer which I assumed would be available in the
ISR. Is this assumption correct or is it possible that the mmap()'d region
might not always be valid within the ISR?

The physical memory you have mmap() should always be available and useable
from the ISR. IF at some point we implement paging/swapping, and IF you
choose to enable on your system, then the global pointer you stored that
address in may not be accessible from your ISR. mlock() will be able to
be used to request the memory not be paged/swapped to ensure this won't
be a problem.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[David Gibbs]

Brian Meinke <RoverFan_SE7@hotmail.com> wrote:

The problem is not occurring on the system with my VME Bus serial card...it
occurrs on COM1 ($3F8, 4) and COM2 ($2F8, 3) of the dual Xeon Dell (can you
tell I like the Dual Xeon ).

Oh, I hadn't realized from the post that it was a different machine
where you lost network access.

This sounds like something else going on, and I have no idea
what.

Would it be a problem if they did share the
same interrupt (just for future reference)?

If you had coding/logic problems in your interrupt handling, you
might end up leaving the interrupt masked when you shouldn't have,
and resulted in this. Basically if a couple people are sharing an
irq, and one makes a mistake, it can damage both.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Brian Meinke]

Thanks for the feedback. I suppose just to be on the safe side (so I dont
hve to worry about it in the future) I will add an mlock() call to lock the
mmap()'d region. The good news for now is that I haven't seen the
"network-no-worky" problem (described in my original post) for quite some
time now

Brian

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:avkmou$3ch$2@nntp.qnx.com...

Brian Meinke <RoverFan_SE7@hotmail.com> wrote:
Another question regarding access to global memory from the ISR:

In order to access the VME serial card, I have to mmap() a range of
physical
memory (to access the VME bus short I/O range). I store the pointer
returned
from mmap() in a global pointer which I assumed would be available in
the
ISR. Is this assumption correct or is it possible that the mmap()'d
region
might not always be valid within the ISR?

The physical memory you have mmap() should always be available and useable
from the ISR. IF at some point we implement paging/swapping, and IF you
choose to enable on your system, then the global pointer you stored that
address in may not be accessible from your ISR. mlock() will be able to
be used to request the memory not be paged/swapped to ensure this won't
be a problem.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[David Gibbs]

Brian Meinke <RoverFan_SE7@hotmail.com> wrote:

Thanks for the feedback. I suppose just to be on the safe side (so I dont
hve to worry about it in the future) I will add an mlock() call to lock the
mmap()'d region.

Maybe I wasn't clear enough. It isn't the mmap()ed region that needs the
mlock() call. It is a mapping of physical memory, the OS is never going
to page/swap that out. (Among other reasons, there is no point to doing
so as doing so doesn't gain any RAM for other programs to use. It is also
a physical mapping of addresses, so swapping it out is kind of meaningless.)

It is the global pointer (which resides in your processes RAM) which is
the memory that might get swapped/paged out at some point in the future,
and which might need the mlock() call applied to it for safety.

That is, you'll always be able to get to the physcical mapped memory,
you may not always be able to get to your program's pointer to that
memory to know where in your address space it resides.

-David

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:avkmou$3ch$2@nntp.qnx.com...
Brian Meinke <RoverFan_SE7@hotmail.com> wrote:
Another question regarding access to global memory from the ISR:

In order to access the VME serial card, I have to mmap() a range of
physical
memory (to access the VME bus short I/O range). I store the pointer
returned
from mmap() in a global pointer which I assumed would be available in
the
ISR. Is this assumption correct or is it possible that the mmap()'d
region
might not always be valid within the ISR?

The physical memory you have mmap() should always be available and useable
from the ISR. IF at some point we implement paging/swapping, and IF you
choose to enable on your system, then the global pointer you stored that
address in may not be accessible from your ISR. mlock() will be able to
be used to request the memory not be paged/swapped to ensure this won't
be a problem.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Brian Meinke]

Ahh....That makes sense. Thanks for the clarification.

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:avms2m$gbt$2@nntp.qnx.com...

Brian Meinke <RoverFan_SE7@hotmail.com> wrote:
Thanks for the feedback. I suppose just to be on the safe side (so I
dont
hve to worry about it in the future) I will add an mlock() call to lock
the
mmap()'d region.

Maybe I wasn't clear enough. It isn't the mmap()ed region that needs the
mlock() call. It is a mapping of physical memory, the OS is never going
to page/swap that out. (Among other reasons, there is no point to doing
so as doing so doesn't gain any RAM for other programs to use. It is also
a physical mapping of addresses, so swapping it out is kind of
meaningless.)

It is the global pointer (which resides in your processes RAM) which is
the memory that might get swapped/paged out at some point in the future,
and which might need the mlock() call applied to it for safety.

That is, you'll always be able to get to the physcical mapped memory,
you may not always be able to get to your program's pointer to that
memory to know where in your address space it resides.

-David

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:avkmou$3ch$2@nntp.qnx.com...
Brian Meinke <RoverFan_SE7@hotmail.com> wrote:
Another question regarding access to global memory from the ISR:

In order to access the VME serial card, I have to mmap() a range of
physical
memory (to access the VME bus short I/O range). I store the pointer
returned
from mmap() in a global pointer which I assumed would be available in
the
ISR. Is this assumption correct or is it possible that the mmap()'d
region
might not always be valid within the ISR?

The physical memory you have mmap() should always be available and
useable
from the ISR. IF at some point we implement paging/swapping, and IF
you
choose to enable on your system, then the global pointer you stored
that
address in may not be accessible from your ISR. mlock() will be able
to
be used to request the memory not be paged/swapped to ensure this won't
be a problem.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.



--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[Geoff]

David,

I have interest in this for the same reasons as Brian. Problem is, the
docs I have say that mlock() is not currently supported. Is this still
correct?

Geoff

David Gibbs wrote:

Brian Meinke <RoverFan_SE7@hotmail.com> wrote:
Thanks for the feedback. I suppose just to be on the safe side (so I dont
hve to worry about it in the future) I will add an mlock() call to lock the
mmap()'d region.

Maybe I wasn't clear enough. It isn't the mmap()ed region that needs the
mlock() call. It is a mapping of physical memory, the OS is never going
to page/swap that out. (Among other reasons, there is no point to doing
so as doing so doesn't gain any RAM for other programs to use. It is also
a physical mapping of addresses, so swapping it out is kind of meaningless.)

It is the global pointer (which resides in your processes RAM) which is
the memory that might get swapped/paged out at some point in the future,
and which might need the mlock() call applied to it for safety.

That is, you'll always be able to get to the physcical mapped memory,
you may not always be able to get to your program's pointer to that
memory to know where in your address space it resides.

-David

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:avkmou$3ch$2@nntp.qnx.com...
Brian Meinke <RoverFan_SE7@hotmail.com> wrote:
Another question regarding access to global memory from the ISR:

In order to access the VME serial card, I have to mmap() a range of
physical
memory (to access the VME bus short I/O range). I store the pointer
returned
from mmap() in a global pointer which I assumed would be available in
the
ISR. Is this assumption correct or is it possible that the mmap()'d
region
might not always be valid within the ISR?

The physical memory you have mmap() should always be available and useable
from the ISR. IF at some point we implement paging/swapping, and IF you
choose to enable on your system, then the global pointer you stored that
address in may not be accessible from your ISR. mlock() will be able to
be used to request the memory not be paged/swapped to ensure this won't
be a problem.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

[David Gibbs]

Geoff <geoff@rtts.com.au> wrote:

David,

I have interest in this for the same reasons as Brian. Problem is, the
docs I have say that mlock() is not currently supported. Is this still
correct?

That is, also, correct. (mlock() may or may not be currently implemented,
that is, it may actually set the bits to lock something into memory right
now, or it may not -- but since we don't actually swap/page anything,
it doesn't have any effect.)

If you go back to my original paragraph, I say things like "if swapping
is implemented" and "mlock() will be able to be used to".

So, mlock() does(the equivalent of) nothing now, but may at some point
in the future be important.

-David

David Gibbs wrote:

Brian Meinke <RoverFan_SE7@hotmail.com> wrote:
Thanks for the feedback. I suppose just to be on the safe side (so I dont
hve to worry about it in the future) I will add an mlock() call to lock the
mmap()'d region.

Maybe I wasn't clear enough. It isn't the mmap()ed region that needs the
mlock() call. It is a mapping of physical memory, the OS is never going
to page/swap that out. (Among other reasons, there is no point to doing
so as doing so doesn't gain any RAM for other programs to use. It is also
a physical mapping of addresses, so swapping it out is kind of meaningless.)

It is the global pointer (which resides in your processes RAM) which is
the memory that might get swapped/paged out at some point in the future,
and which might need the mlock() call applied to it for safety.

That is, you'll always be able to get to the physcical mapped memory,
you may not always be able to get to your program's pointer to that
memory to know where in your address space it resides.

-David

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:avkmou$3ch$2@nntp.qnx.com...
Brian Meinke <RoverFan_SE7@hotmail.com> wrote:
Another question regarding access to global memory from the ISR:

In order to access the VME serial card, I have to mmap() a range of
physical
memory (to access the VME bus short I/O range). I store the pointer
returned
from mmap() in a global pointer which I assumed would be available in
the
ISR. Is this assumption correct or is it possible that the mmap()'d
region
might not always be valid within the ISR?

The physical memory you have mmap() should always be available and useable
from the ISR. IF at some point we implement paging/swapping, and IF you
choose to enable on your system, then the global pointer you stored that
address in may not be accessible from your ISR. mlock() will be able to
be used to request the memory not be paged/swapped to ensure this won't
be a problem.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.