Yuri | 1 Apr 02:19 2012

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"

Aleksander Dutkowski | 1 Apr 20:19 2012
Picon

[GSoC] [ARM] arm cleanup - my own proposal

hello!

after few weeks searching for interesting idea for me, I've decided to
propose my own one. It is already mentioned on IdeasPage:
- ARM cleanup

Why I have chosen this one? I am very interested in embedded world.
Now I am working on porting FBSD to at91sam9g45 - I will be much more
motivated working on arm fbsd project than any other.

Why should you let me do that project? While working on freebsd/arm
I've noticed places that could be optimized, or separated, i.e.
at91_samsize() should be declared for each board separately - now,
this function has if-else and checks, which board is he running on.

I would like to identify and fix that bugs, so the code will be more
efficient and clear. Moreover, I think there should be a
tutorial/framework for adding new boards or SoCs, so I will be
simplier. I am currently reading the code in sys/arm/at91 and
searching for improvements but I will be very pleased, if you send me
your insights.

The first question is - should I cleanup only at91 branch or more? I
am quite familiar with at91 right now.
The second - how to test the code? Some of boards could be tested in
qemu, I could buy board with at91rm9200 for example, if I'm in. But
maybe I will find here people with their own boards, they could help
me testing? I havs sbc6045 board with at91sam9g45 SoC but it hasn't
fbsd support yet (I'm working on it now :) )

(Continue reading)

Greg Miller | 1 Apr 22:34 2012
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"

John Baldwin | 2 Apr 14:31 2012
Picon

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"

John Baldwin | 2 Apr 17:23 2012
Picon

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)

Yuri | 2 Apr 18:39 2012

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)

rank1seeker | 2 Apr 18:59 2012
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"

John Baldwin | 2 Apr 19:12 2012
Picon

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"

Jerry Toung | 2 Apr 19:55 2012
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)

Doug Barton | 2 Apr 20:06 2012
Picon

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)


Gmane