Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Dec 2002 23:22:58 -0800 (PST)
From:      Lamont Granquist <lamont@scriptkiddie.org>
To:        Nate Lawson <nate@root.org>
Cc:        "Kenneth D. Merry" <ken@kdm.org>, <freebsd-current@FreeBSD.ORG>
Subject:   Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
Message-ID:  <20021212232216.U6076-100000@coredump.scriptkiddie.org>
In-Reply-To: <Pine.BSF.4.21.0212121217560.34268-100000@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help


(kgdb) frame 2
#2  0xc0140ffc in cam_periph_getccb (periph=0xc41fc080, priority=1)
    at /usr/src/sys/cam/cam_periph.c:748
748     /usr/src/sys/cam/cam_periph.c: No such file or directory.
        in /usr/src/sys/cam/cam_periph.c
(kgdb) print *periph
$11 = {pinfo = {priority = 1, generation = 6, index = 1},
  periph_start = 0xc0157220 <passstart>,
  periph_oninval = 0xc0156d70 <passoninvalidate>,
  periph_dtor = 0xc0156e00 <passcleanup>, periph_name = 0xc049b503 "pass",
  path = 0xc406dcc0, softc = 0xc41e6000, unit_number = 1,
  type = CAM_PERIPH_BIO, flags = 0, immediate_priority = 1, refcount = 1,
  ccb_list = {slh_first = 0x0}, periph_links = {sle_next = 0x0},
unit_links = {
    tqe_next = 0x0, tqe_prev = 0xc41cdb40}, deferred_callback = 0,
  deferred_ac = 0}
(kgdb)


On Thu, 12 Dec 2002, Nate Lawson wrote:
> 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?20021212232216.U6076-100000>