Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
On Thu, 12 Dec 2002, Lamont Granquist wrote:
(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)
Ok, this shows that the ccb_list is empty and this is the pass1
device. The question is why is the wakeup() never getting called?
It would help if you did this immediately before running cda and reported
the dmesg:
camcontrol debug -S -T pass1
Also, add this patch to augment debugging output:
--- /sys/cam/cam_xpt.c 23 Sep 2002 04:55:32 - 1.128
+++ /sys/cam/cam_xpt.c 13 Dec 2002 19:49:48 -
@@ -3789,6 +3789,7 @@
* device queue otherwise we may never get run
* again.
*/
+ printf(xpt_get_ccb failed, queue hung!\n);
break;
}
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
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
Cannot access memory at address 0xbfbfe778
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
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 [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
(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 [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
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. And i'm running a fairly current -current: # uname -a FreeBSD coredump.scriptkiddie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Wed Dec 4 10:39:19 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP i386 Please update to at least Dec 5. There was a critical ahc fix that went in on the 4th, although it wouldn't cause the problem you're reporting. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
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. And i'm running a fairly current -current: # uname -a FreeBSD coredump.scriptkiddie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Wed Dec 4 10:39:19 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP i386 Please update to at least Dec 5. There was a critical ahc fix that went in on the 4th, although it wouldn't cause the problem you're reporting. If it could cause lost transactions somehow, it might have something to do with this, but it looks like it is a lost timeout problem that got fixed. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
On Wed, 11 Dec 2002, 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. UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 36761 1 6 -8 0 1884 1132 cgticb D p40:00.01 /usr/X11R6/l To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ioctl(CAMGETPASSTHRU) hung X11/cda process
# 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...) This device is: cd0 at ahc0 bus 0 target 4 lun 0 cd0: PLEXTOR CD-R PX-W1210S 1.01 Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: cd present [308392 x 2048 byte records] And i'm running a fairly current -current: # uname -a FreeBSD coredump.scriptkiddie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Wed Dec 4 10:39:19 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
