Strange behaviour (processes "hung" in getblk state)
Robin P. Blanchard
robin.blanchard at gactr.uga.edu
Sun Jan 25 07:58:59 PST 2004
ok...
I let the machine stay "as is" since posting yesterday. Almost 24 hours
later, nothing appears to have changed. Any ideas ?
4494 p0 S+ 0:00.02 make installworld
4499 p0 S+ 0:00.01 /bin/sh -ec cd /usr/src;
PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x /usr/obj/usr/src/make.i386/make
]; then ec
4501 p0 S+ 0:00.04 make -m /usr/src/share/mk -f Makefile.inc1
installworld
4568 p0 S+ 0:00.01 (sh)
4569 p0 S+ 0:00.03 make -f Makefile.inc1 reinstall
4619 p0 S+ 0:00.01 /bin/sh -ec cd /usr/src; make -f Makefile.inc1
install
4620 p0 S+ 0:00.03 make -f Makefile.inc1 install
4627 p0 S+ 0:00.06 (sh)
20977 p0 S+ 0:00.02 make install DIRPRFX=etc/
20982 p0 S+ 0:00.01 /bin/sh -ec cd /usr/src/etc/../share/man; make
makedb
20983 p0 S+ 0:00.01 make makedb
20984 p0 D+ 0:02.85 makewhatis /usr/share/man
20985 p1 Ss 0:00.31 -bash (bash)
db> tr 20982
sched_switch(c62e9a80,2,c067cb2a,1d4,9e90890b) at sched_switch+0x155
mi_switch(c62e9a80,5c,c067cb2a,ee,1) at mi_switch+0x248
msleep(c62fadc0,c62fae2c,15c,c067c496,0) at msleep+0x4ff
wait1(c62e9a80,ebe7ad14,0,ebe7ad40,c0636410) at wait1+0x9a0
wait4(c62e9a80,ebe7ad14,c069237a,3ee,4) at wait4+0x20
syscall(2f,2f,2f,bfbfe904,118e) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (7, FreeBSD ELF32, wait4), eip = 0x281360df, esp = 0xbfbfe84c,
ebp =
0xbfbfe868 ---
db> tr 20983
sched_switch(c6b4e150,2,c067cb2a,1d4,e745835d) at sched_switch+0x155
mi_switch(c6b4e150,5c,c067cb2a,ee,1) at mi_switch+0x248
msleep(c6b4da50,c6b4dabc,15c,c067c496,0) at msleep+0x4ff
wait1(c6b4e150,ebf9cd14,0,ebf9cd40,c0636410) at wait1+0x9a0
wait4(c6b4e150,ebf9cd14,c069237a,3ee,4) at wait4+0x20
syscall(2f,2f,2f,bfbfdd24,51f8) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (7, FreeBSD ELF32, wait4), eip = 0x8064423, esp = 0xbfbfdccc, ebp
=
0xbfbfdce8 ---
db> tr 20984
sched_switch(c5ff1000,2,c067cb2a,1d4,4a463321) at sched_switch+0x155
mi_switch(c5ff1000,50,c067cb2a,ca,1) at mi_switch+0x248
msleep(d26e9244,c06cc688,50,c0682e20,0) at msleep+0x4ff
acquire(e9b97a3c,2000020,600,e7,c0682aa7) at acquire+0xae
lockmgr(d26e9244,2090022,c6955e38,c5ff1000,c06d89e8) at lockmgr+0x457
getblk(c6955e38,0,0,800,0) at getblk+0x18f
breadn(c6955e38,0,0,800,0) at breadn+0x52
bread(c6955e38,0,0,800,0) at bread+0x4c
ffs_read(e9b97be4,c0684a6b,c5ff1000,1ff,c06d86f0) at ffs_read+0x3ff
vn_read(c62f7b6c,e9b97c80,c6292180,0,c5ff1000) at vn_read+0x1f5
dofileread(c5ff1000,c62f7b6c,4,80ee000,4000) at dofileread+0xdc
read(c5ff1000,e9b97d14,c069237a,3ee,3) at read+0x6b
syscall(806002f,2f,bfbf002f,806c158,4000) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (3, FreeBSD ELF32, read), eip = 0x8061a4f, esp = 0xbfbfd3ac, ebp
= 0
xbfbfd3c8 ---
db> tr 20985
sched_switch(c5d81690,2,c067cb2a,1d4,3f1c69d3) at sched_switch+0x155
mi_switch(c5d81690,59,c067cb2a,ee,1) at mi_switch+0x248
msleep(c6049e40,0,159,c068153d,0) at msleep+0x4ff
ttysleep(c6049e30,c6049e40,159,c068153d,0) at ttysleep+0x3d
ttread(c6049e30,e1454c80,7f0000,6,c61eb618) at ttread+0x483
ptsread(c6f91c00,e1454c80,7f0000,c05739e8,c06aca20) at ptsread+0x30d
spec_read(e1454be4,e1454c30,c057e4c5,e1454be4,c0684a6b) at spec_read+0x1e3
spec_vnoperate(e1454be4,c0684a6b,c5d81690,1ff,c06d86f0) at
spec_vnoperate+0x18
vn_read(c62f761c,e1454c80,c6e99580,0,c5d81690) at vn_read+0x1f5
dofileread(c5d81690,c62f761c,0,bfbfe36f,1) at dofileread+0xdc
read(c5d81690,e1454d14,c069237a,3ee,3) at read+0x6b
syscall(bfbf002f,80b002f,bfbf002f,bfbfeb20,28225f00) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (3, FreeBSD ELF32, read), eip = 0x281aa15f, esp = 0xbfbfe35c, ebp
=
0xbfbfe378 ---
-----Original Message-----
From: Robin P. Blanchard
Sent: Sat 1/24/2004 11:41 AM
To: Ken Smith
Cc: Ken Smith; Kris Kennaway; current at freebsd.org
Subject: RE: Strange behaviour (processes "hung" in getblk state)
# top |fgrep makewhatis
20984 root -4 0 812K 716K getblk 1 0:03 0.00% 0.00%
makewhatis
# sysctl debug.enter_debugger=ddb
debug.enter_debuDgger: ebugger("debug.enter_debugger")
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> tr 20984
sched_switch(c5ff1000,2,c067cb2a,1d4,4a463321) at sched_switch+0x155
mi_switch(c5ff1000,50,c067cb2a,ca,1) at mi_switch+0x248
msleep(d26e9244,c06cc688,50,c0682e20,0) at msleep+0x4ff
acquire(e9b97a3c,2000020,600,e7,c0682aa7) at acquire+0xae
lockmgr(d26e9244,2090022,c6955e38,c5ff1000,c06d89e8) at lockmgr+0x457
getblk(c6955e38,0,0,800,0) at getblk+0x18f
breadn(c6955e38,0,0,800,0) at breadn+0x52
bread(c6955e38,0,0,800,0) at bread+0x4c
ffs_read(e9b97be4,c0684a6b,c5ff1000,1ff,c06d86f0) at ffs_read+0x3ff
vn_read(c62f7b6c,e9b97c80,c6292180,0,c5ff1000) at vn_read+0x1f5
dofileread(c5ff1000,c62f7b6c,4,80ee000,4000) at dofileread+0xdc
read(c5ff1000,e9b97d14,c069237a,3ee,3) at read+0x6b
syscall(806002f,2f,bfbf002f,806c158,4000) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (3, FreeBSD ELF32, read), eip = 0x8061a4f, esp =
0xbfbfd3ac, ebp = 0
xbfbfd3c8 ---
db>
-----Original Message-----
From: Ken Smith [mailto:kensmith at cse.Buffalo.EDU]
Sent: Thu 1/22/2004 1:50 PM
To: Robin P. Blanchard
Cc: Ken Smith; Kris Kennaway
Subject: Re: Strange behaviour
On Thu, Jan 22, 2004 at 01:34:39PM -0500, Robin P. Blanchard
wrote:
> I also enabled DEBUG_VFS_LOCKS; but nothing of interest
shows up once
> 'makeshatis' gets stuck in getblk. I've just setup serial
console on this
> thing (along with BREAK_TO_DEBUGGER). How do I enter the
debugger over the
> serial link (I know how from the terminal console)? Once
there do just do a
> "tr $pid" to (hopefully) get some useful info ?
I was able to get there by logging in as root, then do:
sysctl debug.enter_debugger=ddb
That seems to drop the kernel to DDB on the serial port.
Here is what seems typical of the processes that are wedged
on my
machine:
db> tr 1429
sched_switch(c9e0f690,2,c0872111,1d4,75752699) at
sched_switch+0xb5
mi_switch(c9e0f690,50,c0872111,ca,1) at mi_switch+0x248
msleep(d3bb3564,c092f9dc,50,c08782a0,0) at msleep+0x4ff
acquire(edc26ab4,2000020,600,e7,c0877f27) at acquire+0xae
lockmgr(d3bb3564,2090022,c78af410,c9e0f690,c0669ae3) at
lockmgr+0x457
getblk(c78af410,277b440,0,4000,0) at getblk+0x190
breadn(c78af410,277b440,0,4000,0) at breadn+0x52
bread(c78af410,277b440,0,4000,0) at bread+0x4c
ffs_update(c9650208,0,1,54,edc26c4c) at ffs_update+0x235
ufs_inactive(edc26c78,edc26c94,c069e77e,edc26c78,c087982c) at
ufs_inactive+0x205ufs_vnoperate(edc26c78,c087982c,c08794ad,7cc,c0910ce0) at
ufs_vnoperate+0x18
vrele(c9650208,0,c0879d73,2cb,c9b5ab00) at vrele+0x16e
fchdir(c9e0f690,edc26d14,c088ff8d,3ee,1) at fchdir+0x227
syscall(805002f,805002f,bfbf002f,5,8058f00) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (13, FreeBSD ELF32, fchdir), eip = 0x280c616f,
esp = 0xbfbfe92c, ebp = 0xbfbfe9c8 ---
db>
There is one that's wedged in "ufs" instead of "getblk", and
it looks
like this:
db> tr 2062
sched_switch(c785e930,2,c0872111,1d4,9c0e2995) at
sched_switch+0xb5
mi_switch(c785e930,50,c0872111,ca,1) at mi_switch+0x248
msleep(c83d55c0,c092f8e0,50,c087d04c,0) at msleep+0x4ff
acquire(edb68a54,1000040,600,e7,14b) at acquire+0xae
lockmgr(c83d55c0,1010002,c83d5514,c785e930,edb68a70) at
lockmgr+0x457
vop_stdlock(edb68a98,edb68a7c,c07adda8,edb68a98,edb68ab4) at
vop_stdlock+0x2c
vop_defaultop(edb68a98,edb68ab4,c06ad4a9,edb68a98,edb68ab4)
at vop_defaultop+0x18
ufs_vnoperate(edb68a98,edb68ab4,c0635f3a,c83d5514,8) at
ufs_vnoperate+0x18
vn_lock(c83d5514,10002,c785e930,760,0) at vn_lock+0xf9
vget(c83d5514,2,c785e930,dbdde,c785e930) at vget+0x116
vfs_cache_lookup(edb68b8c,edb68ba8,c0697556,edb68b8c,c0887cd1) at
vfs_cache_lookup+0x2e2
ufs_vnoperate(edb68b8c,c0887cd1,c785e930,c063600d,c785e930)
at ufs_vnoperate+0x18
lookup(edb68c28,0,c0878f12,a6,c785e930) at lookup+0x376
namei(edb68c28,edb68c44,c0669ae3,c0934e80,c0934de0) at
namei+0x27e
lstat(c785e930,edb68d14,c088ff8d,3ee,2) at lstat+0x52
syscall(806002f,805002f,bfbf002f,805e500,805e548) at
syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (190, FreeBSD ELF32, lstat), eip = 0x280c556f,
esp = 0xbfbfebfc, ebp = 0xbfbfec98 ---
db>
--
Ken Smith
- From there to here, from here to |
kensmith at cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
More information about the freebsd-current
mailing list