Date: Thu, 12 Dec 2002 12:28:36 -0800 (PST) From: Nate Lawson <nate@root.org> To: Lamont Granquist <lamont@scriptkiddie.org> Cc: "Kenneth D. Merry" <ken@kdm.org>, freebsd-current@FreeBSD.ORG Subject: Re: ioctl(CAMGETPASSTHRU) hung X11/cda process Message-ID: <Pine.BSF.4.21.0212121217560.34268-100000@root.org> In-Reply-To: <20021212002820.S911-100000@coredump.scriptkiddie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Dec 2002, Lamont Granquist wrote:
> On Wed, 11 Dec 2002, Kenneth D. Merry wrote:
> > On Wed, Dec 11, 2002 at 11:37:42 -0800, Nate Lawson wrote:
> > > On Tue, 10 Dec 2002, Lamont Granquist wrote:
> > > > # ps xauww | egrep cda
> > > > root 36761 0.0 0.3 1884 1452 p4 D 7:25PM 0:00.01
> > > > /usr/X11R6/lib/X11/xmcd/bin-FreeBSD_5-i386/cda -batch -dev /dev/cd0 on
> > > > # strace -p 36761
> > > > ioctl(0, CAMGETPASSTHRU
> > > >
> > > > (...hangs forever and won't die with kill -9...)
> > >
> > > ps axl output for that proc, please.
> >
> > It's probably hanging waiting for a CCB, although ps axl output should tell
> > us whether or not that's the case.
> >
> > If that is the case, it raises the "why" question, especially since nothing
> > has changed in that area recently that I know of.
>
> i panic'd the system and got this for a bt on the process:
>
> (kgdb) bt
> #0 mi_switch () at /usr/src/sys/kern/kern_synch.c:522
> #1 0xc02f2027 in msleep (ident=0xc41fc0b8, mtx=0x0, priority=76,
> wmesg=0x0,
> timo=0) at /usr/src/sys/kern/kern_synch.c:262
> #2 0xc0140ffc in cam_periph_getccb (periph=0xc41fc080, priority=1)
> at /usr/src/sys/cam/cam_periph.c:748
> #3 0xc01410a5 in cam_periph_ioctl (periph=0x0, cmd=-1033890813, addr=0x0,
> error_routine=0xc01574f0 <passerror>) at
> /usr/src/sys/cam/cam_periph.c:784
> #4 0xc01573b8 in passioctl (dev=0x0, cmd=0, addr=0xc41f2800 "", flag=3,
> td=0xc42fdc40) at /usr/src/sys/cam/scsi/scsi_pass.c:533
> #5 0xc02b45ee in spec_ioctl (ap=0xc41f2800)
> at /usr/src/sys/fs/specfs/spec_vnops.c:352
> #6 0xc02b3d18 in spec_vnoperate (ap=0x0)
> at /usr/src/sys/fs/specfs/spec_vnops.c:126
> #7 0xc034ae91 in vn_ioctl (fp=0xc4340f3c, com=3261076483,
> data=0xc41f2800,
> active_cred=0xc5eb9100, td=0xc42fdc40) at vnode_if.h:488
> #8 0xc0310686 in ioctl (td=0xc42fdc40, uap=0xdacb0d10) at file.h:227
> #9 0xc046cc7e in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077942432, tf_esi =
> 134979584, tf_ebp = -1077942408, tf_isp = -624226956, tf_ebx = 672215480,
> tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip =
> 672506643, tf_cs = 31, tf_eflags = 582, tf_esp = -1077943092, tf_ss = 47})
> at /usr/src/sys/i386/i386/trap.c:1033
> #10 0xc045cd2d in Xint0x80_syscall () at {standard input}:140
This indicates the system is waiting for a CCB (blocked on tsleep in
cam_periph_getccb). The call to xpt_schedule should make a CCB available
and if it doesn't, it goes to sleep. A later schedule should hit the
start entry for a driver that relinquishes its ccb and calls wakeup.
Ken, I don't see any change that would cause this problem either. When
did this problem start occurring? Also, it might be good to add a PCATCH
to the tsleep since it's ok to interrupt here (I think).
It would be great if you could do "frame 2" and then "print *periph"
-Nate
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0212121217560.34268-100000>