Re: [PATCH] Export per-thread resource usage via sysctl

2011-07-16 Thread Pan Tsu
Alexander Best arun...@freebsd.org writes:

 On Fri Jul 15 11, John Baldwin wrote:
 This change exports each individual thread's resource usage via sysctl when 
 individual threads are requested via KERN_PROC_INC_THREAD.  This generally 
 works correctly with 'top -m io' after the previous change to revert top(1) 
 back to using KERN_PROC_PROC when threads are not enabled.  There is one 
 issue 
 in that top doesn't necessarily DTRT when disabling/enabling threads via 'H' 
 at runtime while in io mode.  I may do some further work to clean that up.  
 However, for just top run it will now show per-thread stats instead of 
 duplicating the per-process stats for each thread.

 i'm not sure, if i understand what the patch is supposed to do. however after
 applying it, and recompiling/reinstalling the kernel, 'top -mio' displays the
 same stats for each thread of a process. if i understood you correctly, each
 thread should have individual stats.

 i'm running r224068 on amd64 and just reinstalled 'top'. anything i am 
 missing?

FWIW, I see different numbers for a few threads of firefox-bin with top-3.8b1.

  http://img233.imageshack.us/img233/1570/81482202.png

Which is an improvement compared to how all threads showed same numbers
before applying the patch.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


pmcstat(8) and machdep.hlt_cpus

2011-07-12 Thread Pan Tsu
pmcstat(8) stopped to work for me after largeSMP landed in r222813.
At the time only pmccontrol(8) was updated. Then the next day
machdep.hlt_cpus was ripped out. So, I've assumed it's going to
be fixed by subsequent commits and commented out related code locally.

  $ qemu -smp 2 -nographic ...
  $ kldload hwpmc
  $ pmcstat -S instructions -T
  pmcstat: ERROR: Cannot determine which CPUs are halted: No such file or 
directory
  Exit 71

A month passed, nothing changed. Am I doing smth wrong?

FWIW, smp(4) still documents machdep.hlt_cpus and machdep.hlt_logical_cpus.
It should probably be updated with hint.lapic.X.disabled from UPDATING.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: ZFS boot fails with two pools

2011-07-09 Thread Pan Tsu
Eir Nym eir...@gmail.com writes:

 On 8 July 2011 09:28, Berczi Gabor free...@berczi.be wrote:

 On Jul 7, 2011, at 12:19 PM, Volodymyr Kostyrko wrote:

 2. Try to convince bios to boot from the disk of pool2.

 There is no disk with a singular ZFS pool.

 Any disk from bootable pool.

 Every disk contains two pools. And the BIOS sees only two (maybe three) of 
 them.

 3. You can possibly try deploying /boot/boot0 MBR selector code
 over disks of data pool. Supplied boot0 code can be used to
 choose another disk to jump to it during boot process and will
 remember the last choice.

 I'm not really sure how to do this with GPT. Should I use boot0 instead of 
 pmbr?

 boot0cfg is your old friend

 Cool, how do we get acquinted?

 Actuall I think that code on that stages just tries to boot from the pool 
 on the current disk.

 There are two pools on it...


 gpart(8) can set 'bootme' flag for GPT partition, so there no problem
 to specify from which partition to boot.

Doesn't gptzfsboot probe all `freebsd-zfs' partitions irrespective of
their boot* attributes? A quick search shows why

  $ fgrep -ir bootme sys/boot sys/cddl/boot
  $ grep -wr 'gpt.*(' sys/boot sys/cddl/boot
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: -Qunused-parameter and clang (was Re: GHC Port on 9-CURRENT)

2011-06-28 Thread Pan Tsu
Niclas Zeising zeis...@daemonic.se writes:

 Sorry for hijacking this thread, and cross posting.

 On 2011-06-26 03:07, Gabor PALI wrote:
 
 
 With Clang, an error occurs in one of the configure scripts, because
 Clang warns about unused command-line arguments, and the configure
 script assumes that to be a compiler error.  You can deal with this by
 adding -Qunused-parameter to CFLAGS.
 
 Thanks for investigating this.
 

 This should probably be made the default, at least for ports when clang
 is compiled, since the output generated when not using
 -Qunused-parameter confuses configure scripts, and stops at least
 FireFox 5 from compiling, that I know of.

Do you use ccache? Try without.

For example, the combo confuses libtool

  http://docs.freebsd.org/cgi/mid.cgi?86d3i8b3dc.fsf
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gcc-4.5 and 4.6 needs to be recompiled due to /usr/src/UPDATE: 20110608:

2011-06-09 Thread Pan Tsu
Hartmann, O. ohart...@zedat.fu-berlin.de writes:

 Since the notice mentioned in /usr/src/UPDATE (20110608) both gcc-4.5
 and 4.6 seems to need to be recompiled. I tried some ports with
 USE_FORTRAN= yes setand they failed as with gcc-4.6. There was
 always an error reporting: undefined reference to __cpumask_t or
 similar.

Do you mean stale typedef in gcc's private copy under
  PREFIX/lib/gccXY/gcc/*/*/include-fixed/sys/types.h ?

You can fix the file manually instead of wasting cpu cycles.

  $ gcc46 foo.c
  In file included from 
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.1/include-fixed/unistd.h:46:0,
   from foo.c:1:
  
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.1/include-fixed/sys/types.h:111:1:
 error: unknown type name '__cpumask_t'
  Exit 1

  $ sed -n 111p 
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.1/include-fixed/sys/types.h
  typedef __cpumask_t cpumask_t;
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: 8-STABLE /usr/include/utmp.h and tmpx

2011-06-04 Thread Pan Tsu
Aryeh Friedman aryeh.fried...@gmail.com writes:

 Some time in the last 2 weeks (I am sure when) a commit caused many
 ports that assume a standard utmp/utmp.x to break for example
 x11-toolkits/vte produces:

I guess it's a user error, utmpx.h and utmp.h shouldn't both be present.
See similar issue

  http://lists.freebsd.org/pipermail/freebsd-ports/2010-September/063733.html

 gnome-pty-helper.c:497: warning: passing argument 4 of 'pty_add'
 discards qualifiers from pointer target type
 mv -f .deps/gnome-pty-helper.Tpo .deps/gnome-pty-helper.Po
 cc -DHAVE_CONFIG_H -I.   -I/usr/local/include  -O2 -pipe
 -march=prescott -fno-strict-aliasing -MT gnome-utmp.o -MD -MP -MF
 .deps/gnome-utmp.Tpo -c -o gnome-utmp.o gnome-utmp.c
 gnome-utmp.c: In function 'write_login_record':
 gnome-utmp.c:367: warning: passing argument 1 of 'login' from
 incompatible pointer type
 gnome-utmp.c:374: error: 'struct utmpx' has no member named 'ut_name'

If you're on /stable/8 try removing leftover includes from /head by
reinstalling /usr/include, e.g.

  $ mv /usr/include /usr/include.old
  $ make distrib-dirs installincludes -C/usr/src

  # a list of files that shouldn't be there
  $ mtree -klink -cinp /usr/include.old old.mtree
  $ mtree -klink -cinp /usr/include new.mtree
  $ diff -u old.mtree new.mtree

struct utmpx shouldn't be used on /stable/8 as there is no utmpx.h.

  # from vte-0.26.2/gnome-pty-helper/acinclude.m4
  AC_CHECK_HEADERS(sys/time.h utmp.h utmpx.h)

  if test $ac_cv_header_utmpx_h = yes; then
  AC_DEFINE(UTMP,[struct utmpx],[Define to the name of a structure which 
holds utmp data.])
  else
  AC_DEFINE(UTMP,[struct utmp],[Define to the name of a structure which 
holds utmp data.])
  fi

And if you're on /head then stale utmp.h should be removed, e.g.

  $ make delete-old -C/usr/src

making the port use ut_user instead of ut_name.

 This is not the only port that has the issue but it is the only one I
 remember off the top of my head (I manually fixed a few others)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: ZFS install from -CURRENT snapshot

2011-05-30 Thread Pan Tsu
George Kontostanos gkontos.m...@gmail.com writes:

 *zpool import -c /tmp/zpool.cache zroot
 can not import /tmp/zpool.cache no such pool available

Try modifying pool's property:

  $ zpool import -o cachefile=/tmp/zpool.cache zroot

 Well, it seems that -c switch is for specifying where to read from and not
 where to write. I haven't been able to import the pool and find a way to
 store zpool.cache in a diffrent place other than /boot/zfs
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Clang error make buildworld

2011-05-06 Thread Pan Tsu
Olivier Smedts oliv...@gid0.org writes:

 2011/5/5 Roman Divacky rdiva...@freebsd.org:
 Because with clang, -march=native often breaks buildworld, while
 -march=core2 is ok.

 Can you be more specific about this claim? On what CPU are seeing
 this breakage?

 Ok, with latest HEAD...

 %echo | gcc -march=native -E -v -x c -### -
 Using built-in specs.
 Target: amd64-undermydesk-freebsd
 Configured with: FreeBSD/amd64 system compiler
 Thread model: posix
 gcc version 4.2.2 20070831 prerelease [FreeBSD]
  /usr/libexec/cc1 -E -quiet -v -D_LONGLONG -
 -march=core2 -mtune=generic

 With -march=native, gcc adds -mtune=generic while the man pages
 says -march=xxx sets -mtune=xxx.

No longer true for `-march=native' on more recent GCC versions.

  $ gcc46 -v -march=native foo.c | fgrep cc1 # C2D E8400
   ...-march=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32
   --param l1-cache-line-size=64 --param l2-cache-size=6144
   -mtune=core2...

  $ gcc46 -v -march=core2 foo.c | fgrep cc1
   ...-march=core2...

  $ clang -v -march=native foo.c | grep -o -- '-target-cpu \w*'
  -target-cpu penryn
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: xterm termcape :ti@:te@:

2011-04-24 Thread Pan Tsu
Randy Bush ra...@psg.com writes:

 i know i a perverted, but i really prefer not to have ca_mode.  i.e.

Not to? But the patch makes the opposite effect.

 prior to 9, i had this little patch

 *** termcap.FCS Tue Jun 17 15:10:46 2003
 --- termcap Tue Jun 17 15:14:15 2003
 ***
 *** 299,305 
   adm3|3|lsi adm3:\
   :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80:
   xterm|xterm-color|X11 terminal emulator:\
 !   :ti@:te@:tc=xterm-xfree86:
   #
   # DESCRIPTION:
   # This file describes capabilities of various terminals, as needed by
 --- 299,305 
   adm3|3|lsi adm3:\
   :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80:
   xterm|xterm-color|X11 terminal emulator:\
 !   :tc=xterm-xfree86:
   #
   # DESCRIPTION:
   # This file describes capabilities of various terminals, as needed by

 which no longer works.

Use FreeBSD-specific `xterm-clear' termcap record, e.g.

  $ xterm -xrm 'XTerm.termName: xterm-clear' # or add to ~/.Xdefaults

or alter xterm alias to point to it so that ca_mode works even if you
ssh to Linux box that doesn't have the record.

%%
Index: share/termcap/termcap.src
===
--- share/termcap/termcap.src   (revision 220998)
+++ share/termcap/termcap.src   (working copy)
@@ -3011,7 +3011,7 @@
 # is widely used for a variety of incompatible terminal emulations including
 # color_xterm and rxvt.
 xterm|X11 terminal emulator:\
-   :tc=xterm-new:
+   :tc=xterm-clear:
 #  :tc=xterm-r6:
 # dtterm termcap entry - Obtained from Xinside's CDE with permission
 # from Thomas Roell
%%
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: xterm termcape :ti@:te@:

2011-04-24 Thread Pan Tsu
Thomas Dickey dic...@radix.net writes:

[...]
 Setting the titeInhibit resource cancels those 1049's, but unsetting
 it doesn't add them.

xterm-basic in /head doesn't define ti/te capabilities anymore per r200503.
So, there is no more need to hide them via `@', e.g. `:ti@:te@:' in `xterm'.

  $ getcap -c ti -f /etc/termcap xterm-basic || tset -S xterm-basic | sed 
'y/:/\n/' | fgrep ti

It was probably too minor of an issue to be mentioned in UPDATING.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] ifconfig(8) flag to display IPv4 netmasks in dot-decimal format

2011-04-12 Thread Pan Tsu
Sergey Vinogradov boo...@lazybytes.org writes:

 Hi,
 I've written a tiny-tiny patch, which adds the '-t' flag to
 ifconfig(8). It modifies the output to display IPv4 netmasks in dotted
 decimal notation:
[...]
 % ifconfig -t msk0
[...]
 inet 10.10.0.1 netmask 255.255.255.0 broadcast 10.10.0.255

Isn't netstat(8) a better place for such an option? domask() already
converts netmask to CIDR notation if possible, e.g. `netstat -ni'

   10.10.0.1/24
   10.10.0.10xff00ff00

Unfortunately, Network column is always truncated to 13 characters even
with -W flag while it can be up to 26 characters long with `-n' flag or
more with a symbolic network name.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org