In message <E1CuXry-000JJd-OV_at_cs1.cs.huji.ac.il>, Danny Braniss writes: >> In message <20050128144733.GA91982_at_green.homeunix.org>, Brian Fundakowski Feldman writes: >> >On Fri, Jan 28, 2005 at 09:08:54AM +0200, Danny Braniss wrote: >> >> hi, >> >> while running 'dump 0f - /dist | restore rf -' >> >> the dump proc. got stuck, it seems it's waiting on some lock: >> >> >> >> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND >> >> >> >> 0 30924 30922 0 4 0 3396 2852 sbwait T p1 1:00.88 dump: >> >> /dev/amrd0s3h: ... >> >> 0 30925 30924 1 -8 0 3268 2784 physrd TL p1 0:53.84 dump 0f - >> >> /dist (dump) >> >> 0 30926 30924 1 20 0 3268 2784 pause T p1 0:53.69 dump 0f - >> >> /dist (dump) >> >> 0 30927 30924 1 20 0 3268 2784 pause T p1 0:54.12 dump 0f - >> >> /dist (dump) >> >> >> >> (this is 5.3-STABLE, cvs'ed about a week ago, and it's a SMP system). >> >> how can i find which lock? or who is holding it? >> > >> >Is the one in physrd not actually reading anything from the disk right >> >now? I would suspect that should be how you really determine if it's >> >hung or not. You should be able to see how long it's been waiting >> >and how long it's due to wait still, using kgdb. >> >> Check also with gstat(8) if there is I/O activity going on and/or if any >> I/O requests are stuck. > >it's stuck. i.e. not doing anything. i've been monitoring it via >iostat, and nothing is moving, nada, the machine is very idle :-( Please use gstat(8) and look for stuck I/O requests. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk_at_FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.Received on Fri Jan 28 2005 - 14:18:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:27 UTC