sio / puc wedging on both -current and -stable

We are building a box that needs many serial ports to talk to some legacy 
low speed (9600) serial devices.  Our application (a small daemon written 
in c) happily talks to the devices and all works well.  However, if one of 
the external devices die or is unplugged, the FreeBSD box will at seemingly 
irregular intervals lockup hard.  The only way to unlock the machine is to 
either hit the reset button (the keyboard is locked solid-- not even num 
lock works) *or* if I jiggle the DB9 connector enough so that enough noise 
shorts across the serial port *or* plug the serial port into a working 
device that I imagine sends some data on the serial port.  The machine then 
returns to a normal state and all is well. This does NOT happen with the 
onboard serial ports.  Only with a PUC device (we have tried several and 
its the same result)

Does this jog anyone's memory as to what the problem might be ?

puc0_at_pci1:5:0:  class=0x070002 card=0x00000000 chip=0x01201407 rev=0x00 
hdr=0x00
     vendor   = 'Lava Computer Manufacturing Inc'
     class    = simple comms
     subclass = UART
puc1_at_pci1:5:1:  class=0x070002 card=0x00000000 chip=0x01211407 rev=0x00 
hdr=0x00
     vendor   = 'Lava Computer Manufacturing Inc'
     class    = simple comms

kernel is GENERIC


I have a remote debugger setup and I can send a break and drop the unit 
into debugger, but kernel debugging is a little beyond our skillset.


db> trace
siointr1(c11d0000,d56dacb0,c02b49e6,c11d0000,10) at siointr1+0xc5
siointr(c11d0000,10,a005,c,10060) at siointr+0xc
Xfastintr4(c11d0c00,d56dacd8,c02a741a,c11d0c00,c0a3f240) at Xfastintr4+0x16
siointr(c11d0c00) at siointr+0xc
puc_intr(c11af000,63103a,c11d0c00,0,d56dad68) at puc_intr+0x4e
intr_mux(c0a3f240,0,630010,c1360010,c0170010) at intr_mux+0x1f
Xresume12() at Xresume12+0x2b
--- interrupt, eip = 0xc02b5b2a, esp = 0xd56dad38, ebp = 0xd56dad68 ---
vec12(c11ce980,3,2000,cbf03a00,d56634c0) at vec12+0x2
cnopen(c11ce980,3,2000,cbf03a00,0) at cnopen+0x6a
spec_open(d56dae08,d56dade0,c0270a6d,d56dae08,d56dae7c) at spec_open+0xfe
spec_vnoperate(d56dae08,d56dae7c,c01a29cc,d56dae08,0) at spec_vnoperate+0x15
ufs_vnoperatespec(d56dae08,0,c1313a40,d56daf80,d56634c0) at 
ufs_vnoperatespec+0x15
vn_open(d56daed4,3,ec,cbf03a00,3) at vn_open+0x3d8
open(cbf03a00,d56daf80,bfbffa94,bfbffa94,bfbff964) at open+0xb8
syscall2(c02b002f,2f,2f,bfbff964,bfbffa94) at syscall2+0x1a9
Xint0x80_syscall() at Xint0x80_syscall+0x25


Here is the ps snippet

db> ps
   pid   proc     addr    uid  ppid  pgrp  flag stat wmesg   wchan   cmd
   151 cbf03380 d56e3000    0     1   151 000084  3  siodtr c11d0418 seriald
   149 cbf03520 d56df000    0     1   149 000084  3  siodtr c11d0818 seriald
   147 cbf03a00 d56d8000    0     1   147 000004  2                  seriald
   145 cbf036c0 d56e6000    0     1   145 000484  2                  seriald
db>

  panic
panic: from debugger
Debugger("panic")


Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer     = 0x8:0xc02b3975
stack pointer           = 0x10:0xd56daaa4
frame pointer           = 0x10:0xd56daaac
code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, IOPL = 0
current process         = 147 (seriald)
interrupt mask          = tty
Stopped at      siointr1+0xc5:  jmp     siointr1+0x1b4


Any pointers on how to track this down ?  It happens both in RELENG_4 from 
May 12th and 5.2-CURRENT FreeBSD 5.2-CURRENT #1: Thu May 13


	---Mike
--------------------------------------------------------------------
Mike Tancsa,                          	          tel +1 519 651 3400
Sentex Communications,     			  mike_at_sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada			  www.sentex.net/mike