Date: Wed, 30 Jul 2003 14:43:25 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: Make long ddb not suck Message-ID: <Pine.BSF.4.21.0307301439170.23956-100000@InterJet.elischer.org> In-Reply-To: <Pine.BSF.4.21.0307301410410.23956-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
answering to myself again.... The main use I have for 'ps' in ddb is when I get a 'hang' and I can get into ddb I use it to try idientify what everything is sleeping on.. if we make ps only show processes then I'd have to do: 'ps' "oh there are 7 KDE/Gnome threaded processess." get paper.. write down pids show threads pid xxx1 show threads pid xxx2 show threads pid xxx3 show threads pid xxx4 show threads pid xxx5 show threads pid xxx6 show threads pid xxx7 to see what everything is waiting on. which is a pain in the neck (particularly when hunting around the machine room looking for a pen and paper) maybe a switch or another command that shows all the wait channels? On Wed, 30 Jul 2003, Julian Elischer wrote: > > > On Wed, 30 Jul 2003, John Baldwin wrote: > > > I have a patch that adds a simple paging facility to ddb at the > > db_printf() level using a one-shot callback mechanism. It includes > > a simple paging callback that rearms itself based on the users > > input (space does another page, enter another line). I've used this > > facility to replace the hand-rolled paging in 'ps', 'show pci', and > > 'show ktr'. The patch is at http://www.FreeBSD.org/~jhb/patches/ddb.patch > > > > Comments? > > > > Also, I notice that we have a 'show threads' command commented out from > > the original Mach sources. I think we should change 'ps' back to just > > showing simple process info (and hopefully back to 80 cols) and only > > print thread info for 'show threads'. Maybe show threads should take a > > PID as the argument? > > > we do have "show thread (addr)" > that shows the stacktrace. > > "show threads {pid}" > would be good to identify the address > of the thread to examine.. > > > > > Thus, one would have: > > > > db> ps > > 1 blah blah sleeping on "foo" > > 2 blah blah threaded > > > > db> show threads 2 > > 0 blah blah sleeping on "bar" > > 1 blah blah running on cpuX > > > > currently ps shows the threads by default.. > either way is ok I guess. > > > etc. > > > > -- > > > > John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0307301439170.23956-100000>