Process stuck in getblk

Peter Holm peter at holm.cc
Thu Mar 24 00:14:38 PST 2005


On Thu, Mar 24, 2005 at 12:26:32AM -0500, Jeff Roberson wrote:
> On Sun, 20 Mar 2005, Peter Holm wrote:
> 
> > With GENERIC HEAD from Mar 18 15:56 UTC I ran into these two
> > problems where a user process seems to be waiting on a lock,
> > that appears to be owned by non-existent thread.

Hey, your back!

> 
> Odd that this is a directory.  Do you know if the other times you were
> able to trigger this were also with directories?
> 

Yes, your right. Grepping throu the crash dumps it appears that
the other getblk problems were related to read or write.

- Peter
> >
> > 5123 [SLPQ getblk 0xc665717c][SLP] mkdir
> >
> > sleepq_switch(c665717c,cf4698c8,c061bcd5,...) at sleepq_switch+0xe0
> > sleepq_wait(c665717c,0,0,2010020,600) at sleepq_wait+0x30
> > msleep(c665717c,c09118dc,50,c083af8f,0) at msleep+0x311
> > acquire(cf469920,2010020,600,c1b2b000,0) at acquire+0xba
> > debuglockmgr(c665717c,2090022,c1e7d5a0,...) at debuglockmgr+0x406
> > getblk(c1e7d500,0,0,800,0) at getblk+0x15a
> > breadn(c1e7d500,0,0,800,0) at breadn+0x58
> > bread(c1e7d500,0,0,800,0) at bread+0x20
> > ffs_blkatoff(c1e7d500,0,0,0,cf469a58) at ffs_blkatoff+0x9e
> > ufs_lookup(cf469b18) at ufs_lookup+0x326
> > VOP_CACHEDLOOKUP_APV(c08cf140,cf469b18) at VOP_CACHEDLOOKUP_APV+0x7e
> > vfs_cache_lookup(cf469b9c) at vfs_cache_lookup+0xd2
> > VOP_LOOKUP_APV(c08cf140,cf469b9c) at VOP_LOOKUP_APV+0x7e
> > lookup(cf469c7c,c0918d80,0,c1b2b000,69f) at lookup+0x362
> > namei(cf469c7c) at namei+0x34a
> > kern_rmdir(c1b2b000,bfbc97d0,0,cf469d40,c07cc3a3) at kern_rmdir+0x3a
> > rmdir(c1b2b000,cf469d14,1,25,292) at rmdir+0x12
> > syscall(2804002f,bfbf002f,bfb8002f,2804f24c,bfbfeb00) at syscall+0x213
> >
> > (kgdb) p (*(struct lock *)0xc665717c)->lk_lockholder->td_state
> > $2 = TDS_INACTIVE
> >
> > http://www.holm.cc/stress/log/cons122.html
> > http://www.holm.cc/stress/log/cons123.html
> > --
> > Peter Holm
> >


More information about the freebsd-current mailing list