Date: Mon, 17 May 2004 17:08:21 -0400 From: Mike Tancsa <mike@sentex.net> To: freebsd-current@freebsd.org Subject: sio / puc wedging on both -current and -stable Message-ID: <6.0.3.0.0.20040517154946.06d23d60@64.7.153.2>
next in thread | raw e-mail | index | archive | help
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@pci1:5:0: class=0x070002 card=0x00000000 chip=0x01201407 rev=0x00
hdr=0x00
vendor = 'Lava Computer Manufacturing Inc'
class = simple comms
subclass = UART
puc1@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@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.0.3.0.0.20040517154946.06d23d60>