headers
Yuri | 1 Apr 2012 02:19

Re: Is there any modern alternative to pstack?

On 03/31/2012 14:22, Jason Hellenthal wrote:
> procstat(1)

I don't see which key of procstat(1) displays this information.
The closest key is:
-k  "Display the stacks of kernel threads in the process"
It shows kernel threads, but no user space stacks. How can I get user 
space stacks?

Yuri
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Greg Miller | 1 Apr 2012 22:34
Picon

GSoC mutex contention profiling and lock order verification

The pthread mutex contention profiling and lock order verification
entry on the ideas list caught my eye.

I'm looking for a potential mentor, and any ideas or suggestions about
what's desired in such a tool. The ideas page lists jeff <at>  as a
contact, but I've not gotten a response as yet, so does anyone have an
interest in this, and maybe some suggestions?
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
John Baldwin | 2 Apr 2012 14:31
Picon
Favicon

Re: Is there any modern alternative to pstack?

On Saturday, March 31, 2012 3:41:41 pm Yuri wrote:
> I look at seemingly abandoned sysutils/pstack, last modified upstream 
> 2002-11-27.
> It doesn't really work on 9.0 i386, prints some errors.
> 
> It's functions, though, is quite desirable if one wants to understand 
> why some multithreaded program hangs or is not responsive.
> Since there were no updates, I wonder, is this because there is some 
> alternative in FreeBSD that I don't know about, or it is primarily due 
> to the lack of interest/resources?
> 
> I don't take gdb as alternative since it is not single line, and also it 
> has some threading issues of its own.

Hmm, I don't know if the port has it, but I did some work on pstack a while 
ago to make it work with libthread_db so it at least handles i386 ok.  It 
needs to be modified to use something like libunwind though or some other 
unwinder.  And possibly it should use libelf instead of its own ELF-parsing 
code.

--

-- 
John Baldwin
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 18 comments |
headers
John Baldwin | 2 Apr 2012 17:23
Picon
Favicon

Re: Approaching the limit on PV entries

On Thursday, March 22, 2012 1:48:29 pm Mark Saad wrote:
> On Thu, Mar 22, 2012 at 8:03 AM, John Baldwin <jhb <at> freebsd.org> wrote:
> > On Wednesday, March 21, 2012 4:20:17 pm Mark Saad wrote:
> >> On Wed, Mar 21, 2012 at 12:39 PM, Sergey Kandaurov <pluknet <at> gmail.com> wrote:
> >> > On 21 March 2012 19:19, John Baldwin <jhb <at> freebsd.org> wrote:
> >> >> On Tuesday, March 20, 2012 11:37:57 am Sergey Kandaurov wrote:
> >> >>> On 22 November 2011 19:29, Mark Saad <nonesuch <at> longcount.org> wrote:
> >> >>> > Hello All
> >> >>>
> >> >>> [found this mail in my drafts, not sure if my answer is still useful]
> >> >>>
> >> >>> >  I want to get to the bottom of a warning in dmesg. On 7.2-RELEASE and
> >> >>> > 7.3-RELEASE I have seen the following warning in dmesg.
> >> >>> >
> >> >>> > Approaching the limit on PV entries, consider increasing either the
> >> >>> > vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
> >> >>> >
> >> >>> > So looking around I see a few posts here and there about how to tune
> >> >>> > the sysctls to address the warning however I am not 100% sure what
> >> >>> > each value does.
> >> >>> > It appears changing vm.pmap.shpgperproc affects the value of
> >> >>> > vm.pmap.pv_entry_max . Can someone explain the relationship of the two
> >> >>> > sysctls. Also
> >> >>>
> >> >>> This is how they are calculated.
> >> >>>
> >> >>> pv_entry_max = shpgperproc * maxproc + cnt.v_page_count;
> >> >>>
> >> >>> and, respectively,
> >> >>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yuri | 2 Apr 2012 18:39

Re: Is there any modern alternative to pstack?

On 04/02/2012 05:31, John Baldwin wrote:
> Hmm, I don't know if the port has it, but I did some work on pstack a while
> ago to make it work with libthread_db so it at least handles i386 ok.  It
> needs to be modified to use something like libunwind though or some other
> unwinder.  And possibly it should use libelf instead of its own ELF-parsing
> code.

I see pstack -1.2_1 failing even on i386:

pstack: cannot read context for thread 0x1879f
pstack: failed to read more threads
1947: /usr/local/share/chromium/chrome
----------------- thread 100255 -----------------
  0x1879f ???????? ()

----------------- thread -1 (running) -----------------
  0x389f1df9 __sys_recvmsg (3, bfbfcd44, 0, bfbfcd68, 0, c) + 5
  0x97850b4 _init (3, bfbfcdc8, 800, bfbfdc20, bfbfdc4c, bfbfdc40) + 15c7c1c
  0xa8089d0 _init (bfbfe074, 3, 0, bfbfe0c4, 20, bfbfdca0) + 264b538
  0xa8094d7 _init (bfbfe44c, 0, bfbfe108, 37a85517, 37aa7680, 38fbf400) 
+ 264c03f
  0x8e7ec02 _init (bfbfe44c, bfbfe4a0, 3c, 0, 0, 0) + cc176a
  0x8e7f102 _init (bfbfe468, bfbfe44c, bfbfe4a0, 37a9f4b4, 37aa5d40, 1) 
+ cc1c6a
  0x8e7f471 _init (2, bfbfe540, bfbfe4a0, 88f9c28, bd4dce8, bd4de88) + 
cc1fd9
  0x81c64ab _init (2, bfbfe540, bfbfe4e8, af61795, bfbfe500, bfbfe540) + 
9013
  0x81c6452 _init (0, 0, bfbfe518, 81c63a7, 2, bfbfe540) + 8fba
  0x81c63a7 _init (3791afd0, 2, bfbfe540, 0, 0, 0) + 8f0f
(Continue reading)

Permalink | Reply | 17 comments |
headers
rank1seeker | 2 Apr 2012 18:59
Picon

Upgrading FreeBSD

Basically it consists of (re)compilation and installation of world + kernel
However, 2 parts are always ommited:
Stage 1 - mbr|boot0
Stage 2 - boot
I won't also mention GPT part ...

Stage 3 - loader (is "covered" by world install)

Should it be expanded to world + kernel + bootcodes
The old way, one could pull it's old bootcodes, from 6.0 to 10.0 world + kernel

And bootcodes are changing. I've got bitten by bug in stage 2 boot, during 8.2 -> 9.0.


Domagoj Smolčić
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
John Baldwin | 2 Apr 2012 19:12
Picon
Favicon

Re: Is there any modern alternative to pstack?

On Monday, April 02, 2012 12:39:26 pm Yuri wrote:
> On 04/02/2012 05:31, John Baldwin wrote:
> > Hmm, I don't know if the port has it, but I did some work on pstack a while
> > ago to make it work with libthread_db so it at least handles i386 ok.  It
> > needs to be modified to use something like libunwind though or some other
> > unwinder.  And possibly it should use libelf instead of its own ELF-parsing
> > code.
> 
> I see pstack -1.2_1 failing even on i386:
> 
> pstack: cannot read context for thread 0x1879f
> pstack: failed to read more threads

Yes, threads don't work for modern binaries (newer than 4.x) without my changes
to make it use libthread_db.  You can find the patch I used for this at
http://www.freebsd.org/~jhb/patches/pstack_threads.patch

--

-- 
John Baldwin
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 16 comments |
headers
Jerry Toung | 2 Apr 2012 19:55
Picon

CAM disk I/O starvation

Hello list,
I am convinced that there is a bug in the CAM code that leads to I/O starvation.
I have already discussed this privately with some. I am now bringing this up to
the general audience to get more feedback.

My setup is that I have 1 RAID controller with 2 arrays connected to
it, da0 and da1.
The controller supports 252 tags. After boot up, camcontrol tags on
da0 and da1 shows that both devices have 252 openings each. A process
P0 writing on da0 is dormant most of the time, but would wake up with
burst of I/Os, 5000-6000 ops as reported by gstat.
A process P1 writing on da1 has a fixed data rate to da1 as reported by gstat.

The issue: When P0 generates that burst of 5000-6000 ops, the write
rate of P1 on da1 goes to 0 MB/sec for up to 8-9sec,
vfs.hirunningspace starts climbing and we get into waithirunning() or
getblk() sleep channel. BTW, raising hirunningspace has no effect on
the 0 MB/s behavior.

The first problem that I see here, is that if the sim's devq has 252
alloc_queue and
send_queue, the struct cam_ed representing da0 and da1 should each
have 126 openings and not
252. The second problem is that clearly, there is no I/O fairness in CAM as seen
in gstat output and da0 exclusively takes a hold of the sim/controller
until it has processed all it's I/Os (8-9 seconds). The code that does
this is at

cam/cam_xpt.c:3030
3030             && (devq->alloc_openings > 0)
(Continue reading)

Permalink | Reply | 11 comments |
headers
Doug Barton | 2 Apr 2012 20:06
Picon
Favicon

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

On 03/30/2012 07:41, Joe Greco wrote:
>> On 3/29/2012 7:01 AM, Joe Greco wrote:
>>>> On 3/28/2012 1:59 PM, Mark Felder wrote:
>>>>> FreeBSD 8-STABLE, 8.3, and 9.0 are untested
>>>>
>>>> As much as I'm sensitive to your production requirements, realistically
>>>> it's not likely that you'll get a helpful result without testing a newer
>>>> version. 8.2 came out over a year ago, many many things have changed
>>>> since then.
>>>>
>>>> Doug
>>>
>>> So you're saying that he should have been using 8.3-RELEASE, then.
>>
>> That isn't what I said at all, sorry if I wasn't clear. The OP mentioned
>> 9.0-RELEASE, and in the context of his message (which I snipped) he
>> mentioned 8-stable. That's what I was referring to.
> 
> And since both the poster and I made it clear that this doesn't seem
> to be a case of "it fails reliably on a machine of your choosing",
> just installing random other versions and hoping that it's going to
> cause a fail ... well, let's just say that doesn't make a whole lot
> of sense.  Or at least it's a recipe for a hell of a lot of busywork,
> busywork not guaranteed to return any sort of useful result.

And since you can't reliably reproduce the problem, how do you expect us
to? I understand that these sorts of bugs are difficult/annoying, etc.
Been there, done that.

> In the meantime, it's unrealistic to tell people to use supported
(Continue reading)

Permalink | Reply | 4 comments |
headers
Joe Greco | 2 Apr 2012 20:43

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

> On 03/30/2012 07:41, Joe Greco wrote:
> >> On 3/29/2012 7:01 AM, Joe Greco wrote:
> >>>> On 3/28/2012 1:59 PM, Mark Felder wrote:
> >>>>> FreeBSD 8-STABLE, 8.3, and 9.0 are untested
> >>>>
> >>>> As much as I'm sensitive to your production requirements, realistically
> >>>> it's not likely that you'll get a helpful result without testing a newer
> >>>> version. 8.2 came out over a year ago, many many things have changed
> >>>> since then.
> >>>>
> >>>> Doug
> >>>
> >>> So you're saying that he should have been using 8.3-RELEASE, then.
> >>
> >> That isn't what I said at all, sorry if I wasn't clear. The OP mentioned
> >> 9.0-RELEASE, and in the context of his message (which I snipped) he
> >> mentioned 8-stable. That's what I was referring to.
> > 
> > And since both the poster and I made it clear that this doesn't seem
> > to be a case of "it fails reliably on a machine of your choosing",
> > just installing random other versions and hoping that it's going to
> > cause a fail ... well, let's just say that doesn't make a whole lot
> > of sense.  Or at least it's a recipe for a hell of a lot of busywork,
> > busywork not guaranteed to return any sort of useful result.
> 
> And since you can't reliably reproduce the problem, how do you expect us
> to? I understand that these sorts of bugs are difficult/annoying, etc.
> Been there, done that.

Nobody expected you to.  We're trying to figure out any commonalities
(Continue reading)

Permalink | Reply | 3 comments |

Gmane