Building world with WITHOUT_SSP set broken?
Hi there, I just tried to do a buildworld with a current svn checkout (r286978). However it appears that world fails with WITHOUT_SSP set. I'm currently running r284582, so the SSP issue must have been introduced somewhere between those two revision. Cheers Alexander Here's the error log: stage 2.3: build tools -- cd /usr/subversion-src; MAKEOBJDIRPREFIX=/usr/obj INSTALL=sh /usr/subversion-src/tools/install.sh PATH=/usr/obj/usr/subversion-src/tmp/legacy/usr/sbin:/usr/obj/usr/subversion-src/tmp/legacy/usr/bin:/usr/obj/usr/subversion-src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/subversion-src/tmp VERSION=FreeBSD 11.0-CURRENT amd64 1100079 MAKEFLAGS=-m /usr/subversion-src/tools/build/mk -m /usr/subversion-src/share/mk make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 DESTDIR= BOOTSTRAPPING=1100077 SSP_CFLAGS= -DNO_LINT -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FULL=no MK_LLDB=no MK_TESTS=no build-tools === bin/csh (obj,build-tools) === bin/sh (obj,build-tools) cc -O2 -pipe -DSTRIP_FBSDID -DSHELL -I. -I/usr/subversion-src/bin/sh -std=gnu99 -Qunused-arguments -I/usr/obj/usr/subversion-src/tmp/legacy/usr/include -c /usr/subversion-src/bin/sh/mknodes.c -o mknodes.o cc -O2 -pipe -DSTRIP_FBSDID -DSHELL -I. -I/usr/subversion-src/bin/sh -std=gnu99 -Qunused-arguments -I/usr/obj/usr/subversion-src/tmp/legacy/usr/include -L/usr/obj/usr/subversion-src/tmp/legacy/usr/lib mknodes.o -o mknodes /usr/bin/ld: cannot find libssp_nonshared.a cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[3]: stopped in /usr/subversion-src/bin/sh *** Error code 1 Stop. make[2]: stopped in /usr/subversion-src *** Error code 1 Stop. make[1]: stopped in /usr/subversion-src *** Error code 1 Stop. make: stopped in /usr/subversion-src pgpruB25_BDD8.pgp Description: PGP signature
Re: Are clang unsigned comparison warnings in kern/kern_* ok?
On Wed Sep 5 12, Eir Nym wrote:
I've got following warnings [no errors had been generated while
-Werror is in command line] and want to know if they are ok. There are
much more same warnings in modules, but I worry about kernel :
Kernel config: http://eroese.org/_/_/pub/bsd/240070/GENERIC_PF.amd64
src.conf: http://eroese.org/_/_/pub/bsd/240070/src.conf
make.conf: /dev/null
kernel build logs:
http://eroese.org/_/_/pub/bsd/240070/kernel.amd64.GENERIC_PF
yes these are OK. clang complains about variables that were defined as
unsigned, but are being compared against 0. since those variables cannot be
negative, comparing them against 0 makes no sence (hence
-Wtautological-compare as name to define this group of warnings).
in theory calng is right, however in practice there might be good reasons to
do so:
1) as a general safety belt to make programmers feel comfortable
2) the check might be there, because in the future it is being planed to switch
a certain variable from unsigned to signed
3) a variable type might be unsigned on one platform per default (no signed or
unsigned keyword used), but might be signed on another. doing the 0 check
prevents programmers from having to deal with both cases.
you can disable these warnings for clang by setting -Wno-tautological-compare.
no idea however what var to put it in. CWARNFLAGS+= in src.conf maybe.
cheers.
alex
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I.
-I/usr/head/src/sys -I/usr/head/src/sys/contrib/altq -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-Werror /usr/head/src/sys/kern/kern_cpuset.c
/usr/head/src/sys/kern/kern_cpuset.c:654:16: warning: comparison of
unsigned expression 0 is always false [-Wtautological-compare]
for (i = 0; i (_NCPUWORDS - 1); i++) {
~ ^
1 warning generated.
/usr/head/src/sys/kern/kern_poll.c:173:10: warning: comparison of
unsigned expression 0 is always false [-Wtautological-compare]
if (val 0 || val 99)
~~~ ^ ~
1 warning generated.
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I.
-I/usr/head/src/sys -I/usr/head/src/sys/contrib/altq -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-Werror /usr/head/src/sys/kern/kern_umtx.c
/usr/head/src/sys/kern/kern_umtx.c:3312:19: warning: comparison of
unsigned expression 0 is always false [-Wtautological-compare]
if (ts32.tv_sec 0 ||
~~~ ^ ~
/usr/head/src/sys/kern/kern_umtx.c:3314:20: warning: comparison of
unsigned expression 0 is always false [-Wtautological-compare]
ts32.tv_nsec 0)
^ ~
/usr/head/src/sys/kern/kern_umtx.c:3338:25: warning: comparison of
unsigned expression 0 is always false [-Wtautological-compare]
if (t32.timeout.tv_sec 0 ||
~~ ^ ~
/usr/head/src/sys/kern/kern_umtx.c:3339:63: warning: comparison of
unsigned expression 0 is always false [-Wtautological-compare]
t32.timeout.tv_nsec = 10 || t32.timeout.tv_nsec 0)
~~~ ^ ~
4 warnings generated.
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I.
-I/usr/head/src/sys -I/usr/head/src/sys/contrib/altq -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-Werror /usr/head/src/sys/kern/uipc_syscalls.c
/usr/head/src/sys/kern/uipc_syscalls.c:356:16: warning: comparison of
unsigned
Re: howto debug a complete hard reset
On Sat Apr 14 12, Jeremie Le Hen wrote: On Sat, Apr 14, 2012 at 08:59:42AM -0400, Robert Huff wrote: This is probably a sysctl handler that is causing the reboot. You can run this one-liner to spot the culprit (use sh): for i in $(sysctl -Na); do sysctl $i ~/sysctl.out; sync; done Each sysctl will be called in turn and the output is appended to a file, but the file will forcibly written to the disk before the next occurence. Um ... it is my understanding sync(8) does not guarantee pending i/o will be written before it returns, but merely requests this happen irrespective of when it would normally occur. An I mistaken? Honestly I don't know, but I have do admit that the small paragraph in the BUGS section of the sync(2) manpage is a little bit shivering: BUGS The sync() system call may return before the buffers are completely flushed. Can any enlightened person answer this? sync(2) does REQUEST an immediate write to disk. however for this to actually be the case, one has to disable softupdates and disable the write cache of that particular disk. the write cache of hdds is enabled by default, because disabling it will give you a huge performance drop. there's a small section about this in tuning(7). cheers. alex ps: SU+J also mustn't be enabled for immediate writes to happen. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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
installworld and delete-old fighting a constant battle
hi there, while installing world with DESTDIR!=/ and running delete-old afterwards, i noticed the following entries. if i'm not mistaken delete-old should not need to delete anything, because DESTDIR was completely empty before running installworld: Removing old files (only deletes safe to delete libs) remove /usr/obj/TESTDIR/usr/share/man/man3/archive_entry_hardlink_w.3.gz? y remove /usr/obj/TESTDIR/usr/share/man/man3/archive_entry_symlink_w.3.gz? y Old files removed Removing old directories /usr/obj/TESTDIR/usr/include/fs/fifofs /usr/obj/TESTDIR/usr/include/lwres /usr/obj/TESTDIR/usr/share/doc/bind9/arm /usr/obj/TESTDIR/usr/share/doc/bind9/misc /usr/obj/TESTDIR/usr/share/doc/bind9 Old directories removed my src.conf contains the following entries: BOOT2_UFS=UFS2_ONLY # don't need UFS1 support anymore GPTBOOT_UFS=UFS2_ONLY # don't need UFS1 support anymore WITHOUT_ACCT=true WITHOUT_AMD=true WITHOUT_APM=true WITHOUT_AT=true WITHOUT_ATM=true WITHOUT_AUDIT=true WITHOUT_BIND=true WITHOUT_GPIO=true WITH_BSD_GREP=true WITHOUT_BSNMP=true WITHOUT_CALENDAR=true WITHOUT_CAPSICUM=true WITHOUT_CTM=true WITHOUT_CVS=true WITHOUT_FLOPPY=true WITHOUT_FREEBSD_UPDATE=true WITHOUT_GAMES=true WITHOUT_GPIB=true WITHOUT_HTML=true WITH_IDEA=true WITHOUT_INET6=true WITHOUT_IPFILTER=true WITHOUT_IPFW=true WITHOUT_IPX=true WITHOUT_JAIL=true WITHOUT_KERBEROS=true WITH_LIBCPLUSPLUS=true WITHOUT_LPR=true WITHOUT_NDIS=true WITHOUT_NETCAT=true WITHOUT_NIS=true WITHOUT_NLS=true WITHOUT_NLS_CATALOGS=true WITHOUT_NS_CACHING=true WITHOUT_PAM_SUPPORT=true WITHOUT_PF=true WITHOUT_PPP=true WITHOUT_PROFILE=true WITHOUT_QUOTAS=true WITHOUT_RCMDS=true WITHOUT_RCS=true WITHOUT_ROUTED=true WITHOUT_SHAREDOCS=true WITHOUT_SSP=true WITHOUT_SYSINSTALL=true WITHOUT_TCSH=true WITHOUT_TELNET=true WITHOUT_ZFS=true cheers. alex ___ 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: setting CC/CXX/CPP unconditionally in src.conf
On Tue Feb 28 12, Chuck Burns wrote:
On 2/28/2012 4:55 PM, Ade Lovett wrote:
On 2/28/2012 14:11, Alexander Best wrote:
any chance we can have a CFLAGS.gcc and CFLAGS.clang in the future?
that would
make certain things a lot easier. dealing with gcc specific options,
such as
-mpreferred-stack-boundary=2 would simply work by setting
CFLAGS.gcc=-mpreferred-stack-boundary=2 e.g.
You already can:
CFLAGS.cc= cc_cflags_here
CFLAGS.clang= clang_cflags_here
CFLAGS+= generic_cflags_here
CFLAGS+= ${CFLAGS.${CC}}
-aDe
I think was asking for adding a third...
.cc for base gcc
.clang for .. clang..
and .gcc for ports gcc4x
..
At least, thats how I read it, I could be wrong, it's happened before.
no you're right. ade's example suits users very well who want to use it in
their src.conf. however what i had in mind was something that can be put into
the makefiles by developers and which is implemented in *.mk mannor.
cheers.
alex
Chuck
___
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: setting CC/CXX/CPP unconditionally in src.conf
On Tue Feb 28 12, Dimitry Andric wrote: On 2012-02-26 22:37, Alexander Best wrote: any chance support for setting CC/CXX/CPP unconditionally in src.conf could be added before the release of freebsd 10.0? the way it is done atm is really not intuitive. the rule should really be: - make.conf = applies globally - src.conf = applies only to /usr/src ( maybe a ports.conf or port.conf could be introduced at some point, too) ... the current situation, where only certain variables can be set in src.conf is not ideal. I just committed r232263 to head, which should allow setting CC/CXX/CPP in src.conf. Please try it out. it seems the latest libarchive import broke world with clang and without NO_WERROR=. i'm now trying with NO_WERROR= set. cheers. alex ___ 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: setting CC/CXX/CPP unconditionally in src.conf
On Tue Feb 28 12, Dimitry Andric wrote: On 2012-02-26 22:37, Alexander Best wrote: any chance support for setting CC/CXX/CPP unconditionally in src.conf could be added before the release of freebsd 10.0? the way it is done atm is really not intuitive. the rule should really be: - make.conf = applies globally - src.conf = applies only to /usr/src ( maybe a ports.conf or port.conf could be introduced at some point, too) ... the current situation, where only certain variables can be set in src.conf is not ideal. I just committed r232263 to head, which should allow setting CC/CXX/CPP in src.conf. Please try it out. any chance we can have a CFLAGS.gcc and CFLAGS.clang in the future? that would make certain things a lot easier. dealing with gcc specific options, such as -mpreferred-stack-boundary=2 would simply work by setting CFLAGS.gcc=-mpreferred-stack-boundary=2 e.g. cheers. alex ___ 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: setting CC/CXX/CPP unconditionally in src.conf
On Tue Feb 28 12, Alexander Best wrote: On Tue Feb 28 12, Dimitry Andric wrote: On 2012-02-26 22:37, Alexander Best wrote: any chance support for setting CC/CXX/CPP unconditionally in src.conf could be added before the release of freebsd 10.0? the way it is done atm is really not intuitive. the rule should really be: - make.conf = applies globally - src.conf = applies only to /usr/src ( maybe a ports.conf or port.conf could be introduced at some point, too) ... the current situation, where only certain variables can be set in src.conf is not ideal. I just committed r232263 to head, which should allow setting CC/CXX/CPP in src.conf. Please try it out. it seems the latest libarchive import broke world with clang and without NO_WERROR=. i'm now trying with NO_WERROR= set. with NO_WERROR= set buildworld succeeded. cheers. alex cheers. alex ___ 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: [RFT] Major snd_hda rewrite
On Thu Jan 12 12, Rainer Hurling wrote: On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote: On 01/12/12 12:52, Gary Jennejohn wrote: On Wed, 11 Jan 2012 21:33:17 +0200 Alexander Motinm...@freebsd.org wrote: I would like request for testing of my work on further HDA sound driver improvement. [big snip] Patch can be found here: http://people.freebsd.org/~mav/hda.rewrite.patch Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and 8-STABLE branches also. The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes in size (mostly the section which deletes all the manufacturer-specific defines at the top of the file). That is probably because of $FreeBSD$ macro resolution. Here is version with present value from 10-CURRENT SVN (sources from CVS or STABLE will need that patch line modified respectively) and some minor additional improvements like CODEC ODs and some more sysctls: http://people.freebsd.org/~mav/hda.rewrite2.patch maybe you could try silencencing these clang warnings? /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5707:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security] snprintf(buf, buflen, chans = 4.0); ^ /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5709:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security] snprintf(buf, buflen, chans = 5.1); ^ /usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5711:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security] snprintf(buf, buflen, chans = 7.1); ^~ /usr/subversion-src/sys/dev/sound/pci/hda/hdacc.c:563:52: warning: if statement has empty body [-Wempty-body] if ((child = codec-streams[dir][stream]) != NULL); ^ 4 warning generated. ..i'll report how the changes interact with my system later on. cheers. alex I just patched 10.0-CURRENT (amd64) r230009 against hda.rewrite2.patch. All went fine so far. My box is now running again with following messages: hdacc0: NVidia (Unknown) HDA CODEC at cad 0 on hdac0 hdaa0: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc0 pcm0: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0 hdacc1: NVidia (Unknown) HDA CODEC at cad 1 on hdac0 hdaa1: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm1: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1 hdacc2: NVidia (Unknown) HDA CODEC at cad 2 on hdac0 hdaa2: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc2 pcm2: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2 hdacc3: NVidia (Unknown) HDA CODEC at cad 3 on hdac0 hdaa3: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc3 pcm3: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3 hdacc4: Realtek ALC892 HDA CODEC at cad 0 on hdac1 hdaa4: Realtek ALC892 HDA CODEC Audio Function Group at nid 1 on hdacc4 pcm4: Realtek ALC892 HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 20,22,23,21 and 24,26 on hdaa4 pcm5: Realtek ALC892 HDA CODEC PCM (Front Analog) at nid 27 and 25 on hdaa4 pcm6: Realtek ALC892 HDA CODEC PCM (Rear Digital) at nid 30 on hdaa4 pcm7: Realtek ALC892 HDA CODEC PCM (Onboard Digital) at nid 17 on hdaa4 I am using pcm4 with 5.1 surround sound and pulseaudio. All seems to work fine :-) The mainboard is an Asus M4A88TD-V EVO/USB3, the graphics card is a NVidia GeForce GTS 450. The Realtek ALC892 is regocnized by the driver, the NVidia HDMI sound device is not. I am looking forward to the commit of this patch! After fixing that per hand I was able to make a kernel with which sound still works. Here the relevant bits from dmesg: hdac0:NVidia (Unknown) HDA Controller mem 0xfcffc000-0xfcff irq 18 at device 0.1 on pci1 hdac1:ATI SB600 HDA Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdacc0:NVidia GT21x HDA CODEC at cad 0 on hdac0 hdaa0:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc0 pcm0:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0 hdacc1:NVidia GT21x HDA CODEC at cad 1 on hdac0 hdaa1:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm1:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1 hdacc2:NVidia GT21x HDA CODEC at cad 2 on hdac0 hdaa2:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc2 pcm2:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2 hdacc3:NVidia GT21x HDA CODEC at cad 3 on hdac0 hdaa3:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc3 pcm3:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3 hdacc4:Realtek ALC889A HDA CODEC at cad 0 on hdac1
Re: [RFT] Major snd_hda rewrite
On Sat Jan 14 12, Alexander Motin wrote:
On 01/14/12 15:48, Alexander Best wrote:
On Thu Jan 12 12, Rainer Hurling wrote:
On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote:
On 01/12/12 12:52, Gary Jennejohn wrote:
On Wed, 11 Jan 2012 21:33:17 +0200
Alexander Motinm...@freebsd.org wrote:
I would like request for testing of my work on further HDA sound driver
improvement.
[big snip]
Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch
Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.
The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes
in size (mostly the section which deletes all the manufacturer-specific
defines at the top of the file).
That is probably because of $FreeBSD$ macro resolution. Here is version
with present value from 10-CURRENT SVN (sources from CVS or STABLE will
need that patch line modified respectively) and some minor additional
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch
maybe you could try silencencing these clang warnings?
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5707:25: warning: format
string is not a string literal (potentially insecure) [-Wformat-security]
snprintf(buf, buflen, chans = 4.0);
^
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5709:25: warning: format
string is not a string literal (potentially insecure) [-Wformat-security]
snprintf(buf, buflen, chans = 5.1);
^
/usr/subversion-src/sys/dev/sound/pci/hda/hdaa.c:5711:25: warning: format
string is not a string literal (potentially insecure) [-Wformat-security]
snprintf(buf, buflen, chans = 7.1);
^~
/usr/subversion-src/sys/dev/sound/pci/hda/hdacc.c:563:52: warning: if
statement has empty body [-Wempty-body]
if ((child = codec-streams[dir][stream]) != NULL);
^
4 warning generated.
..i'll report how the changes interact with my system later on.
Thank you! That variable is not even used now, so I'll just remove that
assignment. I've passed the code through the clang static analyzer at
some point, but probably I've introduced that later.
thanks. :)
the patch works great for me, too.
dmesg -a:
hdacc0: Realtek ALC889A HDA CODEC at cad 2 on hdac0
hdaa0: Realtek ALC889A HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0: Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 20,22,21,23
and 24,26 on hdaa0
pcm1: Realtek ALC889A HDA CODEC PCM (Front Analog) at nid 27 and 25 on hdaa0
pcm2: Realtek ALC889A HDA CODEC PCM (Rear Digital) at nid 30 and 31 on hdaa0
cat /dev/sndstat:
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0: Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) on hdaa0
(1p:1v/2r:1v) default
snddev flags=0x2e6AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC
[pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x2108,
0x0004
interrupts 1274, underruns 0, feed 1274, ready 0
[b:16384/8192/2|bs:16384/8192/2]
channel flags=0x2108TRIGGERED,BUSY,HAS_VCHAN
{userland} - feeder_mixer(0x00200010) - {hardware}
pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 44100/48000, fmt
0x00200010, flags 0x112c, 0x0029, pid 927 (musicpd)
interrupts 0, underruns 0, feed 1859, ready 65536
[b:0/0/0|bs:65536/8192/8]
channel flags=0x112cRUNNING,TRIGGERED,SLEEPING,BUSY,VIRTUAL
{userland} - feeder_root(0x00200010) - feeder_volume(0x00200010) -
feeder_rate(0x00200010 q:1 44100 - 48000) - {hardware}
[pcm0:record:dsp0.r0]: spd 48000, fmt 0x00200010, flags 0x2100,
0x0005
interrupts 0, overruns 0, feed 0, hfree 16384, sfree 16384
[b:16384/8192/2|bs:16384/8192/2]
channel flags=0x2100BUSY,HAS_VCHAN
{hardware} - feeder_root(0x00200010) - feeder_mixer(0x00200010) -
{userland}
[pcm0:record:dsp0.r1]: spd 8000, fmt 0x0018, flags 0x,
0x
interrupts 0, overruns 0, feed 0, hfree 65536, sfree 0
[b:65536/32768/2|bs:0/0/0]
channel flags=0x0
{hardware} - feeder_root(0x) - {userland}
pcm0:record:dsp0.r0[pcm0:virtual:dsp0.vr0]: spd 8000, fmt 0x0018,
flags 0x1000, 0x
interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0]
channel flags=0x1000VIRTUAL
{hardware} - feeder_root(0x) - {userland}
pcm1: Realtek ALC889A HDA CODEC PCM (Front Analog) on hdaa0 (1p:1v/1r:1v)
snddev flags=0x2e6AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC
[pcm1:play:dsp1.p0]: spd 48000, fmt 0x00200010, flags 0x2100,
0x0004
interrupts 0, underruns 0, feed 0, ready 0
CXXFLAGS example in share/examples/etc/make.conf should to be updated
hi there, would it be possible to update the CXXFLAGS example in share/examples/etc/make.conf? looking at the gcc(1) man page, -fconserve-space seems to be a bad example. can somebody thing of a C++ specific option which makes more sense? or maybe something like -Weffc++? although idealy this should go into the (non-existing) CXXWARNSFLAGS. cheers. alex ___ 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: [rfc] removing/conditionalising WERROR= in Makefiles
On Tue Dec 27 11, Philip Paeps wrote:
On 2011-12-26 10:10:40 (+), Alexander Best arun...@freebsd.org wrote:
i grep'ed through src/sys and found several places where WERROR= was set in
order to get rid of the default -Werror setting. i tried to remove those
WERROR= overrides from any Makefile, where doing so did not break tinderbox.
in those cases, where it couldn't be completely removed, i added conditions
to
only set WERROR= for the particular achitecture or compiler, where tinderbox
did not suceed without the WERROR=.
Wouldn't it be better to set WARNS=x rather than WERROR=? WERROR= says this
code has bugs, it breaks tinderbox whereas WARNS=x says this code has the
following kind of bugs which break tinderbox.
Possibly wrapped in an architecture-test where appropriate.
well there are a few issues here:
1) Jan Beich informed me via a private email that enclosing WERROR in arch
specific conditions is a bad idea. if the code gets ported to a new
architecture WERROR doesn't get set and so for every new architecture one
has to evaluate again, whether WERROR needs to be set or not.
so i'm inclined to agree with dim@ that we should not add architecture
specific conditions -- however i think adding compiler specific conditions
is a good idea.
2) the problem with settings WARNS= or specific -Wno-X or -Wno-error=X is that
expecially GCC doesn't have specific -WX flags for certain warnings. some
warnings are implied by -Wall and cannot be turned off seperately. so in
order to get rid of these warnings (which are being handled as errors), we
would need to disable -Wall. and i think setting WERROR= in order to handle
all warnings for specific code as warnings rather than as errors is the
better solution.
i've reworked the patch to only remove WERROR=, where it is not needed anymore
for any supported arch, or where it can be wrapped in a compiler condition.
cheers.
alex
- Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Index: sys/modules/xfs/Makefile
===
--- sys/modules/xfs/Makefile(revision 228911)
+++ sys/modules/xfs/Makefile(working copy)
@@ -6,8 +6,6 @@
KMOD= xfs
-WERROR=
-
SRCS = vnode_if.h \
xfs_alloc.c \
xfs_alloc_btree.c \
Index: sys/modules/sound/driver/maestro/Makefile
===
--- sys/modules/sound/driver/maestro/Makefile (revision 228911)
+++ sys/modules/sound/driver/maestro/Makefile (working copy)
@@ -5,6 +5,5 @@
KMOD= snd_maestro
SRCS= device_if.h bus_if.h pci_if.h
SRCS+= maestro.c
-WERROR=
.include bsd.kmod.mk
Index: sys/modules/aic7xxx/ahd/Makefile
===
--- sys/modules/aic7xxx/ahd/Makefile(revision 228911)
+++ sys/modules/aic7xxx/ahd/Makefile(working copy)
@@ -4,7 +4,6 @@
.PATH: ${.CURDIR}/../../../dev/aic7xxx
KMOD= ahd
-WERROR=
GENSRCS= aic79xx_seq.h aic79xx_reg.h
REG_PRINT_OPT=
AHD_REG_PRETTY_PRINT=1
Index: sys/modules/agp/Makefile
===
--- sys/modules/agp/Makefile(revision 228911)
+++ sys/modules/agp/Makefile(working copy)
@@ -20,7 +20,6 @@
SRCS+= device_if.h bus_if.h agp_if.h pci_if.h
SRCS+= opt_agp.h opt_bus.h
MFILES=kern/device_if.m kern/bus_if.m dev/agp/agp_if.m dev/pci/pci_if.m
-WERROR=
EXPORT_SYMS= agp_find_device \
agp_state \
Index: sys/modules/bios/smapi/Makefile
===
--- sys/modules/bios/smapi/Makefile (revision 228911)
+++ sys/modules/bios/smapi/Makefile (working copy)
@@ -6,7 +6,6 @@
KMOD= smapi
SRCS= smapi.c smapi_bios.S \
bus_if.h device_if.h
-WERROR=
.if ${CC:T:Mclang} == clang
# XXX: clang integrated-as doesn't grok 16-bit assembly yet
CFLAGS+= ${.IMPSRC:T:Msmapi_bios.S:C/^.+$/-no-integrated-as/}
Index: sys/modules/nve/Makefile
===
--- sys/modules/nve/Makefile(revision 228911)
+++ sys/modules/nve/Makefile(working copy)
@@ -7,7 +7,9 @@
device_if.h bus_if.h pci_if.h miibus_if.h \
os+%DIKED-nve.h
OBJS+= nvenetlib.o
+.if ${CC:T:Mclang} == clang
WERROR=
+.endif
CLEANFILES+= nvenetlib.o os+%DIKED-nve.h
nvenetlib.o: ${.CURDIR}/../../contrib/dev/nve/${MACHINE}/${.TARGET}.bz2.uu
___
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: [rfc] removing/conditionalising WERROR= in Makefiles
On Tue Dec 27 11, Luigi Rizzo wrote:
On Tue, Dec 27, 2011 at 11:27:43AM +, Alexander Best wrote:
On Tue Dec 27 11, Philip Paeps wrote:
On 2011-12-26 10:10:40 (+), Alexander Best arun...@freebsd.org
wrote:
i grep'ed through src/sys and found several places where WERROR= was
set in
order to get rid of the default -Werror setting. i tried to remove those
WERROR= overrides from any Makefile, where doing so did not break
tinderbox.
in those cases, where it couldn't be completely removed, i added
conditions to
only set WERROR= for the particular achitecture or compiler, where
tinderbox
did not suceed without the WERROR=.
Wouldn't it be better to set WARNS=x rather than WERROR=? WERROR= says
this
code has bugs, it breaks tinderbox whereas WARNS=x says this code has
the
following kind of bugs which break tinderbox.
Possibly wrapped in an architecture-test where appropriate.
well there are a few issues here:
1) Jan Beich informed me via a private email that enclosing WERROR in arch
specific conditions is a bad idea. if the code gets ported to a new
architecture WERROR doesn't get set and so for every new architecture one
has to evaluate again, whether WERROR needs to be set or not.
so i'm inclined to agree with dim@ that we should not add architecture
specific conditions -- however i think adding compiler specific
conditions
is a good idea.
2) the problem with settings WARNS= or specific -Wno-X or -Wno-error=X is
that
expecially GCC doesn't have specific -WX flags for certain warnings. some
warnings are implied by -Wall and cannot be turned off seperately. so in
order to get rid of these warnings (which are being handled as errors),
we
would need to disable -Wall. and i think setting WERROR= in order to
handle
all warnings for specific code as warnings rather than as errors is the
better solution.
i've reworked the patch to only remove WERROR=, where it is not needed
anymore
for any supported arch, or where it can be wrapped in a compiler condition.
It seems to me that the removal of unnecessary WERROR= needed no
discussion since day one so why don't you go ahead and commit it.
anybody is free to commit this part, since i don't own a commit bit. ;)
I don't understand the comment on issue #1 above. There is a minuscule
(six, before your patch ?)
number of Makefiles with WERROR= . If you make the assignment
architecture-specific, the worst it can happen is that the variable
is not cleared, and if the build breaks, all you need is to
add the extra architecture in these few places.
good point. basically the question with WERROR is: should it be a big hammer
to disable turning warnings into errors for all archs or do we want to set
WERROR in a more specific manor, where it's absolutely necessary.
cheers.
alex
cheers
luigi
cheers.
alex
- Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Index: sys/modules/xfs/Makefile
===
--- sys/modules/xfs/Makefile(revision 228911)
+++ sys/modules/xfs/Makefile(working copy)
@@ -6,8 +6,6 @@
KMOD= xfs
-WERROR=
-
SRCS = vnode_if.h \
xfs_alloc.c \
xfs_alloc_btree.c \
Index: sys/modules/sound/driver/maestro/Makefile
===
--- sys/modules/sound/driver/maestro/Makefile (revision 228911)
+++ sys/modules/sound/driver/maestro/Makefile (working copy)
@@ -5,6 +5,5 @@
KMOD= snd_maestro
SRCS= device_if.h bus_if.h pci_if.h
SRCS+= maestro.c
-WERROR=
.include bsd.kmod.mk
Index: sys/modules/aic7xxx/ahd/Makefile
===
--- sys/modules/aic7xxx/ahd/Makefile(revision 228911)
+++ sys/modules/aic7xxx/ahd/Makefile(working copy)
@@ -4,7 +4,6 @@
.PATH: ${.CURDIR}/../../../dev/aic7xxx
KMOD= ahd
-WERROR=
GENSRCS= aic79xx_seq.h aic79xx_reg.h
REG_PRINT_OPT=
AHD_REG_PRETTY_PRINT=1
Index: sys/modules/agp/Makefile
===
--- sys/modules/agp/Makefile(revision 228911)
+++ sys/modules/agp/Makefile(working copy)
@@ -20,7 +20,6 @@
SRCS+= device_if.h bus_if.h agp_if.h pci_if.h
SRCS+= opt_agp.h opt_bus.h
MFILES=kern/device_if.m kern/bus_if.m dev/agp/agp_if.m dev/pci/pci_if.m
-WERROR=
EXPORT_SYMS= agp_find_device \
agp_state \
Index: sys/modules/bios/smapi/Makefile
===
--- sys/modules/bios/smapi/Makefile (revision 228911)
+++ sys/modules/bios/smapi/Makefile (working copy
Re: [rfc] removing/conditionalising WERROR= in Makefiles
On Tue Dec 27 11, Warner Losh wrote: On Dec 26, 2011, at 6:04 PM, Philip Paeps wrote: On 2011-12-26 10:10:40 (+), Alexander Best arun...@freebsd.org wrote: i grep'ed through src/sys and found several places where WERROR= was set in order to get rid of the default -Werror setting. i tried to remove those WERROR= overrides from any Makefile, where doing so did not break tinderbox. in those cases, where it couldn't be completely removed, i added conditions to only set WERROR= for the particular achitecture or compiler, where tinderbox did not suceed without the WERROR=. Wouldn't it be better to set WARNS=x rather than WERROR=? WERROR= says this code has bugs, it breaks tinderbox whereas WARNS=x says this code has the following kind of bugs which break tinderbox. Agreed... in this case it would have to be WARNS=1 then, because anything 1 will enable -Wall, which is the warning that breaks sys/modules/ie. cheers. alex Possibly wrapped in an architecture-test where appropriate. Not so much... When you make architecture-specific tests, experience has shown that we don't fix bugs and they languish for a long time. Many times, these warnings are real. Sadly, we've found no way to tag the ones that aren't real yet as safe to ignore... Warner ___ 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
[rfc] removing/conditionalising WERROR= in Makefiles
hi there,
i grep'ed through src/sys and found several places where WERROR= was set in
order to get rid of the default -Werror setting. i tried to remove those
WERROR= overrides from any Makefile, where doing so did not break tinderbox.
in those cases, where it couldn't be completely removed, i added conditions to
only set WERROR= for the particular achitecture or compiler, where tinderbox
did not suceed without the WERROR=.
i talked to dim@ on #freebsd-clang@OFTC and he was against enclosing WERROR=
in a architecture or compiler condition. his statement was:
dim : I'm not going to riddle all those makefiles with endless comments, people
have to learn to look in the commit history for a file.
however the problem is that most of the time the commit message by the person
who added WERROR= to a Makefile doesn't state *why* the person did it and most
importantly it doesn't state in *which* case tinderbox failed without the
WERROR= (see *).
so my suggestion would be that instead of setting WERROR= unconditionally in
Makefiles, it should be enclosed in a condition to only set it in a particular
case, where tinderbox *will* fail.
an example is r228861. here dim@ set WERROR= in sys/modules/nve/Makefile
unconditionally. however tinderbox will only fail when
A) clang is used as compiler
B) when building for i386
these facts aren't clear from the commit message. so i'd suggest (please see
the attached patch) to conditionalise such settings.
another point i'd like to make is that WERROR= might have been set in a
Makefile in the past to unbreak tinderbox for a certain arch that is no longer
supported. since most of the time the commit logs simply state something like:
*)
...remove -Werror for now to unbreak tinderbox...
nobody will notice that after support for a certain arch was removed, the
WERROR= line can be removed from that particular Makefile.
that's why i'd like to propose the following patch. i ran a full tinderbox run
against r228878 and it suceeded.
cheers.
alex
Index: sys/modules/xfs/Makefile
===
--- sys/modules/xfs/Makefile(revision 228878)
+++ sys/modules/xfs/Makefile(working copy)
@@ -6,8 +6,6 @@
KMOD= xfs
-WERROR=
-
SRCS = vnode_if.h \
xfs_alloc.c \
xfs_alloc_btree.c \
Index: sys/modules/sound/driver/maestro/Makefile
===
--- sys/modules/sound/driver/maestro/Makefile (revision 228878)
+++ sys/modules/sound/driver/maestro/Makefile (working copy)
@@ -5,6 +5,5 @@
KMOD= snd_maestro
SRCS= device_if.h bus_if.h pci_if.h
SRCS+= maestro.c
-WERROR=
.include bsd.kmod.mk
Index: sys/modules/aic7xxx/ahd/Makefile
===
--- sys/modules/aic7xxx/ahd/Makefile(revision 228878)
+++ sys/modules/aic7xxx/ahd/Makefile(working copy)
@@ -4,7 +4,6 @@
.PATH: ${.CURDIR}/../../../dev/aic7xxx
KMOD= ahd
-WERROR=
GENSRCS= aic79xx_seq.h aic79xx_reg.h
REG_PRINT_OPT=
AHD_REG_PRETTY_PRINT=1
Index: sys/modules/ie/Makefile
===
--- sys/modules/ie/Makefile (revision 228878)
+++ sys/modules/ie/Makefile (working copy)
@@ -6,6 +6,8 @@
KMOD= if_ie
SRCS= if_ie.c if_ie_isa.c \
isa_if.h bus_if.h device_if.h
+.if ${MACHINE_CPUARCH} == i386
WERROR=
+.endif
.include bsd.kmod.mk
Index: sys/modules/agp/Makefile
===
--- sys/modules/agp/Makefile(revision 228878)
+++ sys/modules/agp/Makefile(working copy)
@@ -20,7 +20,6 @@
SRCS+= device_if.h bus_if.h agp_if.h pci_if.h
SRCS+= opt_agp.h opt_bus.h
MFILES=kern/device_if.m kern/bus_if.m dev/agp/agp_if.m dev/pci/pci_if.m
-WERROR=
EXPORT_SYMS= agp_find_device \
agp_state \
Index: sys/modules/bios/smapi/Makefile
===
--- sys/modules/bios/smapi/Makefile (revision 228878)
+++ sys/modules/bios/smapi/Makefile (working copy)
@@ -6,7 +6,6 @@
KMOD= smapi
SRCS= smapi.c smapi_bios.S \
bus_if.h device_if.h
-WERROR=
.if ${CC:T:Mclang} == clang
# XXX: clang integrated-as doesn't grok 16-bit assembly yet
CFLAGS+= ${.IMPSRC:T:Msmapi_bios.S:C/^.+$/-no-integrated-as/}
Index: sys/modules/nve/Makefile
===
--- sys/modules/nve/Makefile(revision 228878)
+++ sys/modules/nve/Makefile(working copy)
@@ -7,7 +7,9 @@
device_if.h bus_if.h pci_if.h miibus_if.h \
os+%DIKED-nve.h
OBJS+= nvenetlib.o
+.if ${MACHINE_CPUARCH} == i386 ${CC:T:Mclang} == clang
WERROR=
+.endif
CLEANFILES+= nvenetlib.o os+%DIKED-nve.h
nvenetlib.o: ${.CURDIR}/../../contrib/dev/nve/${MACHINE}/${.TARGET}.bz2.uu
___
freebsd-current@freebsd.org mailing list
starting the annual discussion regarding top(1)'s CPU usage statistics
ok...so we all know that top(1) cannot compute the exact CPU usage for all processes, since some processes get spawned and exit so fast that they don't fall into the calculation range. i think nobody is getting angry when top(1) is off by a few percent. however please take a look at the following top(1) output. this is just ridiculous! out of 800% of CPU power, almost 600% mysteriously vanished. is there really nothing to improve top(1)'s behaviour when the CPU is dealing with a lot of short processes (time wise) with a hugh CPU burst? this output was gathered on HEAD (r227491) running on i386. cheers. alex ps: no, switching between raw and weighted CPU stats did *not* make a difference. ;) last pid: 1489; load averages: 7.58, 7.73, 7.01 up 10+01:22:2821:21:04 170 processes: 2 running, 167 sleeping, 1 waiting CPU 0: 13.4% user, 0.0% nice, 13.4% system, 3.9% interrupt, 69.3% idle CPU 1: 48.8% user, 0.0% nice, 20.8% system, 0.0% interrupt, 30.4% idle CPU 2: 52.8% user, 0.0% nice, 24.8% system, 0.0% interrupt, 22.4% idle CPU 3: 59.2% user, 0.0% nice, 19.2% system, 0.0% interrupt, 21.6% idle CPU 4: 70.4% user, 0.0% nice, 17.6% system, 0.0% interrupt, 12.0% idle CPU 5: 42.5% user, 0.0% nice, 20.5% system, 0.0% interrupt, 37.0% idle CPU 6: 59.5% user, 0.0% nice, 16.7% system, 0.0% interrupt, 23.8% idle CPU 7: 55.2% user, 0.0% nice, 9.6% system, 0.0% interrupt, 35.2% idle Mem: 333M Active, 6577M Inact, 332M Wired, 4436K Cache, 111M Buf, 763M Free Swap: 8192M Total, 444K Used, 8191M Free PIDUIDTHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 11 0 8 155 ki31 0K64K CPU77 1718.7 200.00% [idle] 12 0 18 -84- 0K 144K WAIT0 73:49 3.76% [intr] 1238 1233 1 520 8032K 552K wait5 0:00 0.10% [cc] 1234 1233 1 520 9936K 1440K wait2 0:00 0.10% sh -ev 1236 1233 1 520 9936K 1492K wait2 0:00 0.10% [sh] 7 0 1 16- 0K 8K syncer 0 55:42 0.00% [syncer] 13 0 3 -8- 0K24K - 2 13:43 0.00% [geom] 14 0 1 -16- 0K 8K - 1 3:31 0.00% [yarrow] 9 0 1 -16- 0K 8K sdflus 4 3:00 0.00% [softdepflush] 566 0 1 200 12128K 2380K select 5 2:59 0.00% /sbin/devd 8 0 1 -16- 0K 8K vlruwt 2 1:32 0.00% [vnlru] 3 0 1 -16- 0K 8K psleep 3 1:29 0.00% [pagedaemon] 6 0 1 -16- 0K 8K psleep 1 1:13 0.00% [bufdaemon] 811 0 1 200 9784K 1356K select 1 0:22 0.00% /usr/sbin/rpcbind 975 0 1 200 11320K 1928K select 3 0:21 0.00% /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var 1043 0 1 200 13080K 2396K select 2 0:20 0.00% /usr/sbin/sshd 1050 0 1 200 11340K 2356K select 3 0:12 0.00% sendmail: accepting connections (sendmail) 1006 1 1 200 9540K 1088K sbwait 4 0:09 0.00% /usr/sbin/rwhod 1 0 1 200 8032K 352K wait7 0:09 0.00% [init] 1063 0 1 280 9656K 1388K nanslp 0 0:07 0.00% /usr/sbin/cron -s 735 0 1 200 9624K 1192K select 0 0:06 0.00% /usr/sbin/syslogd -s 814 0 1 200 9552K 1308K select 1 0:04 0.00% /usr/sbin/ypbind 0 0 8 -520 0K64K - 7 0:03 0.00% [kernel] 937 0 1 200 4408K 404K nanslp 2 0:03 0.00% /root/mfid cluster...@freebsd.org 59391 1233 1 520 28512K 23144K select 6 0:02 0.00% make DIRPRFX=lib/libc/ all 75317 1233 1 520 20320K 14032K select 1 0:01 0.00% make DIRPRFX=secure/lib/libcrypto/ all 17282 1233 1 200 8032K 616K select 1 0:01 0.00% make buildworld TARGET=arm TARGET_ARCH=armeb 17285 1233 1 200 8032K 616K select 6 0:01 0.00% make buildworld TARGET=amd64 TARGET_ARCH=amd64 17279 1233 1 200 8032K 616K select 0 0:01 0.00% make buildworld TARGET=arm TARGET_ARCH=arm 17299 1233 1 200 8032K 616K select 1 0:01 0.00% make buildworld TARGET=mips TARGET_ARCH=mipsel 17290 1233 1 200 8032K 616K select 2 0:01 0.00% make buildworld TARGET=mips TARGET_ARCH=mipseb 17293 1233 1 200 8032K 616K select 1 0:01 0.00% make buildworld TARGET=mips TARGET_ARCH=mips64el 17298 1233 1 200 8032K 616K select 2 0:01 0.00% make buildworld TARGET=mips TARGET_ARCH=mipsn32eb 17294 1233 1 200 8032K 616K select 3 0:01 0.00% make buildworld TARGET=mips TARGET_ARCH=mips64eb 17919 1233 1 200 8032K 996K select 1 0:01 0.00% make -m /dumpster/home/arundel/src/share/mk -f Makefile.inc1 17928 1233 1 200 8032K 932K select 0 0:01 0.00% make -m /dumpster/home/arundel/src/share/mk -f Makefile.inc1 18122
Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386?
On Sat Dec 24 11, Bruce Evans wrote: On Fri, 23 Dec 2011, Alexander Best wrote: is -mpreferred-stack-boundary=2 really necessary for i386 builds any longer? i built GENERIC (including modules) with and without that flag. the results are: The same as it has always been. It avoids some bloat. 1654496 bytes with the flag set vs. 1654952 bytes with the flag unset I don't believe this. GENERIC is enormously bloated, so it has size more like 16MB than 1.6MB. Even a savings of 4K instead of 456 bytes i'm sorry. i used du(1) to get those numbers, so i believe those numbers represent the ammount of 512-byte blocks. if i'm correct GENERIC is even more bloated than you feared and almost reaches 1GB: 807,859375 megabytes with flag set vs. 808,0820313 megabytes without the flag set is hard to believe. I get a savings of 9K (text) in a 5MB kernel. Changing the default target arch from i386 to pentium-undocumented has reduced the text space savings a little, since the default for passing args is now to preallocate stack space for them and store to this, instead of to push them; this preallocation results in more functions needing to allocate some stack space explicitly, and when some is allocated explicitly, the text space cost for this doesn't depend on the size of the allocation. Anyway, the savings are mostly from from avoiding cache misses from sparse allocation on stacks. Also, FreeBSD-i386 hasn't been programmed to support aligned stacks: - KSTACK_PAGES on i386 is 2, while on amd64 it is 4. Using more stack might push something over the edge - not much care is taken to align the initial stack or to keep the stack aligned in calls from asm code. E.g., any alignment for mi_startup() (and thus proc0?) is accidental. This may result in perfect alignment or perfect misalignment. Hopefully, more care is taken with thread startup. For gcc, the alignment is done bogusly in main() in userland, but there is no main() in the kernel. The alignment doesn't matter much (provided the perfect misalignment is still to a multiple of 4), but when it matters, the random misalignment that results from not trying to do it at all is better than perfect misalignment from getting it wrong. With 4-byte alignment, the only cases that it helps are with 64-bit variables. the gcc(1) man page states the following: This extra alignment does consume extra stack space, and generally increases code size. Code that is sensitive to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to -mpreferred-stack-boundary=2. the comment in sys/conf/kern.mk however sorta suggests that the default alignment of 4 bytes might improve performance. The default stack alignment is 16 bytes, which unimproves performance. clang handles stack alignment correctly (only does it when it is needed) so it doesn't need a -mpreferred-stack-boundary option and doesn't always break without alignment in main(). Well, at least it used to, IIRC. Testing it now shows that it does the necessary andl of the stack pointer for __aligned(32), but for __aligned(16) it now assumes that the stack is aligned by the caller. So it now needs -mpreferred-stack-boundary=2, but doesn't have it. OTOH, clang doesn't do the andl in main() like gcc does (unless you put a dummy __aligned(32) there), but requires crt to pass an aligned stack. Bruce ___ 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: [rfc] removing -mpreferred-stack-boundary=2 flag for i386?
On Sat Dec 24 11, Bruce Evans wrote: On Fri, 23 Dec 2011, Alexander Best wrote: is -mpreferred-stack-boundary=2 really necessary for i386 builds any longer? i built GENERIC (including modules) with and without that flag. the results are: The same as it has always been. It avoids some bloat. 1654496 bytes with the flag set vs. 1654952 bytes with the flag unset I don't believe this. GENERIC is enormously bloated, so it has size more like 16MB than 1.6MB. Even a savings of 4K instead of 456 bytes is hard to believe. I get a savings of 9K (text) in a 5MB kernel. Changing the default target arch from i386 to pentium-undocumented has reduced the text space savings a little, since the default for passing args is now to preallocate stack space for them and store to this, instead of to push them; this preallocation results in more functions needing to allocate some stack space explicitly, and when some is allocated explicitly, the text space cost for this doesn't depend on the size of the allocation. Anyway, the savings are mostly from from avoiding cache misses from sparse allocation on stacks. Also, FreeBSD-i386 hasn't been programmed to support aligned stacks: - KSTACK_PAGES on i386 is 2, while on amd64 it is 4. Using more stack might push something over the edge - not much care is taken to align the initial stack or to keep the stack aligned in calls from asm code. E.g., any alignment for mi_startup() (and thus proc0?) is accidental. This may result in perfect alignment or perfect misalignment. Hopefully, more care is taken with thread startup. For gcc, the alignment is done bogusly in main() in userland, but there is no main() in the kernel. The alignment doesn't matter much (provided the perfect misalignment is still to a multiple of 4), but when it matters, the random misalignment that results from not trying to do it at all is better than perfect misalignment from getting it wrong. With 4-byte alignment, the only cases that it helps are with 64-bit variables. the gcc(1) man page states the following: This extra alignment does consume extra stack space, and generally increases code size. Code that is sensitive to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to -mpreferred-stack-boundary=2. the comment in sys/conf/kern.mk however sorta suggests that the default alignment of 4 bytes might improve performance. The default stack alignment is 16 bytes, which unimproves performance. maybe the part of the comment in sys/conf/kern.mk, which mentions that a stack alignment of 16 bytes might improve micro benchmark results should be removed. this would prevent people (like me) from thinking, using a stack alignment of 4 bytes is a compromise between size and efficiently. it isn't! currently a stack alignment of 16 bytes has no advantages towards one with 4 bytes on i386. so specifying -mpreferred-stack-boundary=2 on i386 is absolutely mandatory. please see the attached patch, which also introduduces a line break in order to describe the stack alignment issue in a paragraph of its own. cheers. alex clang handles stack alignment correctly (only does it when it is needed) so it doesn't need a -mpreferred-stack-boundary option and doesn't always break without alignment in main(). Well, at least it used to, IIRC. Testing it now shows that it does the necessary andl of the stack pointer for __aligned(32), but for __aligned(16) it now assumes that the stack is aligned by the caller. So it now needs -mpreferred-stack-boundary=2, but doesn't have it. OTOH, clang doesn't do the andl in main() like gcc does (unless you put a dummy __aligned(32) there), but requires crt to pass an aligned stack. Bruce Index: /usr/src/sys/conf/kern.mk === --- /usr/src/sys/conf/kern.mk (revision 228845) +++ /usr/src/sys/conf/kern.mk (working copy) @@ -30,12 +30,12 @@ # On i386, do not align the stack to 16-byte boundaries. Otherwise GCC 2.95 # and above adds code to the entry and exit point of every function to align the # stack to 16-byte boundaries -- thus wasting approximately 12 bytes of stack -# per function call. While the 16-byte alignment may benefit micro benchmarks, -# it is probably an overall loss as it makes the code bigger (less efficient -# use of code cache tag lines) and uses more stack (less efficient use of data -# cache tag lines). Explicitly prohibit the use of FPU, SSE and other SIMD -# operations inside the kernel itself. These operations are exclusively -# reserved for user applications. +# per function call. This makes the code bigger (less efficient use of code +# cache tag lines) and uses more stack (less efficient use of data cache tag +# lines). +# Explicitly prohibit the use of FPU, SSE and other SIMD operations inside the +# kernel
Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386?
On Sat Dec 24 11, Bruce Evans wrote: On Sat, 24 Dec 2011, Alexander Best wrote: On Sat Dec 24 11, Bruce Evans wrote: On Fri, 23 Dec 2011, Alexander Best wrote: is -mpreferred-stack-boundary=2 really necessary for i386 builds any longer? i built GENERIC (including modules) with and without that flag. the results are: The same as it has always been. It avoids some bloat. 1654496bytes with the flag set vs. 1654952bytes with the flag unset I don't believe this. GENERIC is enormously bloated, so it has size more like 16MB than 1.6MB. Even a savings of 4K instead of 456 bytes i'm sorry. i used du(1) to get those numbers, so i believe those numbers represent the ammount of 512-byte blocks. if i'm correct GENERIC is even more bloated than you feared and almost reaches 1GB: 807,859375 megabytes with flag set vs. 808,0820313 megabytes without the flag set That's certainly bloated. It counts all object files and modules, and probably everything is compiled with -g. I only counted kernel text size. yeah, but for demonstrating the different size between the build with -mpreferred-stack-boundary=2 set and -mpreferred-stack-boundary=2 unset, it doesn't really matter how big the directories are and if object files are included. the difference in size is 1 megabyte. so setting -mpreferred-stack-boundary=2 doesn't aid in reducing the kernel (or modules) size, but merely to improve improve stack performance/efficiency. cheers. alex Bruce ___ 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: [rfc] removing -mpreferred-stack-boundary=2 flag for i386?
On Sat Dec 24 11, Bruce Evans wrote: On Fri, 23 Dec 2011, Adrian Chadd wrote: Well, the whole kernel is bloated at the moment, sorry. I've been trying to build the _bare minimum_ required to bootstrap -HEAD on these embedded boards and I can't get the kernel down below 5 megabytes - ie, one with FFS (with options disabled), MIPS, INET (no INET6), net80211, ath (which admittedly is big, but I need it no matter what, right?) comes in at: -r-xr-xr-x 1 root wheel 5307021 Nov 29 19:14 kernel.LSSR71 And with INET6, on another board (and this includes MSDOS and the relevant geom modules): -r-xr-xr-x 1 root wheel 5916759 Nov 28 12:00 kernel.RSPRO .. honestly, that's what should be addressed. That's honestly a bit ridiculous. It's disgusting, but what problems does it cause apart from minor slowness from cache misses? I used to monitor the size of a minimal i386 kernel: % machine i386 % cpu I686_CPU % ident MIN % options SCHED_4BSD In FreeBSD-5-CURRENT between 5.1R and 5.2R, this had size: text data bss dec hex filename 931241 86524 62356 1080121 107b39 /sysc/i386/compile/min/kernel A minimal kernel is not useful, but maybe you can add some i/o to it without bloating it too much. This almost builds in -current too. I had to add the following: - NO_MODULES to de-bloat the compile time - MK_CTF=no to build -current on FreeBSD.9. The kernel .mk files are still broken (depend on nonstandard/new features in sys.mk). strange. the build(7) man page claims that: WITH_CTF If defined, the build process will run the DTrace CTF conversion tools on built objects. Please note that this WITH_ option is handled differently than all other WITH_ options (there is no WITHOUT_CTF, or correspond- ing MK_CTF in the build system). ... so setting MK_CTF to anything shouldn't have (according to the man page). cheers. alex - comment out a line in if.c that refers to Vloif. if.c is standard but the loop device is optional. A few more changes to remove non-minimalities that are not defaults made little difference: % machine i386 % cpu I686_CPU % ident MIN % options SCHED_4BSD % % # XXX kill default misconfigurations. % makeoptions NO_MODULES=yes % makeoptions COPTFLAGS=-O -pipe % % # XXX from here on is to try to kill everything in DEFAULTS. % % # nodevice isa # needed for DELAY... % # nooptions ISAPNP # needed ... % % nodevicenpx % % nodevicemem % nodeviceio % % nodeviceuart_ns8250 % % nooptions GEOM_PART_BSD % nooptions GEOM_PART_EBR % nooptions GEOM_PART_EBR_COMPAT % nooptions GEOM_PART_MBR % % # nooptions NATIVE # needed ... % # nodevice atpic # needed ... % % nooptions NEW_PCIB % % nooptions VFS_ALLOW_NONMPSAFE text data bss dec hex filename 1663902110632 136892 1911426 1d2a82 kernel (This was about 100K larger with -O2 and all DEFAULTS). The bloat since FreeBSD-5 is only 70%. Here are some sizes for my standard kernel (on i386). The newer versions have about the same number of features since they don't support so many old isa devices or so many NICs: text data bss dec hex filename 1483269106972 172524 1762765 1ae5cd FreeBSD-3/kernel 1917408157472 194228 2269108 229fb4 FreeBSD-4/kernel 2604498198948 237720 3041166 2e678e FreeBSD-5.1.5/kernel 2833842206856 242936 3283634 321ab2 FreeBSD-5.1.5/kernel-with-acpi 2887573192456 288696 3368725 336715 FreeBSD-5.1.5/kernel with my changes, -O2 and usb added relative to the above 2582782195756 298936 3077474 2ef562 previous, with some excessive inlining avoided, and without -O2, and with ipfilter 1998276159436 137748 2295460 2306a4 kernel.4 a more up to date and less hacked on FreeBSD-4 4365549262656 209588 4837793 49d1a1 kernel.7 4406155266496 496532 5169183 4ee01f kernel.7.invariants 3953248242464 207252 4402964 432f14 kernel.7.noacpi 4418063268288 240084 4926435 4b2be3 kernel.7.smp various fairly stock FreeBSD-7R kernels 3669544262848 249712 4182104 3fd058 kernel.c 4174317258240 540144 4972701 4be09d kernel.c.invariants 3964455250656 249808 4464919 442117 kernel.c.noacpi 3213928
Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386?
On Sat Dec 24 11, Bruce Evans wrote: On Sat, 24 Dec 2011, Alexander Best wrote: On Sat Dec 24 11, Bruce Evans wrote: On Fri, 23 Dec 2011, Alexander Best wrote: ... the gcc(1) man page states the following: This extra alignment does consume extra stack space, and generally increases code size. Code that is sensitive to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to -mpreferred-stack-boundary=2. the comment in sys/conf/kern.mk however sorta suggests that the default alignment of 4 bytes might improve performance. The default stack alignment is 16 bytes, which unimproves performance. maybe the part of the comment in sys/conf/kern.mk, which mentions that a stack alignment of 16 bytes might improve micro benchmark results should be removed. this would prevent people (like me) from thinking, using a stack alignment of 4 bytes is a compromise between size and efficiently. it isn't! currently a stack alignment of 16 bytes has no advantages towards one with 4 bytes on i386. I think the comment is clear enough. It it mentions all the tradeoffs. It is only slightly cryptic in saying that these are tradeoffs and that the configuration is our best guess at the best tradeoff -- it just says while for both. It goes without saying that we don't use our worst guess. Anyone wanting to change this should run benchmarks and beware that micro-benchmarks are especially useless. The changed comment is not so good since it no longer mentions micro-bencharmarks or says while. if micro benchmark results aren't of any use, why should the claim that the default stack alignment of 16 bytes might produce better outcome stay? it doesn't seem as if anybody has micro benchmarked 16 bytes vs. 4 bytes stack alignment, until now. so the micro benchmark statement in the comment seems to be pure speculation. even worse...it indicates that by removing the -mpreferred-stack-boundary=2 flag, one can gain a performance boost by sacrifying a few more bytes of kernel (and module) size. this suggests that the behavior -mpreferred-stack-boundary=2 vs. not specyfing it, losely equals the semantics of -Os vs. -O2. i don't see how a 4 byte stack alignment for the kernel has any tradeoffs against the default 16 byte alignment. so if there are no tradeoffs, the comment shouldn't imply that there are. cheers. alex so specifying -mpreferred-stack-boundary=2 on i386 is absolutely mandatory. Not mandatory; just an optimization. please see the attached patch, which also introduduces a line break in order to describe the stack alignment issue in a paragraph of its own. There should also be an empty line for a paragraph break. % +# Explicitly prohibit the use of FPU, SSE and other SIMD operations inside the % +# kernel itself. These operations are exclusively reserved for user % +# applications. This part was actually wronger: - these operations are not really reserved, but were just not supported in the kernel - they have been supported in the kernel for some time, although anything wanting to use the compiler to generate them would have to do something to kill the options added here. Kernel code using them must inform the kernel that it is doing so, using fpu_kern*(9undoc), and this is only valid in some contexts (more or less for kernel-only threads) so we still prevent compilers from using them routinely. The makefile is not the right place to describe any of this, Bruce ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Fri Dec 23 11, Daniel Kalchev wrote: On 23.12.11 08:47, Martin Sugioarto wrote: A further thing is that I cannot understand the people here sometimes. I would like that the -RELEASE versions of FreeBSD perform well without any further optimizations. The -RELEASE things is just a freeze (or, let's say tested freeze) of the corresponding branch at some time. It is the code available and tested at that time. Thus, it is safe to say that FreeBSD 8.0-RELEASE is much worse than FreeBSD RELENG_8 (still 8.2 at the moment), because years have passed between both code bases, lots of bugs have been discovered and fixed and new technologies have been integrated. Especially in this line, the compiler has changed from 4.2.1 to 4.2.2. When the distribution does not compile with the latest compiler it's simply a bug. FreeBSD is not a distribution. It also compiles with the latest compiler - LLVM. :) I find it amusing, that people want everything compiled with GCC 4.7, which is still very much developing, therefore highly unstable and (probably) full of bugs. Why should one try to penalize the other distribution and downgrade their binaries? Many suggested that the Linux binaries be run via the FreeBSD Linux emulation. Unchanged. There is one problem here though, the emulation is still 32 bit. plus the current emulation layer is far from complete. a lot of stuff hasn't been implemented yet (meaning it's missing or implemented as dummy code). try running recent firefox linux binaries on freebsd. they will all crash almost instantly. cheers. alex When FreeBSD has a bad default setup, there must be a reason for that. Tell me this reason and show me that it's justified in form of some other benchmark. FreeBSD has safe default. It is supposed to work out of the box on whatever hardware you put it. As much as it has drives for that hardware, of course. Once you have working installation, you may tweak it all the way you wish. If your installation is pre-optimized, chances are it will crash all the time on you and there will be no easy way for you to fix, short of installing another distribution. Daniel ___ 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] Cleaning up amd64 kernel optimization options
On Fri Dec 23 11, John Baldwin wrote: On Thursday, December 22, 2011 9:51:47 pm Garrett Cooper wrote: On Dec 22, 2011, at 4:59 PM, Alexander Best arun...@freebsd.org wrote: On Thu Dec 22 11, Benjamin Kaduk wrote: On Thu, 22 Dec 2011, Alexander Best wrote: On Thu Dec 22 11, Dimitry Andric wrote: Hi, I would like to ask some feedback on the attached patch, which cleans up the kernel optimization options for amd64. This was touched upon earlier by Alexander Best in freebsd-toolchain, here: i've been using such settings for a few months now and haven't noticed any problems. however bruce evans raised a good point (in a private mail). when you compile a kernel without debugging enabled, -O2 is the default. if you experience issues, and enable debugging, -O0 now becomes the default. in case the problems with the kernel were caused by the -O2 option and aren't present with the -O0 option, the newly built kernel with debugging enabled will not help you fix the problems. in that case you would need to set -O2 explicitly in CFLAGS. his exact words were: I don't like -O2 for anything. However, if it is only a default, it is not a problem provided it can be canceled easily. And for debugging, you want the default to be the same as without debugging, so that (by default) you debug the same code that caused the problem. however i don't think this is fixable. using -O0 for debuggable and non-debuggable kernels will cause too much of a slowdown. having -O2 as the default flag for non-debuggable kernels and -O2 -g for debuggable kernels might cause situations, where debugging isn't possible, where with -O0 -g it would have been. so i guess although bruces concerns are valid, they are impossible to solve. Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. sorry. of course i meant -O: .if defined(DEBUG) _MINUS_O= -O CTFFLAGS+= -g .else [..] Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. I still leave -O2 in, but what I do is this: make DEBUG_FLAGS=-g -fno-inline would making -O2 -fno-inline the default flags introduce any major slowdown? all that would be needed then to build a debugging kernel would be to add -g. cheers. alex Just adding -fno-inline makes a world of difference. -- John Baldwin ___ 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] Cleaning up amd64 kernel optimization options
On Fri Dec 23 11, Dimitry Andric wrote: On 2011-12-23 18:55, Kostik Belousov wrote: On Fri, Dec 23, 2011 at 06:03:42PM +0100, Dimitry Andric wrote: ... The only thing my patch makes sure of, is that amd64 does the same thing as all other arches, e.g.: compile with a low optimization settings for debug (-O, which is equivalent to -O1), compile with arch-specific high optimization settings for release (-O2 plus whatever is required for the arch, or lower if optimization breaks things). Release is built with -g for long time, this is where the symbol files in /boot/kernel comes from. Ah, that is done via 'makeoptions DEBUG=-g' in the kernel configuration file, right? I didn't realize that was kept in for a release. But even in that case, amd64 is somehow different from the other arches, which all get compiled with -O instead. If people prefer that to stay as it is, I'll change the diff so only -frename-registers gets removed when clang is used, as clang does not support this flag. i think you should go ahead with the changes: 1) get amd64 in line with the other archs when debugging was requested (turning the default optimisation from -O2 to -O) 2) only specify -frename-registers on amd64, when gcc is the requested compiler i'd say: commit it. :) ...sorry we got carried away, but optimisation flags tend to trigger a lot of discussion. ;) cheers. alex ___ 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
[rfc] removing -mpreferred-stack-boundary=2 flag for i386?
hi there, is -mpreferred-stack-boundary=2 really necessary for i386 builds any longer? i built GENERIC (including modules) with and without that flag. the results are: 1654496 bytes with the flag set vs. 1654952 bytes with the flag unset the gcc(1) man page states the following: This extra alignment does consume extra stack space, and generally increases code size. Code that is sensitive to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to -mpreferred-stack-boundary=2. the comment in sys/conf/kern.mk however sorta suggests that the default alignment of 4 bytes might improve performance. cheers. alex ___ 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] Cleaning up amd64 kernel optimization options
On Thu Dec 22 11, Dimitry Andric wrote: Hi, I would like to ask some feedback on the attached patch, which cleans up the kernel optimization options for amd64. This was touched upon earlier by Alexander Best in freebsd-toolchain, here: i've been using such settings for a few months now and haven't noticed any problems. however bruce evans raised a good point (in a private mail). when you compile a kernel without debugging enabled, -O2 is the default. if you experience issues, and enable debugging, -O0 now becomes the default. in case the problems with the kernel were caused by the -O2 option and aren't present with the -O0 option, the newly built kernel with debugging enabled will not help you fix the problems. in that case you would need to set -O2 explicitly in CFLAGS. his exact words were: I don't like -O2 for anything. However, if it is only a default, it is not a problem provided it can be canceled easily. And for debugging, you want the default to be the same as without debugging, so that (by default) you debug the same code that caused the problem. however i don't think this is fixable. using -O0 for debuggable and non-debuggable kernels will cause too much of a slowdown. having -O2 as the default flag for non-debuggable kernels and -O2 -g for debuggable kernels might cause situations, where debugging isn't possible, where with -O0 -g it would have been. so i guess although bruces concerns are valid, they are impossible to solve. cheers. alex http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-October/000270.html What this patch attempts to fix is the following: - When you compile amd64 kernels for debug, they still get optimized with -O2 -frename-registers, which is almost certain to make debugging miserable. Optimizing at higher levels makes variables and code move around, or disappear altogether. About -frename-registers the gcc documentation even says: Depending on the debug information format adopted by the target, however, it can make debugging impossible, since variables will no longer stay in a ?home register?. - Clang doesn't support the -frename-registers option, so you get harmless but annoying warning: argument unused during compilation: '-frename-registers' messages during buildkernel. The patch makes it so that: - For normal amd64 kernel builds, it uses -O2 -frename-registers, unless Clang is used, then it uses plain -O2. - For debug amd64 kernel builds, it uses -O, just like all the other arches. ___ 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] Cleaning up amd64 kernel optimization options
On Thu Dec 22 11, Benjamin Kaduk wrote: On Thu, 22 Dec 2011, Alexander Best wrote: On Thu Dec 22 11, Dimitry Andric wrote: Hi, I would like to ask some feedback on the attached patch, which cleans up the kernel optimization options for amd64. This was touched upon earlier by Alexander Best in freebsd-toolchain, here: i've been using such settings for a few months now and haven't noticed any problems. however bruce evans raised a good point (in a private mail). when you compile a kernel without debugging enabled, -O2 is the default. if you experience issues, and enable debugging, -O0 now becomes the default. in case the problems with the kernel were caused by the -O2 option and aren't present with the -O0 option, the newly built kernel with debugging enabled will not help you fix the problems. in that case you would need to set -O2 explicitly in CFLAGS. his exact words were: I don't like -O2 for anything. However, if it is only a default, it is not a problem provided it can be canceled easily. And for debugging, you want the default to be the same as without debugging, so that (by default) you debug the same code that caused the problem. however i don't think this is fixable. using -O0 for debuggable and non-debuggable kernels will cause too much of a slowdown. having -O2 as the default flag for non-debuggable kernels and -O2 -g for debuggable kernels might cause situations, where debugging isn't possible, where with -O0 -g it would have been. so i guess although bruces concerns are valid, they are impossible to solve. Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. sorry. of course i meant -O: .if defined(DEBUG) _MINUS_O= -O CTFFLAGS+= -g .else [..] -Ben Kaduk ___ 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: SCHED_ULE should not be the default
On Mon Dec 19 11, Nathan Whitehorn wrote: On 12/18/11 04:34, Adrian Chadd wrote: The trouble is that there's lots of anecdotal evidence, but noone's really gone digging deep into _their_ example of why it's broken. The developers who know this stuff don't see anything wrong. That hints to me it may be something a little more creepy - as an example, the interplay between netisr/swi/taskqueue/callbacks and such. It may be that something is being starved that isn't obviously obvious. It's just a stab in the dark, but it sounds somewhat plausible based on what I've seen ULE do in my network throughput hacking. I applaud reppie for trying to make it as easy as possible for people to use KTR to provide scheduler traces for him to go digging with, so please, if you have these issues and you can absolutely reproduce them, please follow his instructions and work with him to get him what he needs. The thing I've seen is that ULE is substantially more enthusiastic about migrating processes between cores than 4BSD. Often, this is a good thing, but can increase the rate of cache misses, hurting performance for cache-bound processes (I see this particularly in HPC-type scientific workloads). It might be interesting to add some kind of tunable here. does r228718 have any impact regarding this behaviour? cheers. alex Another more interesting and slightly longer-term possibility if someone wants a project would be to integrate scheduling decisions with hwpmc counters, to accumulate statistics on cache hits at each context switch and preferentially keep processes with a high hits/misses ratio on the same thread/cache domain relative to processes with a low one. -Nathan P.S. The other thing that could be very interesting from a research and scheduling standpoint would be to integrate heterogeneous SMP support into the operating system, with a FreeBSD-4 Application Processor syscall model. We seem to be going down the road where GPGPU computing has MMUs, timer interrupts, IPIs, etc. (the next AMD Fusions, IBM Cell). This is something that no operating system currently supports well, and would be a place for BSD to shine. If anyone has a free graduate student... ___ 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
can a wrong alignment cause a decrease in a hdd's life expectancy?
hi there, i'm using a usb hdd with the following specs: otaku% sudo smartctl -i /dev/da0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 10.0-CURRENT amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Western Digital My Passport Essential SE (USB, Adv. Format) Device Model: WDC WD10TMVW-11ZSMS4 Serial Number:WD-WXJ1A81C1845 LU WWN Device Id: 5 0014ee 1af1e4483 Firmware Version: 01.01A01 User Capacity:1,000,204,886,016 bytes [1,00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is:In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Mon Dec 19 23:00:43 2011 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled unfortunately i didn't align it properly using gpart(8)'s -a switch. performance wise it shouldn't cause any issues, because i'm accessing this hdd through usb 2 exclusively. however my concern is that using an alignment of 512 will put an extra workload onto the hdd (doing the conversion - 4096). will this reduce my hdd's life expectancy? in that case i might consider re-partitioning it (with proper alignment settings). cheers. alex ps: the hdd only gets mounted read-only! ___ 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: can a wrong alignment cause a decrease in a hdd's life expectancy?
On Mon Dec 19 11, Poul-Henning Kamp wrote: In message 20111219221617.ga70...@freebsd.org, Alexander Best writes: ps: the hdd only gets mounted read-only! There is no known wear-effects in flash storage as long as you only read. You may need to do refresh-writes every 5-10 years to avoid tunnel-leakage bit errors, but most flash controllers use semi-long ECC syndromes and will do so on first bit that gives an read error. this is a regular hdd i believe -- no ssd. at least when i plug it into my usb drive i hear the hdd spinning up and causing vibrations. i don't think that would be the case with an ssd. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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: can a wrong alignment cause a decrease in a hdd's life expectancy?
On Mon Dec 19 11, Poul-Henning Kamp wrote: In message 20111219224700.ga75...@freebsd.org, Alexander Best writes: On Mon Dec 19 11, Poul-Henning Kamp wrote: In message 20111219221617.ga70...@freebsd.org, Alexander Best writes: ps: the hdd only gets mounted read-only! There is no known wear-effects in flash storage as long as you only read. You may need to do refresh-writes every 5-10 years to avoid tunnel-leakage bit errors, but most flash controllers use semi-long ECC syndromes and will do so on first bit that gives an read error. this is a regular hdd i believe -- no ssd. at least when i plug it into my usb drive i hear the hdd spinning up and causing vibrations. i don't think that would be the case with an ssd. Ahh, sorry, I don't know why I thought it was flash. no problem. so will the improper alignment also not cause a life expectancy shortage in case of a hdd (non-flash-based)? and one other question: the hdd also supports usb 3. will the improper alignment have any effect (speed wise) when connected via usb 3, or is even usb 3 too slow to notice the performance drop due to the improper alignment? cheers. alex -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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: can a wrong alignment cause a decrease in a hdd's life expectancy?
On Mon Dec 19 11, Jeremy Chadwick wrote: On Mon, Dec 19, 2011 at 10:56:33PM +, Alexander Best wrote: On Mon Dec 19 11, Poul-Henning Kamp wrote: In message 20111219224700.ga75...@freebsd.org, Alexander Best writes: On Mon Dec 19 11, Poul-Henning Kamp wrote: In message 20111219221617.ga70...@freebsd.org, Alexander Best writes: ps: the hdd only gets mounted read-only! There is no known wear-effects in flash storage as long as you only read. You may need to do refresh-writes every 5-10 years to avoid tunnel-leakage bit errors, but most flash controllers use semi-long ECC syndromes and will do so on first bit that gives an read error. this is a regular hdd i believe -- no ssd. at least when i plug it into my usb drive i hear the hdd spinning up and causing vibrations. i don't think that would be the case with an ssd. Ahh, sorry, I don't know why I thought it was flash. no problem. so will the improper alignment also not cause a life expectancy shortage in case of a hdd (non-flash-based)? The improper alignment will result in sub-par write performance, and a slight decrease in read performance writes -- but will not impact life expectancy or harm the drive in any way. I recommend strongly that you rectify the situation before you get too carried away with software installations, etc.. And yes I am aware what you have is a mechanical HDD not an SSD (I say in this advance of what I'm about to write). If you need a safe alignment value, most software on Windows (including Windows 7) pick a value of 2MBytes as the alignment offset, which I believe is LBA 4095, since everything software-wise uses 512-byte sectors. That's calculated via: 2097152 / 512. This number is also evenly divisible by 4096 bytes (which is what you're trying to ensure for performance). Readers, as well as you, may wonder where the magical 2MByte value comes from, and can you pick something smaller. Yes you can pick something smaller, but the value itself stems from the added complexity of SSDs and NAND erase page size vs. NAND page size. A value of 2MBytes works well on all brands of SSDs on the market (as of this writing). Which reminds me -- I need to go back and redo most of our systems that use Intel SSDs, since at the time I picked the default offset in sysinstall (LBA 63, thus 64 * 512 = 32KBytes), which though divisible by 4096, is not optimal for NAND erase page size. I would love to advocate FreeBSD change sysinstall/bsdinstall to use a default offset of 2MBytes, but I imagine that would upset a lot of people who install FreeBSD on limited space devices (CF, etc.). Honestly though, with the size of media these days thanks a lot for the explanation. i'm going to get another drive, soon, and will then be able to fix the alignment, as i currently have no place where i can backup the data of my current (misaligned) hdd. and one other question: the hdd also supports usb 3. will the improper alignment have any effect (speed wise) when connected via usb 3, or is even usb 3 too slow to notice the performance drop due to the improper alignment? USB 3.0 vs. 2.0 vs. eSATA vs. native SATA has no bearing on the situation. Those are transport protocols that define maximum bandwidth. By the way, the hard disk itself does not support USB 3.0 -- your drive is in an enclosure that contains a SATA-USB3.0 conversion chipset inside. If you open the enclosure, you will find the hard disk is SATA, and probably supports SATA600. i was ware of this fact. what i meant by speed in connection with usb 3 was the following example-case (please don't take the numbers literally) 1) the drive itself can do 500 mb/sec when aligned properly 2) the drive does 350 mb/sec when aligned improperly (512 boundry) 3) usb 3 can do 100 mb/sec ... so in this case the improper alignment wouldn't have an impact, since even with proper alignment only 100 mb/sec were possible. however in the following example: 1) 500 mb/sec 2) 100 mb/sec 3) 200 mb/sec the improper alignment would have an impact, since usb 3 *could* perform at 200 mb/sec with proper alignment, but will drop to 100 mb/sec in the case of improper alignment. again...please don't take the transfer rates literaly. they're most defenately bogus. cheers. alex -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: SCHED_ULE should not be the default
On Sun Dec 18 11, Andrey Chernov wrote: On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote: On 13/12/2011 09:00, Andrey Chernov wrote: I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine with 16 logical CPUs. If I run tar xf somefile.tar and make -j16 buildworld then logging into another console can take several seconds. Sometimes even the Password: prompt can take a couple of seconds to appear after typing my username. I'd resigned myself to expecting this sort of behaviour as 'normal' on my single core 1133MHz PIII-M. As a reproducable data point, running 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat the CPU while testing my manual fan control script, hogs it up pretty much while regularly running the script below in another konsole to check values - which often gets stuck half way, occasionally pausing _twice_ before finishing. Switching back to the first konsole (on another desktop) to kill the dd can also take a couple/few seconds. This issue not about slow machine under load, because the same slow machine under exact the same load, but with SCHED_4BSD is very fast to response interactively. I think we should not misinterpret interactivity with speed. I see no big speed (i.e. compilation time) differences, switching schedulers, but see big _interactivity_ difference. ULE in general tends to underestimate interactive processes in favour of background ones. It perhaps helps to compilation, but looks like slowpoke OS from the interactive user experience. +1 i've also experienced issues with ULE and performed several tests to compare it to the historical 4BSD scheduler. the difference between the two does *not* seem to be speed (at least not a huge difference), but interactivity. one of the tests i performed was the following ttyv0: untar a *huge* (+10G) archive ttyv1: after ~ 30 seconds of untaring do 'ls -la $direcory', where directory contains a lot of files. i used direcory = /var/db/portsnap, because that directory contains 23117 files on my machine. measuring 'ls -la $direcory' via time(1) revealed that SCHED_ULE takes 15 seconds, whereas SCHED_4BSD only takes ~ 3-5 seconds. i think the issue is io. io operations usually get a high priority, because statistics have shown that - unlike computational tasks - io intensive tasks only run for a small fraction of time and then exit: read data - change data - writeback data. so SCHED_ULE might take these statistics too literaly and gives tasks like bsdtar(1) (in my case) too many ressources, so other tasks which require io are struggling to get some ressources assigned to them (ls(1) in my case). of course SCHED_4BSD isn't perfect, too. try using it and run the stress2 testsuite. your whole system will grind to a halt. mouse input drops below 1 HZ. even after killing all the stress2 tests, it will take a few minutes after the system becomes snappy again. cheers. alex -- http://ache.vniz.net/ ___ 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: SCHED_ULE should not be the default
On Sun Dec 18 11, Alexander Best wrote: On Sun Dec 18 11, Andrey Chernov wrote: On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote: On 13/12/2011 09:00, Andrey Chernov wrote: I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine with 16 logical CPUs. If I run tar xf somefile.tar and make -j16 buildworld then logging into another console can take several seconds. Sometimes even the Password: prompt can take a couple of seconds to appear after typing my username. I'd resigned myself to expecting this sort of behaviour as 'normal' on my single core 1133MHz PIII-M. As a reproducable data point, running 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat the CPU while testing my manual fan control script, hogs it up pretty much while regularly running the script below in another konsole to check values - which often gets stuck half way, occasionally pausing _twice_ before finishing. Switching back to the first konsole (on another desktop) to kill the dd can also take a couple/few seconds. This issue not about slow machine under load, because the same slow machine under exact the same load, but with SCHED_4BSD is very fast to response interactively. I think we should not misinterpret interactivity with speed. I see no big speed (i.e. compilation time) differences, switching schedulers, but see big _interactivity_ difference. ULE in general tends to underestimate interactive processes in favour of background ones. It perhaps helps to compilation, but looks like slowpoke OS from the interactive user experience. +1 i've also experienced issues with ULE and performed several tests to compare it to the historical 4BSD scheduler. the difference between the two does *not* seem to be speed (at least not a huge difference), but interactivity. one of the tests i performed was the following ttyv0: untar a *huge* (+10G) archive ttyv1: after ~ 30 seconds of untaring do 'ls -la $direcory', where directory contains a lot of files. i used direcory = /var/db/portsnap, because s/portsnap/portsnap\/files/ that directory contains 23117 files on my machine. measuring 'ls -la $direcory' via time(1) revealed that SCHED_ULE takes 15 seconds, whereas SCHED_4BSD only takes ~ 3-5 seconds. i think the issue is io. io operations usually get a high priority, because statistics have shown that - unlike computational tasks - io intensive tasks only run for a small fraction of time and then exit: read data - change data - writeback data. so SCHED_ULE might take these statistics too literaly and gives tasks like bsdtar(1) (in my case) too many ressources, so other tasks which require io are struggling to get some ressources assigned to them (ls(1) in my case). of course SCHED_4BSD isn't perfect, too. try using it and run the stress2 testsuite. your whole system will grind to a halt. mouse input drops below 1 HZ. even after killing all the stress2 tests, it will take a few minutes after the system becomes snappy again. cheers. alex -- http://ache.vniz.net/ ___ 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
stupid cp(1) behaviour
is there a chance to change cp's behaviour in connection with the -R switch, so that it stops after the first error? i just ran into the following situation: 1) cp -ai bla /mnt/umass 2) i got a lot of warnings that /mnt/umass was full 3) cp -an bla /mnt/umass 4) ...that didn't work, since cp created 0 byte files for all files it couldn't copy in 1. 5) what i had to do is 'find /mnt/umass/bla -type f - size 0 -delete' and then try 3 again of course, if cp would have bailed out after the first error, there still would be one file with actual file size. maybe the available filesize could be checked before crating the file, or another possibility: implement a new -N switch or so which isn't based on a file's existance, but a file's checksum. cheers. alex ___ 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: Remove debug echo
On Tue Nov 29 11, Warner Losh wrote:
kill it.
Warner
On Nov 29, 2011, at 2:07 PM, John Baldwin wrote:
Any objections to this? It removes a weird line during 'make -s
buildworld'
output and I think it was debugging accidentally left in in 213077 by
Warner:
Index: newvers.sh
===
--- newvers.sh (revision 228074)
+++ newvers.sh (working copy)
@@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do
done
if [ -n $svnversion ] ; then
- echo $svnversion
svn=`cd ${SYSDIR} $svnversion`
case $svn in
[0-9]*) svn= r${svn} ;;
also...
when running buildkernel via 'make -s', do we really need all those module
printfs? i see messages for cleandir, obj, depend and all. i think for
'make -s', that's pure overkill!
for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 and
you'll get 2680 lines of output. not really *silent*, is it? ;)
cheers.
alex
--
John Baldwin
___
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: Remove debug echo
On Wed Nov 30 11, Garrett Cooper wrote:
On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best arun...@freebsd.org wrote:
On Tue Nov 29 11, Warner Losh wrote:
kill it.
Warner
On Nov 29, 2011, at 2:07 PM, John Baldwin wrote:
Any objections to this? It removes a weird line during 'make -s
buildworld'
output and I think it was debugging accidentally left in in 213077 by
Warner:
Index: newvers.sh
===
--- newvers.sh (revision 228074)
+++ newvers.sh (working copy)
@@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do
done
if [ -n $svnversion ] ; then
- echo $svnversion
svn=`cd ${SYSDIR} $svnversion`
case $svn in
[0-9]*) svn= r${svn} ;;
also...
when running buildkernel via 'make -s', do we really need all those module
printfs? i see messages for cleandir, obj, depend and all. i think
for
'make -s', that's pure overkill!
for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 and
you'll get 2680 lines of output. not really *silent*, is it? ;)
pmake sucks as far as diagnostic output is concerned when compared
with gmake. I'd rather not have to fish through with -j1 (if I'm lucky
and it's not a race) to determine what directory created the Error
Code output. With the printouts discussed here, at least you have a
chance at determining what the issue was.
Maybe it's just me, but I like noisy builds -- otherwise the
amount of time I have to spend root-causing the issue becomes
expensive.
ehmmm...a noisy silent flag? i totally agree, if we're talking about 'make' in
its default mode, but what's the point of a silent flag, if it produces 2500
lines of output? nobody uses the -s flag for diagnostics. its purpose is to
build a kernel without producing a lot of output and also not fiddling with
stdout/stderr to achieve that goal.
cheers.
alex
Thanks,
-Garrett
___
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
possible array out of bounds access in sys/netinet/sctp_output.c
hi there, i've been playing with clang tot and noticed the following error: /usr/local/bin/clang -c -O3 -pipe -fno-inline-functions -fno-strict-aliasing -march=core2 -std=c99 -g -fdiagnostics-show-option -fformat-extensions -Wall -Wcast-qual -Winline -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wundef -Wno-pointer-sign -nostdinc -I. -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wno-error=tautological-compare -Wno-error=shift-count-negative -Wno-error=shift-count-overflow -Wno-error=shift-overflow -Wno-error=conversion -Wno-error=empty-body -Wno-error=gnu-designator -Wno-error=format -Wno-error=format-invalid-specifier -Wno-error=format-extra-args -Werror /usr/git-freebsd-head/sys/netinet/sctp_output.c clang: warning: argument unused during compilation: '-fformat-extensions' /usr/git-freebsd-head/sys/netinet/sctp_output.c:4685:2: error: array index 1 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] sup_addr-addr_type[1] = htons(SCTP_IPV6_ADDRESS); ^ ~ /usr/git-freebsd-head/sys/netinet/sctp_header.h:84:2: note: array 'addr_type' declared here uint16_t addr_type[SCTP_ARRAY_MIN_LEN]; /* array of supported address ^ 1 error generated. *** Error code 1 Stop in /usr/obj/usr/git-freebsd-head/sys/GENERIC. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. this is from a GENERIC kernel build (so INET + INET6) for amd64. is this a false positive, or is length(sup_addr-addr_type) really == 1, thus making sup_addr-addr_type[1] an illegal access? cheers. alex ___ 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: ee (easy editor) bugged on 9.0?
On Sun Nov 20 11, Jason Edwards wrote: On Sat, Nov 19, 2011 at 6:07 PM, Stefan Bethke s...@lassitu.de wrote: Am 19.11.2011 um 17:29 schrieb Jason Edwards: Dear list, Has anyone noticed the easy editor is quite bugged on 9.0? On console direct access, opening the easy editor has several bugs: 1) the cursor starts on line 2 instead of line 1 2) the line numbering is printed on line 1 instead of the boundary (line 0) 3) the keys page up and page down bring the escape menu Strange enough, if I SSH into the box the ee editor works normally. So I'm wondering if this is something other people have noticed? Just want to exclude the possibility of me doing something wrong. I've noticed this behavior on 9-CURRENT, 9.0-RC1 as well as 9.0-RC2, amd64. GENERIC kernel and tested inside Virtualbox. Working fine here on 9.0-RC1. Is this a fresh install, or did you upgrade? Have you updated your ttys to set the terminal type to xterm instead of cons25? This is a fresh install. I do make a LiveCD using scripted tools. But it pretty much is a vanilla FreeBSD install with just some packages preinstalled (webserver, php, etc). The only relevant changes I think are a change to /etc/ttys. But when I revert the file back to the defaults, the problem stays. I thought that perhaps Virtualbox had something to do with it, but it seems to happen on a real system as well. Some of you asked for the environmental settings. Using 'env' the output begins with: -- on console -- TERM=cons25 SHELL=/usr/local/bin/bash -- via SSH -- TERM=xterm SHELL=/usr/local/bin/bash Via SSH the ee editor works as it should. On the console it is bugged. i just grabbed a copy of FreeBSD-9.0-RC2-amd64-dvd1.iso and ran it in qemu. i noticed nothing irregular running ee. also TERM is set to xterm on the console. so this is either an issue with bash (have you tried running sh?) or something in your /etc is broken. cheers. alex Regards, Jason ___ 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: ee (easy editor) bugged on 9.0?
On Sat Nov 19 11, Garrett Cooper wrote: On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd adr...@freebsd.org wrote: .. how many users is this going to trip up? cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I went through several iterations with ed@ over the fact that various curses based apps were broken with the libteken work, but then just gave in and set 'xterm'. That being said, I can't reproduce the issue Jason mentioned in the first post. running a very recent HEAD doing 'export TERM=cons25' in zsh and then running 'ee', i can exactly reproduce this issue. cheers. alex 1. Have you rebuilt your termcap database? 2. What is your $TERM in the ssh case and the console case? Etc. Thanks, -Garrett ___ 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: ee (easy editor) bugged on 9.0?
On Sat Nov 19 11, Garrett Cooper wrote: On Sat, Nov 19, 2011 at 12:53 PM, Alexander Best arun...@freebsd.org wrote: On Sat Nov 19 11, Garrett Cooper wrote: On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd adr...@freebsd.org wrote: .. how many users is this going to trip up? cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I went through several iterations with ed@ over the fact that various curses based apps were broken with the libteken work, but then just gave in and set 'xterm'. That being said, I can't reproduce the issue Jason mentioned in the first post. running a very recent HEAD doing 'export TERM=cons25' in zsh and then running 'ee', i can exactly reproduce this issue. How are you accessing the terminal? I ask in part because of this email thread: http://comments.gmane.org/gmane.os.freebsd.current/136528 what do you mean? i fire up xterm (actually sakura in my case) and simply type 'export TERM=cons25'. this is on my local machine. however i tried the same over ssh, connecting to hub.freebsd.org (which is running7.4-STABLE, and got the same result. cheers. alex . Cheers, -Garrett ___ 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
issue with usb hdd
hi there, i recently bought a western digital 1 terrabyte usb2/usb3 hdd: [83611.209514] umass0: MSC Bulk-Only Transport on usbus3 [83613.618514] da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 [83613.618514] da0: WD My Passport 0740 1003 Fixed Direct Access SCSI-6 device [83613.618514] da0: 40.000MB/s transfers [83613.618514] da0: 953837MB (1953458176 512 byte sectors: 255H 63S/T 121597C) i partitioned it via the gpt scheme and one big ufs2 partition with SU+J enabled: Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 1953458142 first: 34 entries: 128 scheme: GPT Providers: 1. Name: da0p1 Mediasize: 1000170551808 (931G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 17408 Mode: r0w0e0 rawuuid: 39d3bf09-fb47-11e0-ade1-000fb58207c8 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 1000170551808 offset: 17408 type: freebsd-ufs index: 1 end: 1953458142 start: 34 Consumers: 1. Name: da0 Mediasize: 1000170586112 (931G) Sectorsize: 512 Mode: r0w0e0 =34 1953458109 da0 GPT (931G) 34 19534581091 freebsd-ufs (931G) tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) wd mounting and everything works great. however if i don't access the monted hdd for a couple of hours, and then do `ls /mnt/wd`, nothing is there. `mount -p` reports that the hdd is still mounted: /dev/ufs/rootfs / ufs ro 1 1 devfs /devdevfs rw 0 0 /dev/ufs/varfs /varufs rw 1 2 /dev/ufs/usrfs /usrufs rw 1 2 linprocfs /usr/compat/linux/proc linprocfs rw 0 0 linsysfs/usr/compat/linux/sys linsysfsrw 0 0 devfs /usr/compat/linux/dev devfs rw 0 0 linprocfs /usr/local/gentoo-stage3/proc linprocfs rw 0 0 linsysfs/usr/local/gentoo-stage3/sys linsysfs rw 0 0 devfs /usr/local/gentoo-stage3/dev devfs rw 0 0 tmpfs /tmptmpfs rw 0 0 tmpfs /var/tmptmpfs rw 0 0 /dev/ufs/wd /mnt/wd ufs rw,noexec,nosuid 0 0 `pwd` executed will return ENXIO. i can then do `umount /mnt/wd`, but re-mounting the hdd fails with the following dmesg warnings: [96836.840512] (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 0 0 0 0 0 [96836.840512] (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error [96836.840512] (probe0:umass-sim0:0:0:1): SCSI status: Check Condition [96836.840512] (probe0:umass-sim0:0:0:1): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) [97109.824517] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97109.824517] WARNING: Forced mount will invalidate journal contents [97126.200518] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97126.200518] WARNING: Forced mount will invalidate journal contents [97129.283518] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97129.283518] WARNING: Forced mount will invalidate journal contents [97133.904518] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97133.904518] WARNING: Forced mount will invalidate journal contents (i believe the probe0 stuff is from the umount) `mount` fails with EPERM btw. what i have to do is: `fsck /dev/ufs/wd`. this complains about the following: ** /dev/ufs/wd USE JOURNAL? [yn] y ** SU+J Recovering /dev/ufs/wd ** Reading 33554432 byte journal from inode 4. RECOVER? [yn] y ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. * FILE SYSTEM MARKED CLEAN * ...now everything is back to normal and i can mount the hdd again. any suggestions? i'm running a very recent HEAD on amd64. cheers. alex ___ freebsd-current@freebsd.org mailing
Re: 10.0-CUR r226986 ports (general)
On Thu Nov 3 11, Matthias Apitz wrote: El día Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias Apitz escribió: Hello, I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November 1st; The ports/audio/jack seems installing fine, but the shared lib libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it is mentioned in the list -L of the package; later ports/audio/arts and ports/x11/kde3 are missing the shared lib; It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as host_os: freebsd10.0 and the ./configure scripts have tests like this: ports/audio/jack/work/jack-audio-connection-kit-0.121.3: case $host_os in ... freebsd1*) dynamic_linker=no ;; ... And now? I'm cluesless now how we could solve this :-( are you sure this issue is related to the freebsd1* case? uname -a FreeBSD otaku 9.9-CURRENT FreeBSD 9.9-CURRENT #9: Thu Nov 3 11:41:08 CET 2011 arundel@otaku:/usr/obj/usr/git-freebsd-head/sys/ARUNDEL amd64 i did a 'cd /usr/ports/security/p11-kit ; make ; make install', yet from the following list: otaku% pkg_info -L p11-kit-0.8 Information for p11-kit-0.8: Files: /usr/local/bin/p11-kit /usr/local/include/p11-kit-1/p11-kit/p11-kit.h /usr/local/include/p11-kit-1/p11-kit/pin.h /usr/local/include/p11-kit-1/p11-kit/uri.h /usr/local/include/p11-kit-1/p11-kit/pkcs11.h /usr/local/lib/libp11-kit.a /usr/local/lib/libp11-kit.la /usr/local/lib/libp11-kit.so /usr/local/lib/libp11-kit.so.0 /usr/local/lib/p11-kit-proxy.so /usr/local/libdata/pkgconfig/p11-kit-1.pc /usr/local/share/gtk-doc/html/p11-kit/api-index-full.html /usr/local/share/gtk-doc/html/p11-kit/config-example.html /usr/local/share/gtk-doc/html/p11-kit/config-format.html /usr/local/share/gtk-doc/html/p11-kit/config-global.html /usr/local/share/gtk-doc/html/p11-kit/config-locations.html /usr/local/share/gtk-doc/html/p11-kit/config-module.html /usr/local/share/gtk-doc/html/p11-kit/config.html /usr/local/share/gtk-doc/html/p11-kit/gtk-doc.css /usr/local/share/gtk-doc/html/p11-kit/home.png /usr/local/share/gtk-doc/html/p11-kit/index.html /usr/local/share/gtk-doc/html/p11-kit/index.sgml /usr/local/share/gtk-doc/html/p11-kit/left.png /usr/local/share/gtk-doc/html/p11-kit/p11-kit-Future.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-Modules.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-PIN-Callbacks.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-URIs.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-Utilities.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit.devhelp2 /usr/local/share/gtk-doc/html/p11-kit/up.png /usr/local/share/gtk-doc/html/p11-kit/reference.html /usr/local/share/gtk-doc/html/p11-kit/right.png /usr/local/share/gtk-doc/html/p11-kit/sharing-initialize.html /usr/local/share/gtk-doc/html/p11-kit/sharing-module.html /usr/local/share/gtk-doc/html/p11-kit/sharing.html /usr/local/share/gtk-doc/html/p11-kit/style.css /usr/local/share/examples/p11-kit/pkcs11.conf.example all *.so* files didn't get installed! cheers. alex matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: 10.0-CUR r226986 ports (general)
On Thu Nov 3 11, Matthias Apitz wrote: El día Thursday, November 03, 2011 a las 11:28:47AM +, Alexander Best escribió: It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as host_os: freebsd10.0 and the ./configure scripts have tests like this: here's my config.log after building and installing security/p11-kit. i have edited my newvers.sh according to UPDATING and uname -a now properly reports: FreeBSD otaku 9.9-CURRENT FreeBSD 9.9-CURRENT #9: Thu Nov 3 11:41:08 CET 2011 arundel@otaku:/usr/obj/usr/git-freebsd-head/sys/ARUNDEL amd64 still for me the issue remains: no libs get built and thus not installed! cheers. alex ports/audio/jack/work/jack-audio-connection-kit-0.121.3: case $host_os in ... freebsd1*) dynamic_linker=no ;; ... And now? I'm cluesless now how we could solve this :-( are you sure this issue is related to the freebsd1* case? I can only comment what I saw: - OS was detected as freebsd10.0 (I inserted a 'echo $host_os' into the ./configure script - ./configure said that it should/will not build shared libs - the *.so* were missing in ports/audio/jack/work/... and in /usr/local/lib I will remove all /usr/ports/* and /usr/local/* and /var/db/pkg/* and will start from scratch with cvs checkout and will set UNAME_r as explained in ports/UPDATING; will let you know the result matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by p11-kit configure 0.8, which was generated by GNU Autoconf 2.68. Invocation command line was $ ./configure --disable-gtk-doc --disable-nls --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.9 ## - ## ## Platform. ## ## - ## hostname = otaku uname -m = amd64 uname -r = 9.9-CURRENT uname -s = FreeBSD uname -v = FreeBSD 9.9-CURRENT #9: Thu Nov 3 11:41:08 CET 2011 arundel@otaku:/usr/obj/usr/git-freebsd-head/sys/ARUNDEL /usr/bin/uname -p = amd64 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/local/diablo-jre1.6.0/bin ## --- ## ## Core tests. ## ## --- ## configure:2406: checking for a BSD-compatible install configure:2474: result: /usr/bin/install -c -o root -g wheel configure:2485: checking whether build environment is sane configure:2535: result: yes configure:2676: checking for a thread-safe mkdir -p configure:2715: result: ./install-sh -c -d configure:2728: checking for gawk configure:2758: result: no configure:2728: checking for mawk configure:2758: result: no configure:2728: checking for nawk configure:2744: found /usr/bin/nawk configure:2755: result: nawk configure:2766: checking whether make sets $(MAKE) configure:2788: result: yes configure:2868: checking whether build environment is sane configure:2918: result: yes configure:2921: checking whether to disable maintainer-specific portions of Makefiles configure:2930: result: yes configure:2986: checking build system type configure:3000: result: amd64-portbld-freebsd9.9 configure:3020: checking host system type configure:3033: result: amd64-portbld-freebsd9.9 configure:3074: checking how to print strings configure:3101: result: printf configure:3134: checking for style of include used by make configure:3162: result: GNU configure:3232: checking for gcc configure:3259: result: cc configure:3488: checking for C compiler version configure:3497: cc --version 5 cc (GCC) 4.2.2 20070831 prerelease [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3508: $? = 0 configure:3497: cc -v 5 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] configure:3508: $? = 0 configure:3497: cc -V 5 cc: '-V' option must have argument configure:3508: $? = 1 configure:3497: cc -qversion 5 cc: unrecognized option '-qversion' cc: No input files specified configure:3508: $? = 1 configure:3528: checking whether the C compiler works configure:3550: cc -O2 -pipe -frename-registers -march
Re: small devfs.conf patch
On Tue Oct 18 11, Andriy Gapon wrote: on 17/10/2011 23:01 Alexander Best said the following: hi there, any thoughts regarding this change? with the ata subsystem dying, linking to /dev/acd isn't really necessary any more. also a lot of ports nowadays depend on /dev/dvd. IMO, go for it. unfortunately i don't own a commit bit. -- Andriy Gapon ___ 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: [RFC] Prepend timestamp in msgbuf
On Fri Oct 14 11, Arnaud Lacombe wrote: Hi, On Fri, Oct 14, 2011 at 8:52 AM, Nali Toja nalit...@gmail.com wrote: Alexander Best arun...@freebsd.org writes: On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. maybe the granularity of the timestamps could be limited to a static value? the following output doesn't really look pretty: [7.729516] 118/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 blocks, 0.7% fragmentation) [7.891512] 118Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. [8.33519] . [9.440514] 118Setting hostname: otaku. [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 [9.850516] 118Starting wpa_supplicant. [10.335514] 118Starting Network: lo0 ath0. so it would be nice, if trailing zeros got printed out, too. Why not make formatting similar to linux/xorg logs, e.g. [ 31.897] (**) Option XkbLayout us [ 31.897] (II) XINPUT: Adding extended input device default keyboard (type: KEYBOARD, id 7) [ 11485.404] (II) 3rd Button detected: disabling emulate3Button [ 0.00] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 [ 0.00] Command line: root=/dev/disk/by-uuid/625db1f5-9b51-4d2d-acb7-6726f4d7e199 ro [...] [ 15.096862] NET: Registered protocol family 10 [ 16.792594] [drm] nouveau :01:00.0: plugged DVI-I-2 [ 26.054186] eth0: no IPv6 routers present A way to convert those timestamps to localtime or time delta[1] post-mortem via dmesg(8) would be good, too. well, I do not care for the pretty side of the thing, however, this is just a matter length modifier in the string format; should be trivial to fix. cc -c -O -pipe -march=core2 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -Wmissing-include-dirs -nostdinc -I. -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fformat-extensions -fdiagnostics-show-option -fstack-protector -Werror /usr/git-freebsd-head/sys/kern/subr_msgbuf.c cc1: warnings being treated as errors /usr/git-freebsd-head/sys/kern/subr_msgbuf.c: In function 'msgbuf_do_addchar': /usr/git-freebsd-head/sys/kern/subr_msgbuf.c:171: warning: format '%d' expects type 'int', but argument 4 has type 'time_t' [-Wformat] *** Error code 1 Stop in /usr/obj/usr/git-freebsd-head/sys/ARUNDEL. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. - Arnaud [1] like in tcpdump -ttt ___ 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: [RFC] Prepend timestamp in msgbuf
On Mon Oct 17 11, Arnaud Lacombe wrote: Hi, On Mon, Oct 17, 2011 at 2:01 PM, Alexander Best arun...@freebsd.org wrote: On Fri Oct 14 11, Arnaud Lacombe wrote: Hi, On Fri, Oct 14, 2011 at 8:52 AM, Nali Toja nalit...@gmail.com wrote: Alexander Best arun...@freebsd.org writes: On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. maybe the granularity of the timestamps could be limited to a static value? the following output doesn't really look pretty: [7.729516] 118/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 blocks, 0.7% fragmentation) [7.891512] 118Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. [8.33519] . [9.440514] 118Setting hostname: otaku. [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 [9.850516] 118Starting wpa_supplicant. [10.335514] 118Starting Network: lo0 ath0. so it would be nice, if trailing zeros got printed out, too. Why not make formatting similar to linux/xorg logs, e.g. [ 31.897] (**) Option XkbLayout us [ 31.897] (II) XINPUT: Adding extended input device default keyboard (type: KEYBOARD, id 7) [ 11485.404] (II) 3rd Button detected: disabling emulate3Button [ 0.00] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 [ 0.00] Command line: root=/dev/disk/by-uuid/625db1f5-9b51-4d2d-acb7-6726f4d7e199 ro [...] [ 15.096862] NET: Registered protocol family 10 [ 16.792594] [drm] nouveau :01:00.0: plugged DVI-I-2 [ 26.054186] eth0: no IPv6 routers present A way to convert those timestamps to localtime or time delta[1] post-mortem via dmesg(8) would be good, too. well, I do not care for the pretty side of the thing, however, this is just a matter length modifier in the string format; should be trivial to fix. cc -c -O -pipe -march=core2 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -Wmissing-include-dirs -nostdinc -I. -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fformat-extensions -fdiagnostics-show-option -fstack-protector -Werror /usr/git-freebsd-head/sys/kern/subr_msgbuf.c cc1: warnings being treated as errors /usr/git-freebsd-head/sys/kern/subr_msgbuf.c: In function 'msgbuf_do_addchar': /usr/git-freebsd-head/sys/kern/subr_msgbuf.c:171: warning: format '%d' expects type 'int', but argument 4 has type 'time_t' [-Wformat] *** Error code 1 Stop in /usr/obj/usr/git-freebsd-head/sys/ARUNDEL. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. FreeBSD has no time_t PRI... macros in any machine/_inttypes.h, eventually cast it to `long'. just wanted to tell you that your patch causes buildkernel to fail on certain archs (amd64 in my case) and that it appears you didn't run 'make universe-kernels' to check, whether your patch breaks anything. i'll leave the details to you. cheers. alex Btw, I appreciate the very clear message of yours, no Hi, no signature, no idea what ARUNDEL is, and especially no details on which architecture you are attempting to build, which should be, I assume, LP64 ;-) - Arnaud ___ 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
small devfs.conf patch
hi there, any thoughts regarding this change? with the ata subsystem dying, linking to /dev/acd isn't really necessary any more. also a lot of ports nowadays depend on /dev/dvd. cheers. alex diff --git a/etc/devfs.conf b/etc/devfs.conf index f7869fe..f3a270e 100644 --- a/etc/devfs.conf +++ b/etc/devfs.conf @@ -35,7 +35,8 @@ #link ttyv0 vga # Commonly used by many ports -#link acd0cdrom +#link cd0 cdrom +#link cd0 dvd # Allow a user in the wheel group to query the smb0 device #perm smb00660 ___ 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: [RFC] Prepend timestamp in msgbuf
On Mon Oct 17 11, Arnaud Lacombe wrote: Hi, On Mon, Oct 17, 2011 at 3:44 PM, Alexander Best arun...@freebsd.org wrote: On Mon Oct 17 11, Arnaud Lacombe wrote: Hi, On Mon, Oct 17, 2011 at 2:01 PM, Alexander Best arun...@freebsd.org wrote: On Fri Oct 14 11, Arnaud Lacombe wrote: Hi, On Fri, Oct 14, 2011 at 8:52 AM, Nali Toja nalit...@gmail.com wrote: Alexander Best arun...@freebsd.org writes: On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. maybe the granularity of the timestamps could be limited to a static value? the following output doesn't really look pretty: [7.729516] 118/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 blocks, 0.7% fragmentation) [7.891512] 118Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. [8.33519] . [9.440514] 118Setting hostname: otaku. [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 [9.850516] 118Starting wpa_supplicant. [10.335514] 118Starting Network: lo0 ath0. so it would be nice, if trailing zeros got printed out, too. Why not make formatting similar to linux/xorg logs, e.g. [ 31.897] (**) Option XkbLayout us [ 31.897] (II) XINPUT: Adding extended input device default keyboard (type: KEYBOARD, id 7) [ 11485.404] (II) 3rd Button detected: disabling emulate3Button [ 0.00] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 [ 0.00] Command line: root=/dev/disk/by-uuid/625db1f5-9b51-4d2d-acb7-6726f4d7e199 ro [...] [ 15.096862] NET: Registered protocol family 10 [ 16.792594] [drm] nouveau :01:00.0: plugged DVI-I-2 [ 26.054186] eth0: no IPv6 routers present A way to convert those timestamps to localtime or time delta[1] post-mortem via dmesg(8) would be good, too. well, I do not care for the pretty side of the thing, however, this is just a matter length modifier in the string format; should be trivial to fix. cc -c -O -pipe -march=core2 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -Wmissing-include-dirs -nostdinc -I. -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fformat-extensions -fdiagnostics-show-option -fstack-protector -Werror /usr/git-freebsd-head/sys/kern/subr_msgbuf.c cc1: warnings being treated as errors /usr/git-freebsd-head/sys/kern/subr_msgbuf.c: In function 'msgbuf_do_addchar': /usr/git-freebsd-head/sys/kern/subr_msgbuf.c:171: warning: format '%d' expects type 'int', but argument 4 has type 'time_t' [-Wformat] *** Error code 1 Stop in /usr/obj/usr/git-freebsd-head/sys/ARUNDEL. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. FreeBSD has no time_t PRI... macros in any machine/_inttypes.h, eventually cast it to `long'. just wanted to tell you that your patch causes buildkernel to fail on certain archs (amd64 in my case) and that it appears you didn't run 'make universe-kernels' to check, whether your patch breaks anything. i'll leave the details to you. I have no interest testing architectures/kernels I have no interest in. Of course, this statement only apply as long as I have no full control over the future of the feature. sorry i was under the impression that this feature was a candidate to make it into HEAD. - Arnaud
Re: [RFC] Prepend timestamp in msgbuf
On Fri Oct 14 11, Nikolay Denev wrote: On Oct 13, 2011, at 9:40 PM, Arnaud Lacombe wrote: Hi, On Thu, Oct 13, 2011 at 2:00 PM, lacom...@gmail.com wrote: From: Arnaud Lacombe lacom...@gmail.com Hi folks, There is many case recently when I really wished timestamp were present in the post-mortem msgbuf. Such situation could be when userland application segfault potentially triggering a panic/crash, or have information about the time-wise location of a given message (kernel or userland). Attached patch is available in the git repository at: git://github.com/lacombar/freebsd.git master/topic/msgbuf-timestamp Arnaud Lacombe (3): msgbuf(4): convert `msg_needsnl' to a bit flag msgbuf(4): add logic to prepend timestamp on new line msgbuf(4): add a sysctl to toggle timestamp prepend sys/kern/subr_msgbuf.c | 53 --- sys/sys/msgbuf.h |4 ++- 2 files changed, 48 insertions(+), 9 deletions(-) Cool! I've dreamt for something like this for a long time, it can be very useful. great work! a have a few comments however: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? 2) my dmesg output contains a lot of these entries: 118 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? 4) maybe a new dmesg flag would be a good idea to suppress timestamps. cheers. alex Regards, Nikolay ___ 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: [RFC] Prepend timestamp in msgbuf
On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. cheers. alex -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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: [RFC] Prepend timestamp in msgbuf
On Fri Oct 14 11, Alexander Best wrote: On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. maybe the granularity of the timestamps could be limited to a static value? the following output doesn't really look pretty: [7.729516] 118/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 blocks, 0.7% fragmentation) [7.891512] 118Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. [8.33519] . [9.440514] 118Setting hostname: otaku. [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 [9.850516] 118Starting wpa_supplicant. [10.335514] 118Starting Network: lo0 ath0. so it would be nice, if trailing zeros got printed out, too. cheers. alex cheers. alex -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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: [RFC] Prepend timestamp in msgbuf
On Fri Oct 14 11, Alexander Best wrote: On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. or even better: if timestamp == 1.0 then simply don't ouput it at all. cheers. alex -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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: [head tinderbox] failure on powerpc/powerpc
On Wed Oct 5 11, FreeBSD Tinderbox wrote: TB --- 2011-10-05 12:55:29 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-05 12:55:29 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-05 12:55:29 - cleaning the object tree TB --- 2011-10-05 12:55:43 - cvsupping the source tree TB --- 2011-10-05 12:55:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-05 12:55:55 - building world TB --- 2011-10-05 12:55:55 - CROSS_BUILD_TESTING=YES TB --- 2011-10-05 12:55:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-05 12:55:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-05 12:55:55 - SRCCONF=/dev/null TB --- 2011-10-05 12:55:55 - TARGET=powerpc TB --- 2011-10-05 12:55:55 - TARGET_ARCH=powerpc TB --- 2011-10-05 12:55:55 - TZ=UTC TB --- 2011-10-05 12:55:55 - __MAKE_CONF=/dev/null TB --- 2011-10-05 12:55:55 - cd /src TB --- 2011-10-05 12:55:55 - /usr/bin/make -B buildworld World build started on Wed Oct 5 12:55:56 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/grep/util.c cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/grep/regex/fastmatch.c cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/grep/regex/hashtable.c cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/grep/regex/tre-compile.c cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/grep/regex/tre-fastmatch.c [..] -Wno-unused-parameter [..] -Wunused-parameter ? cheers. alex cc1: warnings being treated as errors /src/usr.bin/grep/regex/tre-fastmatch.c: In function 'tre_match_fast': /src/usr.bin/grep/regex/tre-fastmatch.c:961: warning: comparison of unsigned expression 0 is always false *** Error code 1 Stop in /src/usr.bin/grep. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-10-05 14:43:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-05 14:43:43 - ERROR: failed to build world TB --- 2011-10-05 14:43:43 - 5199.23 user 882.58 system 6494.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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: [head tinderbox] failure on powerpc/powerpc
On Wed Oct 5 11, Alexander Best wrote:
On Wed Oct 5 11, FreeBSD Tinderbox wrote:
TB --- 2011-10-05 12:55:29 - tinderbox 2.8 running on
freebsd-current.sentex.ca
TB --- 2011-10-05 12:55:29 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2011-10-05 12:55:29 - cleaning the object tree
TB --- 2011-10-05 12:55:43 - cvsupping the source tree
TB --- 2011-10-05 12:55:43 - /usr/bin/csup -z -r 3 -g -L 1 -h
cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2011-10-05 12:55:55 - building world
TB --- 2011-10-05 12:55:55 - CROSS_BUILD_TESTING=YES
TB --- 2011-10-05 12:55:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-10-05 12:55:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-10-05 12:55:55 - SRCCONF=/dev/null
TB --- 2011-10-05 12:55:55 - TARGET=powerpc
TB --- 2011-10-05 12:55:55 - TARGET_ARCH=powerpc
TB --- 2011-10-05 12:55:55 - TZ=UTC
TB --- 2011-10-05 12:55:55 - __MAKE_CONF=/dev/null
TB --- 2011-10-05 12:55:55 - cd /src
TB --- 2011-10-05 12:55:55 - /usr/bin/make -B buildworld
World build started on Wed Oct 5 12:55:56 UTC 2011
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything
[...]
cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/src/usr.bin/grep/util.c
cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/src/usr.bin/grep/regex/fastmatch.c
cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/src/usr.bin/grep/regex/hashtable.c
cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/src/usr.bin/grep/regex/tre-compile.c
cc -O2 -pipe -I/src/usr.bin/grep/regex -I/usr/include/gnu -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/src/usr.bin/grep/regex/tre-fastmatch.c
[..] -Wno-unused-parameter [..] -Wunused-parameter ?
any thoughts about
diff --git a/share/mk/bsd.sys.mk b/share/mk/bsd.sys.mk
index 796d169..a6127bf 100644
--- a/share/mk/bsd.sys.mk
+++ b/share/mk/bsd.sys.mk
@@ -36,12 +36,12 @@ CWARNFLAGS += -Werror
CWARNFLAGS += -Wall -Wno-format-y2k
. endif
. if ${WARNS} = 3
-CWARNFLAGS += -W -Wno-unused-parameter -Wstrict-prototypes\
+CWARNFLAGS += -Wextra -Wstrict-prototypes\
-Wmissing-prototypes -Wpointer-arith
. endif
. if ${WARNS} = 4
CWARNFLAGS += -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch\
- -Wshadow -Wunused-parameter
+ -Wshadow
. if !defined(NO_WCAST_ALIGN)
CWARNFLAGS += -Wcast-align
. endif
@@ -56,6 +56,9 @@ CWARNFLAGS+= -Wchar-subscripts -Winline
-Wnested-externs\
# XXX always get it right.
CWARNFLAGS += -Wno-uninitialized
. endif
+. if ${WARNS} == 3
+CWARNFLAGS += -Wno-unused-parameter
+. endif
CWARNFLAGS += -Wno-pointer-sign
. endif
?
-Wunused-parameter seems to be enforced by -Wunsed, which seems
Re: buildworld failure
On Mon Aug 15 11, Robert Watson wrote: On Sun, 14 Aug 2011, Alexander Best wrote: has anybody seen this buildworld failure? Could you try the attached patch and see if it helps? I currently have it in the re@ approval queue. It does appear to fix the problem here. thanks. the patch fixes the issue. Generally, I would strongly advise against using modules built with world, and wonder if we should be de-supporting that explicitly at this point. Checking that the below works for you would be great, but you might not want to use MODULES_WITH_WORLD anymore. usually i set MODULES_OVERRIDE =, because i don't have time to wait for buildkernel compiling all the modules. however i thought it might be handy to have the kernel modules available, so i set MODULES_WITH_WORLD instead. of course i know that building/installing a new kernel and keeping the old modules is not really a great idea, because quite often the outdated modules will fail to load. yet for me it's a timer saver and still gives me the option of loading a certain module. so personally i'd like to see MODULES_WITH_WORLD support stay. but if people decide it should go then that's not too much of a problem with me. ;) cheers. alex (If we do want to keep MODULES_WITH_WORLD, we may want to add it to the tinderboxes.) Robert -- Fix two cases involving opt_capsicum.h and module builds: (1) opt_capsicum.h is no longer required in ffs_alloc.c, so remove the #include. (2) portalfs depends on opt_capsicum.h, so have the Makefile generate one if required. Note, however, that attempting to use modules built without a kernel configuration is a bad idea generally -- it's a bit worrying that we still provide MODULES_WITH_WORLD. Approved by: re (xxx) Sponsored by: Google Inc Index: ufs/ffs/ffs_alloc.c === --- ufs/ffs/ffs_alloc.c (revision 224860) +++ ufs/ffs/ffs_alloc.c (working copy) @@ -62,7 +62,6 @@ #include sys/cdefs.h __FBSDID($FreeBSD$); -#include opt_capsicum.h #include opt_quota.h #include sys/param.h Index: modules/portalfs/Makefile === --- modules/portalfs/Makefile (revision 224860) +++ modules/portalfs/Makefile (working copy) @@ -4,6 +4,7 @@ KMOD=portalfs SRCS=vnode_if.h \ - portal_vfsops.c portal_vnops.c + portal_vfsops.c portal_vnops.c \ + opt_capsicum.h .include bsd.kmod.mk ___ 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: kernel panic caused by Opera 11.50
On Sun Aug 14 11, Alvaro Castillo wrote: uname -a: FreeBSD shuttle0.lan 9.0-BETA1 FreeBSD 9.0-BETA1 #2: Mon Aug 8 17:05:59 WEST 2011 net...@shuttle0.lan:/usr/obj/usr/src/sys/HYDROGEN amd64 kernel panic: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x fault code = supervisor write data, page not present instruction pointer = 0x20:0x804bfff0 stack pointer = 0x28:0xff8223c4ba40 frame pointer = 0x28:0xff8223c4ba60 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2691 (operapluginwrapper.) Step to reproduce: 1. Open Opera 11.50 browser 2. Try to enter to Gmail or any web page with flash player and panic! try http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html -- netSys-- http://www.byteandbit.info ___ 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: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.
On Sun Aug 14 11, Niclas Zeising wrote:
On 2011-08-13 12:08, Roland Smith wrote:
On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
On 08/13/11 09:26, Roland Smith wrote:
On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
On 08/12/11 22:54, Roland Smith wrote:
On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
Does this file actually exist if you extract the snapshot? And are the
permissions et cetera OK?
Roland
No, it does not.
What I did so far over night:
I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again.
Again failure.
After that it got the ports tree via CVS (make update in /usr/ports).
Everything seems
all right. I tried portsnap again. portsnap compalins about a
non-portsnap-created /usr/ports
and please me to use 'extract'. I do ... but then I run into the very
same failure:
(portsnap fetch extract:)
/usr/ports/devel//
/usr/ports/devel/ccdoc/
/usr/ports/devel/ccrtp/
/usr/ports/devel/cdash/
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
not
found -- snapshot corrupt.
I've been looking at the portsnap shellscript. This error message is
generated
by the shell's built-in test command, specifically '[ -r'. It is looking
for a
file that was extracted with tar. So the place to look for the bug is IMO
1) the portsnap script itself (differences between 8.2 and 9?)
2) the sh(1)'s built-in test command (ditto)
3) tar (ditto)
When you run 'portsnap fetch' it downloads a tgz archive and unpacks it with
tar(1). What you could try is to comment out the line 'rm
${SNAPSHOTHASH}.tgz'
in portsnap, and test if the tgz file extracts differently using an
8.2-RELEASE tar and the 9-CURRENT tar. If so, that would be a bug!
Roland
Just a me too!. It happens for me on a recently updated 9-current
virtual machine, built with clang.
same here:
/usr/ports/databases/gigabase/
/usr/ports/databases/godis/
files/39644d98f9e9b9d9a362cbfc075a996683e8a611a4362d883247c9a2e2fa2658.gz not
found -- snapshot corrupt.
running r224841 on amd64 built with base clang.
Regards!
--
Niclas
___
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: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun Aug 14 11, Test Rat wrote: Test Rat ttse...@gmail.com writes: Eduardo Morras nec...@retena.com writes: At 22:06 13/08/2011, Steven Hartland wrote: i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. There is kgzldr that lets you boot compressed kernels. Try $ gzip /boot/kernel/* $ reboot the above works for me. just booted a compressed kernel. Nevermind, I've confused it with gzip support in loader, it also has bzip2 support which for some reason doesn't work for me bzf_read: BZ2_bzDecompress returned -3 ___ 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: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.
On Sun Aug 14 11, Olivier Smedts wrote:
2011/8/14 Alexander Best arun...@freebsd.org:
On Sun Aug 14 11, Niclas Zeising wrote:
On 2011-08-13 12:08, Roland Smith wrote:
On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
On 08/13/11 09:26, Roland Smith wrote:
On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
On 08/12/11 22:54, Roland Smith wrote:
On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
Does this file actually exist if you extract the snapshot? And are the
permissions et cetera OK?
Roland
No, it does not.
What I did so far over night:
I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again.
Again failure.
After that it got the ports tree via CVS (make update in /usr/ports).
Everything seems
all right. I tried portsnap again. portsnap compalins about a
non-portsnap-created /usr/ports
and please me to use 'extract'. I do ... but then I run into the very
same failure:
(portsnap fetch extract:)
/usr/ports/devel//
/usr/ports/devel/ccdoc/
/usr/ports/devel/ccrtp/
/usr/ports/devel/cdash/
files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
not
found -- snapshot corrupt.
I've been looking at the portsnap shellscript. This error message is
generated
by the shell's built-in test command, specifically '[ -r'. It is looking
for a
file that was extracted with tar. So the place to look for the bug is IMO
1) the portsnap script itself (differences between 8.2 and 9?)
2) the sh(1)'s built-in test command (ditto)
3) tar (ditto)
When you run 'portsnap fetch' it downloads a tgz archive and unpacks it
with
tar(1). What you could try is to comment out the line 'rm
${SNAPSHOTHASH}.tgz'
in portsnap, and test if the tgz file extracts differently using an
8.2-RELEASE tar and the 9-CURRENT tar. If so, that would be a bug!
Roland
Just a me too!. It happens for me on a recently updated 9-current
virtual machine, built with clang.
same here:
/usr/ports/databases/gigabase/
/usr/ports/databases/godis/
files/39644d98f9e9b9d9a362cbfc075a996683e8a611a4362d883247c9a2e2fa2658.gz
not found -- snapshot corrupt.
running r224841 on amd64 built with base clang.
Aparently fixed with latest HEAD *kernel* :
# svn log -v -r224842
r224842 | rwatson | 2011-08-13 18:03:40 +0200 (sam 13 aoû 2011) | 10 lignes
Chemins modifiés :
M /head/sys/kern/vfs_syscalls.c
When falloc() was broken into separate falloc_noinstall() and finstall(),
a bug was introduced in kern_openat() such that the error from the vnode
open operation was overwritten before it was passed as an argument to
dupfdopen(). This broke operations on /dev/{stdin,stdout,stderr}. Fix
by preserving the original error number across finstall() so that it is
still available.
Approved by:re (kib)
Reported by:cognet
You won't be able to buildworld with the buggy kernel, but you can
buildkernel and reboot on the new kernel. No problems with portsnap
after that (don't know if you have to clean the old portsnap files, I
did it).
thanks. switching to a newer revision alone didn't solve the issue. however
after doing
rm -r /var/db/portsnap/files/; rm /var/db/portsnap/t*; portsnap fetch update
everything's back to normal. :)
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org - against HTML email vCards X
www: http://www.gid0.org - against proprietary attachments / \
Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas.
___
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
buildworld failure
hi there, has anybody seen this buildworld failure? === sys/modules/portalfs (depend) @ - /usr/git-freebsd-head/sys machine - /usr/git-freebsd-head/sys/amd64/include x86 - /usr/git-freebsd-head/sys/x86/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend CC='clang' mkdep -f .depend -a -nostdinc -DSTRIP_FBSDID -D_KERNEL -DKLD_MODULE -I. -I@ -I@/contrib/altq /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vfsops.c /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vnops.c /usr/git-freebsd-head/sys/modules/portalfs/../../fs/portalfs/portal_vnops.c:41:10: fatal error: 'opt_capsicum.h' file not found #include opt_capsicum.h ^ 1 error generated. mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error cheers. alex ___ 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: Crash kernel in linux module...
On Sat Aug 13 11, fidaj wrote: Hello all! I have: uname -a FreeBSD nonamehost 9.0-BETA1 FreeBSD 9.0-BETA1 #0 r224806: Sat Aug 13 11:17:49 EEST 2011 ivan@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 After update source code r224728 to r224806 - my kernel smash when i start the game WorldOfGoo. My computer just reboots. Before the upgrade was not like this... :( Last message in //var/log/messages ... Aug 13 02:02:40 nonamehost last message repeated 4 times Aug 13 02:05:40 nonamehost last message repeated 6 times Aug 13 02:05:49 nonamehost kernel: linux: pid 4157 (WorldOfGoo.bin32): linux_sys_futex: op LINUX_FUTEX_UNLOCK_PI not implemented Aug 13 02:05:49 nonamehost kernel: ... Aug 13 02:13:17 nonamehost kernel: linux: pid 3893 (WorldOfGoo.bin32): linux_sys_futex: op LINUX_FUTEX_UNLOCK_PI not implemented Aug 13 02:13:17 nonamehost kernel: ... What has happened since then? What other information do I provide? are you running the nvidia drivers? if yes, then please see http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html cheers. alex Thanks! ___ 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
[rfc] replacing /boot/kernel.old with a unique directory name
hi there,
i just had the following idea: how about instead of copying the current kernel
to /boot/kernel.old and then installing the new one under /boot/kernel as the
results of target installkernel, we create a unique directory name for the old
kernel?
something like /boot/kernel-r${revision}-${/dev/random}?
that would let people not only boot the previous kernel, but all kernels that
have been replaced by target installkernel. this would make tracking issues,
which have been introduced by a certain commit much easier, imho.
i don't think implementing this logic would be that difficult. the only problem
i see is with ${/dev/random} in the case where people are running a kernel
without /dev/{u}random support.
cheers.
alex
___
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: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat Aug 13 11, Chris Rees wrote:
On 13 August 2011 20:51, Alexander Best arun...@freebsd.org wrote:
hi there,
i just had the following idea: how about instead of copying the current
kernel
to /boot/kernel.old and then installing the new one under /boot/kernel as
the
results of target installkernel, we create a unique directory name for the
old
kernel?
something like /boot/kernel-r${revision}-${/dev/random}?
that would let people not only boot the previous kernel, but all kernels
that
have been replaced by target installkernel. this would make tracking issues,
which have been introduced by a certain commit much easier, imho.
i don't think implementing this logic would be that difficult. the only
problem
i see is with ${/dev/random} in the case where people are running a kernel
without /dev/{u}random support.
cheers.
alex
mktemp?
ahh. nice. unless mktemp(1) relies on device random, that sounds like a good
solution. :)
Chris
___
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: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat Aug 13 11, Garrett Cooper wrote:
On Aug 13, 2011, at 12:51 PM, Alexander Best arun...@freebsd.org wrote:
hi there,
i just had the following idea: how about instead of copying the current
kernel
to /boot/kernel.old and then installing the new one under /boot/kernel as
the
results of target installkernel, we create a unique directory name for the
old
kernel?
something like /boot/kernel-r${revision}-${/dev/random}?
that would let people not only boot the previous kernel, but all kernels
that
have been replaced by target installkernel. this would make tracking issues,
which have been introduced by a certain commit much easier, imho.
i don't think implementing this logic would be that difficult. the only
problem
i see is with ${/dev/random} in the case where people are running a kernel
without /dev/{u}random support.
Why not just use INSTKERNNAME?
hmm...won't setting INSTKERNNAME set the path to where the new kernel will be
installed and not where the current kernel will be backup'ed?
-Garrett
___
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
recent commit causes lock up
hi there, running r224715 i'm having no problems what so ever. after upgrading my kernel to r224784, i'm experiencing fatal lock ups, where only a hard reset will resolve the problem. the lock up happend two times while running chromium with only a decent number of tabs (~ 5). also the lock up occured only after ~ 5 minutes uptime and an uptime of chromium of only ~ 2 minutes. i've now reverted my kernel back to r224715 and everything's working again. cheers. alex ___ 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: recent commit causes lock up
On Fri Aug 12 11, Test Rat wrote: Alexander Best arun...@freebsd.org writes: hi there, running r224715 i'm having no problems what so ever. after upgrading my kernel to r224784, i'm experiencing fatal lock ups, where only a hard reset will resolve the problem. the lock up happend two times while running chromium with only a decent number of tabs (~ 5). also the lock up occured only after ~ 5 minutes uptime and an uptime of chromium of only ~ 2 minutes. i've now reverted my kernel back to r224715 and everything's working again. Do you use x11/nvidia-driver? In r224778 fget(9) KPI changed which broke the port in src/nvidia_linux.c:linux_ioctl_nvidia(). It's probably only called when using linuxolator, e.g. flash plugin. Try below workaround. thanks i'll try the patch later on. indeed i'm using the nvidia drivers and i think the freeze might in fact be related to flash. did r224778 introduce a version bump of freebsd? cheers. alex %% --- src/nvidia_linux.c~ +++ src/nvidia_linux.c @@ -26,6 +26,8 @@ #include machine/../linux32/linux32_proto.h #endif +#include sys/capability.h + int linux_ioctl_nvidia(d_thread_t *, struct linux_ioctl_args *); int linux_ioctl_nvidia( @@ -37,7 +39,7 @@ int linux_ioctl_nvidia( int error; u_long cmd; -if ((error = fget(td, args-fd, fp)) != 0) +if ((error = fget(td, args-fd, CAP_IOCTL, fp)) != 0) return error; cmd = args-cmd; %% ___ 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: recent commit causes lock up
On Fri Aug 12 11, Test Rat wrote: Alexander Best arun...@freebsd.org writes: hi there, running r224715 i'm having no problems what so ever. after upgrading my kernel to r224784, i'm experiencing fatal lock ups, where only a hard reset will resolve the problem. the lock up happend two times while running chromium with only a decent number of tabs (~ 5). also the lock up occured only after ~ 5 minutes uptime and an uptime of chromium of only ~ 2 minutes. i've now reverted my kernel back to r224715 and everything's working again. Do you use x11/nvidia-driver? In r224778 fget(9) KPI changed which broke the port in src/nvidia_linux.c:linux_ioctl_nvidia(). It's probably only called when using linuxolator, e.g. flash plugin. Try below workaround. thanks. i just tried your patch and indeed: the nvidia driver was causing the freeze. that should teach me a lessing always to compile 3rd party kernel modules in combination with installing a new kernel. ;) %% --- src/nvidia_linux.c~ +++ src/nvidia_linux.c @@ -26,6 +26,8 @@ #include machine/../linux32/linux32_proto.h #endif +#include sys/capability.h + int linux_ioctl_nvidia(d_thread_t *, struct linux_ioctl_args *); int linux_ioctl_nvidia( @@ -37,7 +39,7 @@ int linux_ioctl_nvidia( int error; u_long cmd; -if ((error = fget(td, args-fd, fp)) != 0) +if ((error = fget(td, args-fd, CAP_IOCTL, fp)) != 0) return error; cmd = args-cmd; %% ___ 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: HEAD after 9-BETA1 broken
On Wed Aug 10 11, René Ladan wrote:
Hi,
it seems that HEAD is broken somewhere after 9.0-BETA1 amd64:
acer % pwd
/usr/src
acer % svn info
Path: .
URL: svn+ssh://svn.freebsd.org/base/head
Repository Root: svn+ssh://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 224747
Node Kind: directory
Schedule: normal
Last Changed Author: kevlo
Last Changed Rev: 224747
Last Changed Date: 2011-08-10 08:17:06 +0200 (wo, 10 aug 2011)
acer % svn diff
Index: sys/modules/Makefile
===
--- sys/modules/Makefile (revision 224747)
+++ sys/modules/Makefile (working copy)
@@ -335,6 +335,7 @@
${_xe} \
xfs \
xl \
+ xtaf \
${_zfs} \
zlib \
Index: sys/modules/geom/Makefile
===
--- sys/modules/geom/Makefile (revision 224747)
+++ sys/modules/geom/Makefile (working copy)
@@ -28,6 +28,7 @@
geom_vinum \
geom_virstor \
geom_vol_ffs \
+ geom_xbox360 \
geom_zero
.include bsd.subdir.mk
acer % cat /usr/src/sys/amd64/conf/ACER
include GENERIC
options CAPABILITIES
acer % make buildkernel
--
Kernel build for ACER started on Wed Aug 10 08:21:53 CEST 2011
--
=== ACER
mkdir -p /usr/obj/usr/src/sys
[...]
--
stage 2.3: build tools
--
cd /usr/obj/usr/src/sys/ACER;
MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make SSP_CFLAGS=
-DNO_CPU_CFLAGS -DNO_CTF -f /usr/src/sys/dev/aic7xxx/aicasm/Makefile
Warning: Object directory not changed from original /usr/obj/usr/src/sys/ACER
yacc -b aicasm_gram -d -o aicasm_gram.c
/usr/src/sys/dev/aic7xxx/aicasm/aicasm_gram.y
yacc -b aicasm_macro_gram -p mm -d -o aicasm_macro_gram.c
/usr/src/sys/dev/aic7xxx/aicasm/aicasm_macro_gram.y
clang -O2 -pipe -nostdinc -I/usr/include -I.
-I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wno-pointer-sign -c /usr/src/sys/dev/aic7xxx/aicasm/aicasm.c
clang -O2 -pipe -nostdinc -I/usr/include -I.
-I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wno-pointer-sign -c /usr/src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c
clang -O2 -pipe -nostdinc -I/usr/include -I.
-I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wno-pointer-sign -c aicasm_gram.c
clang -O2 -pipe -nostdinc -I/usr/include -I.
-I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wno-pointer-sign -c aicasm_macro_gram.c
lex -t /usr/src/sys/dev/aic7xxx/aicasm/aicasm_scan.l aicasm_scan.c
clang -O2 -pipe -nostdinc -I/usr/include -I.
-I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wno-pointer-sign -c aicasm_scan.c
/usr/src/sys/dev/aic7xxx/aicasm/aicasm_scan.l:843:12: error: function 'input'
is
not needed and will not be emitted
[-Werror,-Wunneeded-internal-declaration]
static int input(void)
^
problem here is that -Werror got set. could you try removing the following
part from your make.conf:
.if !empty(.CURDIR:M/usr/src*)
# Don't die on warnings
NO_WERROR=
WERROR=
.endif
and add
# Don't die on warnings
NO_WERROR=
WERROR=
to your src.conf?
cheers.
alex
1 error generated.
*** Error code 1
Stop in /usr/obj/usr/src/sys/ACER.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
acer %
/etc/make.conf is attached.
René
--
http://www.rene-ladan.nl/
GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6
(subkeys.pgp.net)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
Re: awk(1) segfaults when building kernel modules
On Wed Aug 10 11, Navdeep Parhar wrote: On Wed, Aug 10, 2011 at 11:12 AM, Test Rat ttse...@gmail.com wrote: `make -s buildkernel' seems to contain lots of segfaults after recent update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk. just out of curiosity: what's the point of doing a vendor import during a beta phase? isn't this exactly the kind of stuff you DON'T want to do, because it can only turn out badly? imho r224731 should completely be reverted. aren't those exactly the kind of commits re@ shouldn't approve? cheers. alex ... Anyone else? I see this too. ___ 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: makefs(8) broken iso9660 images
On Wed Aug 10 11, Test Rat wrote: A quick example $ mkdir -p q/a q/b q/c q/d $ touch q/a/foo.c q/b/foo.c q/c/foo.c q/d/foo.c $ makefs -t cd9660 q.iso q $ tar tf q.iso . A B A/FOO.C B/FOO.C C D $ mkisofs -quiet -o q.iso q $ tar tf q.iso . A B C D D/FOO.C C/FOO.C B/FOO.C A/FOO.C $ makefs -t cd9660 inc.iso /usr/include $ tar tvvf inc.iso tar: Invalid location of extent of file Archive Format: ISO9660, Compression: none tar: Error exit delayed from previous errors. $ mkisofs -quiet -o inc.iso /usr/include mkisofs: Symlink /usr/include/float.h ignored - continuing. mkisofs: Symlink /usr/include/syslog.h ignored - continuing. mkisofs: Symlink /usr/include/sched.h ignored - continuing. [...] $ tar tvvf inc.iso drwx-- 54 0 0 12288 Aug 10 15:26 . drwx-- 2 0 02048 Jun 14 01:40 NETATALK [...] -r 1 0 06324 Jun 14 01:40 GSSAPI/GSSAPI_K.H Archive Format: ISO9660, Compression: none And for more real example grab a bootonly image from allbsd.org though official BETA1 would suffice, too, and try to extract kernel e.g. $ sha256 -q FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso 9b8beabe007f88f85f3fc59dd1b40ce212132dde173e03d4a93d48a5477989a4 $ tar tf FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso | fgrep -i kernel [nothing] $ mount -t cd9660 /dev/$(mdconfig -f FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso) /media $ ls -1 /media/boot/kernel aac.ko accf_data.ko accf_dns.ko accf_http.ko acpi_asus.ko acpi_dock.ko acpi_fujitsu.ko acpi_hp.ko acpi_ibm.ko acpi_panasonic.ko ^C And the following is probably known but doesn't happen with 8.2-RELEASE image. $ find /media/usr/include /dev/null find: /media/usr/include/c++/4.2/ext/pb_ds/detail/basic_tree_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/binary_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/binomial_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/binomial_heap_base_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/bin_search_tree_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/cc_hash_table_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/eq_fn: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/gp_hash_table_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/hash_fn: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/left_child_next_sibling_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/list_update_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/list_update_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/ov_tree_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/pairing_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/pat_trie_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/rb_tree_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/rc_binomial_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/resize_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/splay_tree_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/thin_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/tree_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/trie_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/unordered_iterator: Input/output error Am I alone in seeing this? was this fixed by rr224762? -- FreeBSD 9.0-BETA1 r224746M amd64, clang-built ___ 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: issues with bsdgrep and lang/go
On Tue Aug 9 11, Jason Hellenthal wrote: So has the maintainer of bsdgrep updated it yet so these things do not happen ?, if not (and apparently not) I don't understand why you are explicitly defaulting your gnugrep to a broken bsdgrep. This was a known problem a few months back and I for one have not seen updates on that yet. well i'd like to help the author of bsdgrep to improve it. testing it and then going back to gnu grep, because bsdgrep still has bugs isn't going to help much. by using it i'd like to trip over these kind of bugs and report them. but you're right...the author hasn't really paid a lot of attention to bsdgrep, lately. :( i guess that's a problem when you have an open os, where everybody can do as much or as little as it pleases him. ;) Debugging pencil should be handy in this case. On Tue, Aug 09, 2011 at 08:18:42AM +, Alexander Best wrote: hi there, i'm running HEAD on amd64 with bsdgrep (WITH_BSD_GREP=true). i noticed the lang/go port won't build due to errors caused by egrep. this might be a ports issue, but to me it rather looks like bsdgrep is not behaving exactly the same, as gnu grep. however i haven't tried building the port with gnu grep. maybe somebody could check that out. the port errors are of the following form: [...] gmake -C 6g install gmake[1]: Entering directory `/usr/ports/lang/go/work/go-20110515/src/cmd/6g' quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/list.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/gobj.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/galign.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/ggen.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/cgen.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c -I. -o cplx.o ../gc/cplx.c [...] cheers. alex ___ 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 ___ 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
issues with bsdgrep and lang/go
hi there, i'm running HEAD on amd64 with bsdgrep (WITH_BSD_GREP=true). i noticed the lang/go port won't build due to errors caused by egrep. this might be a ports issue, but to me it rather looks like bsdgrep is not behaving exactly the same, as gnu grep. however i haven't tried building the port with gnu grep. maybe somebody could check that out. the port errors are of the following form: [...] gmake -C 6g install gmake[1]: Entering directory `/usr/ports/lang/go/work/go-20110515/src/cmd/6g' quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/list.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/gobj.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/galign.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/ggen.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/cgen.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from|from: No such file or directory quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c -I. -o cplx.o ../gc/cplx.c [...] cheers. alex ___ 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: issues with bsdgrep and lang/go
On Tue Aug 9 11, Test Rat wrote: Alexander Best arun...@freebsd.org writes: [...] gmake -C 6g install gmake[1]: Entering directory `/usr/ports/lang/go/work/go-20110515/src/cmd/6g' quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c /usr/ports/lang/go/work/go-20110515/src/cmd/6g/list.c egrep: : error: .Each undeclared identifier|: error: for each function it appears|is dangerous, better use|is almost always misused|: In function |: At top level: |In file included from| from: No such file or directory Do you use GREP_OPTIONS? otaku% type $GREP_OPTIONS otaku% echo foo | env -i GREP_OPTIONS= bsdgrep foo env: bsdgrep: No such file or directory otaku% $ echo foo | env -i GREP_OPTIONS= bsdgrep foo bsdgrep: foo: No such file or directory ___ 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: issues with bsdgrep and lang/go
On Tue Aug 9 11, Test Rat wrote:
Alexander Best arun...@freebsd.org writes:
On Tue Aug 9 11, Test Rat wrote:
Alexander Best arun...@freebsd.org writes:
[...]
gmake -C 6g install
gmake[1]: Entering directory
`/usr/ports/lang/go/work/go-20110515/src/cmd/6g'
quietgcc -I/usr/ports/lang/go/work/go-20110515/include -ggdb -O2 -c
/usr/ports/lang/go/work/go-20110515/src/cmd/6g/list.c
egrep: : error: .Each undeclared identifier|: error: for each function
it appears|is dangerous, better use|is almost always misused|: In
function |: At top level: |In file included from| from: No such file
or directory
Do you use GREP_OPTIONS?
otaku% type $GREP_OPTIONS
otaku% echo foo | env -i GREP_OPTIONS= bsdgrep foo
env: bsdgrep: No such file or directory
otaku%
Actually, it's lang/go that seems to set the environment variable.
$ fgrep -r GREP_OPTIONS $(make -V WRKSRC)
.../src/cmd/gc/mkopnames:export GREP_OPTIONS=
.../src/Make.inc:GREP_OPTIONS:=
.../src/Make.inc:export LANG LC_ALL LC_CTYPE GREP_OPTIONS GREP_COLORS
.../src/Make.inc: @echo export GREP_OPTIONS=$(GREP_OPTIONS)
.../test/run:unset GREP_OPTIONS # in case user has a non-standard set
.../doc/devel/weekly.html:* build: clear custom variables like GREP_OPTIONS,
Try below workaround. It also makes empty GREP_COLOR behave like gnugrep(1).
thanks a bunch. after applying your patch lang/go builds without any issues! :)
cheers.
alex
%%
Index: usr.bin/grep/grep.c
===
--- usr.bin/grep/grep.c (revision 224705)
+++ usr.bin/grep/grep.c (working copy)
@@ -304,7 +304,7 @@ init_color(const char *d)
char *c;
c = getenv(GREP_COLOR);
- return (c != NULL ? c : d);
+ return (c != NULL c[0] != '\0' ? c : d);
}
int
@@ -360,7 +360,7 @@ main(int argc, char *argv[])
/* support for extra arguments in GREP_OPTIONS */
eargc = 0;
- if (eopts != NULL) {
+ if (eopts != NULL eopts[0] != '\0') {
char *str;
/* make an estimation of how many extra arguments we have */
@@ -373,6 +373,7 @@ main(int argc, char *argv[])
eargc = 0;
/* parse extra arguments */
while ((str = strsep(eopts, )) != NULL)
+ if(*str != '\0')
eargv[eargc++] = grep_strdup(str);
aargv = (char **)grep_calloc(eargc + argc + 1,
%%
___
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: chromium port causing massive I/O faults
On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Alexander Best arun...@freebsd.org: On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Gleb Kurtsou gleb.kurt...@gmail.com: On (27/07/2011 00:48), Alexander Best wrote: On Mon Jul 25 11, Matthias Andree wrote: Am 25.07.2011 09:21, schrieb Alexander Best: On Mon Jul 25 11, Adrian Chadd wrote: Is it perhaps doing disk IO using mmap? how can i check, whether that's the case or not? Use truss(1) for instance. However, unless there are *practical* problems, a high number of page faults is not an indication for problems. Although it may sound scary, page faults are a feature of the memory management. unfortunately truss(1) is crashing chromium :( i opened up a new thread reagarding this issue on freebsd-current@. Could you try ktrace? It works for me another thing i noticed is the increase in system calls caused by chromium. let's have a look at hub.freebsd.org: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls About 2.5k syscalls with chrome + a lot of other stuff running. 1.5k without chrome. Looks like there is a lot of clock_gettime and gettimeofday syscalls. ~ % kdump -m 1 -f ktrace.out | grep 'CALL .*gettime' | wc -l 24343 ~ % kdump -E -m 1 -f ktrace.out | grep 'CALL .*gettime' | tail -20 12747 chrome 15.077376 CALL gettimeofday(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) Some work was done by kib@ to create a kernel page strong current time and other misc info to eliminate gettimeofday kind syscalls. Bits of it were commited but I'm not sure if it was finished. But anyway calling gettimeofday hundreds of times per second is a chrome bug. FreeBSD 9.0-CURRENT #2 r224003+777e962: Thu Jul 14 13:04:55 EEST 2011 chromium-11.0.696.57_1 ^ Can you retry with an up-to-date version of www/chromium? The codebase of chromium changes quite fast so not using the latest version in ports might render obsolete (and upstream unsupported) results. my tests were done with chromium-12.0.742.124 btw. Ok, I'll do some tests with the beta version from the chruetertee repository (13.0.782.99). it looks as if this issue was fixed somewhere between 14.0.797.0 and 14.0.817.0 according to http://code.google.com/p/chromium/issues/detail?id=77625 René -- http://www.rene-ladan.nl/ ___ 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: chromium port causing massive I/O faults
On Wed Jul 27 11, Gleb Kurtsou wrote: On (27/07/2011 00:48), Alexander Best wrote: On Mon Jul 25 11, Matthias Andree wrote: Am 25.07.2011 09:21, schrieb Alexander Best: On Mon Jul 25 11, Adrian Chadd wrote: Is it perhaps doing disk IO using mmap? how can i check, whether that's the case or not? Use truss(1) for instance. However, unless there are *practical* problems, a high number of page faults is not an indication for problems. Although it may sound scary, page faults are a feature of the memory management. unfortunately truss(1) is crashing chromium :( i opened up a new thread reagarding this issue on freebsd-current@. Could you try ktrace? It works for me another thing i noticed is the increase in system calls caused by chromium. let's have a look at hub.freebsd.org: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls About 2.5k syscalls with chrome + a lot of other stuff running. 1.5k without chrome. Looks like there is a lot of clock_gettime and gettimeofday syscalls. ~ % kdump -m 1 -f ktrace.out | grep 'CALL .*gettime' | wc -l 24343 ~ % kdump -E -m 1 -f ktrace.out | grep 'CALL .*gettime' | tail -20 12747 chrome 15.077376 CALL gettimeofday(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) Some work was done by kib@ to create a kernel page strong current time and other misc info to eliminate gettimeofday kind syscalls. Bits of it were commited but I'm not sure if it was finished. But anyway calling gettimeofday hundreds of times per second is a chrome bug. *lol* i did exactly the same measurements, you did. :) here are my results: otaku% kdump|grep CALL mmap|wc 7242896 58468 otaku% kdump -s|grep CALL clock_gettime|wc 49545 198180 2772674 otaku% kdump -s|grep CALL linux_clock_gettime|wc 40185 160740 2491298 otaku% kdump -s|grep CALL linux_gettimeofday|wc 21670 86680 1278530 otaku% kdump -s|grep CALL gettimeofday|wc 8173 32692 525053 otaku% kdump -s|grep CALL linux_sys_futex|wc 6191 24764 548800 cheers. alex FreeBSD 9.0-CURRENT #2 r224003+777e962: Thu Jul 14 13:04:55 EEST 2011 chromium-11.0.696.57_1 i ran the following command twice. first time without running chromium and the second time with chromium running: otaku% vmstat -s|grep system calls; sleep 1; vmstat -s|grep system calls 2178187850 system calls 2178189739 system calls otaku% vmstat -s|grep system calls; sleep 1; vmstat -s|grep system calls 2177998835 system calls 2178022003 system calls so it's 2k/sec vs. 23k/sec cheers. alex ___ 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: chromium port causing massive I/O faults
On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Gleb Kurtsou gleb.kurt...@gmail.com: On (27/07/2011 00:48), Alexander Best wrote: On Mon Jul 25 11, Matthias Andree wrote: Am 25.07.2011 09:21, schrieb Alexander Best: On Mon Jul 25 11, Adrian Chadd wrote: Is it perhaps doing disk IO using mmap? how can i check, whether that's the case or not? Use truss(1) for instance. However, unless there are *practical* problems, a high number of page faults is not an indication for problems. Although it may sound scary, page faults are a feature of the memory management. unfortunately truss(1) is crashing chromium :( i opened up a new thread reagarding this issue on freebsd-current@. Could you try ktrace? It works for me another thing i noticed is the increase in system calls caused by chromium. let's have a look at hub.freebsd.org: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls About 2.5k syscalls with chrome + a lot of other stuff running. 1.5k without chrome. Looks like there is a lot of clock_gettime and gettimeofday syscalls. ~ % kdump -m 1 -f ktrace.out | grep 'CALL .*gettime' | wc -l 24343 ~ % kdump -E -m 1 -f ktrace.out | grep 'CALL .*gettime' | tail -20 12747 chrome 15.077376 CALL gettimeofday(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) Some work was done by kib@ to create a kernel page strong current time and other misc info to eliminate gettimeofday kind syscalls. Bits of it were commited but I'm not sure if it was finished. But anyway calling gettimeofday hundreds of times per second is a chrome bug. FreeBSD 9.0-CURRENT #2 r224003+777e962: Thu Jul 14 13:04:55 EEST 2011 chromium-11.0.696.57_1 ^ Can you retry with an up-to-date version of www/chromium? The codebase of chromium changes quite fast so not using the latest version in ports might render obsolete (and upstream unsupported) results. my tests were done with chromium-12.0.742.124 btw. René -- http://www.rene-ladan.nl/ ___ 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: chromium port causing massive I/O faults
On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Alexander Best arun...@freebsd.org: On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Gleb Kurtsou gleb.kurt...@gmail.com: On (27/07/2011 00:48), Alexander Best wrote: On Mon Jul 25 11, Matthias Andree wrote: Am 25.07.2011 09:21, schrieb Alexander Best: On Mon Jul 25 11, Adrian Chadd wrote: Is it perhaps doing disk IO using mmap? how can i check, whether that's the case or not? Use truss(1) for instance. However, unless there are *practical* problems, a high number of page faults is not an indication for problems. Although it may sound scary, page faults are a feature of the memory management. unfortunately truss(1) is crashing chromium :( i opened up a new thread reagarding this issue on freebsd-current@. Could you try ktrace? It works for me another thing i noticed is the increase in system calls caused by chromium. let's have a look at hub.freebsd.org: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls About 2.5k syscalls with chrome + a lot of other stuff running. 1.5k without chrome. Looks like there is a lot of clock_gettime and gettimeofday syscalls. ~ % kdump -m 1 -f ktrace.out | grep 'CALL .*gettime' | wc -l 24343 ~ % kdump -E -m 1 -f ktrace.out | grep 'CALL .*gettime' | tail -20 12747 chrome 15.077376 CALL gettimeofday(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) Some work was done by kib@ to create a kernel page strong current time and other misc info to eliminate gettimeofday kind syscalls. Bits of it were commited but I'm not sure if it was finished. But anyway calling gettimeofday hundreds of times per second is a chrome bug. ...also the number of context switches is very high. the following 'vmstat -s' output was taken after only 32 minutes of uptime and chromium running for ~ 10 minutes: 39775038 cpu context switches 1716910 device interrupts 1707161 software interrupts 1764371 traps 57319358 system calls 15 kernel threads created 2120 fork() calls 11 vfork() calls 25 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 71184 vnode pager pageins 102181 vnode pager pages paged in 13321 vnode pager pageouts 67437 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 4662 pages reactivated 93964 copy-on-write faults 274 copy-on-write optimized faults 358563 zero fill pages zeroed 319 zero fill pages prezeroed 302 intransit blocking page faults 740518 total VM faults taken 0 pages affected by kernel thread creation 1130760 pages affected by fork() 17316 pages affected by vfork() 22319 pages affected by rfork() 7162 pages cached 693935 pages freed 0 pages freed by daemon 396060 pages freed by exiting processes 34690 pages active 88551 pages inactive 164 pages in VM cache 76703 pages wired down 301738 pages free 4096 bytes per page 426219 total name lookups cache hits (87% pos + 2% neg) system 0
Re: chromium port causing massive I/O faults
On Wed Jul 27 11, Gleb Kurtsou wrote: On (27/07/2011 09:18), Alexander Best wrote: On Wed Jul 27 11, Gleb Kurtsou wrote: On (27/07/2011 00:48), Alexander Best wrote: On Mon Jul 25 11, Matthias Andree wrote: Am 25.07.2011 09:21, schrieb Alexander Best: On Mon Jul 25 11, Adrian Chadd wrote: Is it perhaps doing disk IO using mmap? how can i check, whether that's the case or not? Use truss(1) for instance. However, unless there are *practical* problems, a high number of page faults is not an indication for problems. Although it may sound scary, page faults are a feature of the memory management. unfortunately truss(1) is crashing chromium :( i opened up a new thread reagarding this issue on freebsd-current@. Could you try ktrace? It works for me another thing i noticed is the increase in system calls caused by chromium. let's have a look at hub.freebsd.org: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls About 2.5k syscalls with chrome + a lot of other stuff running. 1.5k without chrome. Looks like there is a lot of clock_gettime and gettimeofday syscalls. ~ % kdump -m 1 -f ktrace.out | grep 'CALL .*gettime' | wc -l 24343 ~ % kdump -E -m 1 -f ktrace.out | grep 'CALL .*gettime' | tail -20 12747 chrome 15.077376 CALL gettimeofday(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) Some work was done by kib@ to create a kernel page strong current time and other misc info to eliminate gettimeofday kind syscalls. Bits of it were commited but I'm not sure if it was finished. But anyway calling gettimeofday hundreds of times per second is a chrome bug. *lol* i did exactly the same measurements, you did. :) here are my results: otaku% kdump|grep CALL mmap|wc 7242896 58468 otaku% kdump -s|grep CALL clock_gettime|wc 49545 198180 2772674 otaku% kdump -s|grep CALL linux_clock_gettime|wc 40185 160740 2491298 otaku% kdump -s|grep CALL linux_gettimeofday|wc 21670 86680 1278530 otaku% kdump -s|grep CALL gettimeofday|wc 8173 32692 525053 otaku% kdump -s|grep CALL linux_sys_futex|wc 6191 24764 548800 I suppose linux_* stuff comes from flashplugin. Clearly flash generates more gettime syscalls than chrome itself. Unfortunately the only way to fix this mess in a linux centric world is to implement syscall free gettimeofday with linux ABI support. syscall-free gettimeofday discussion: http://freebsd.1045724.n5.nabble.com/fast-syscall-free-gettimeofday-td4488301.html thanks. this linux article is also very interesting in this context: http://lwn.net/Articles/18411/ ...they sorta claim that implementing gettimeofday() in userland is extremely difficult. cheers. alex ___ 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: issues with vmstat and latest HEAD
On Tue Jul 26 11, Alexander Best wrote: hi there, 'vmstat -m' and 'vmstat -z' report: otaku% vmstat -m vmstat: memstat_sysctl_malloc: Too many CPUs otaku% vmstat -z vmstat: memstat_sysctl_uma: Too many CPUs world and kernel are in sync. i'm running r224294 on amd64. please disregard this thread. there's a discussion on svn-src-head@ which deals with this issue. cheers. alex cheers. alex ___ 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: issues with vmstat and latest HEAD
On Wed Jul 27 11, Brandon Gooch wrote: On Jul 27, 2011 7:58 AM, Alexander Best arun...@freebsd.org wrote: On Tue Jul 26 11, Alexander Best wrote: hi there, 'vmstat -m' and 'vmstat -z' report: otaku% vmstat -m vmstat: memstat_sysctl_malloc: Too many CPUs otaku% vmstat -z vmstat: memstat_sysctl_uma: Too many CPUs world and kernel are in sync. i'm running r224294 on amd64. please disregard this thread. there's a discussion on svn-src-head@ which deals with this issue. cheers. alex cheers. alex Do you have a link to the discussion handy? http://www.mail-archive.com/svn-src-head@freebsd.org/msg14793.html -Brandon ___ 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
issues with vmstat and latest HEAD
hi there, 'vmstat -m' and 'vmstat -z' report: otaku% vmstat -m vmstat: memstat_sysctl_malloc: Too many CPUs otaku% vmstat -z vmstat: memstat_sysctl_uma: Too many CPUs world and kernel are in sync. i'm running r224294 on amd64. cheers. alex ___ 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
truss crashing process
hi there,
i was trying to attach truss to chromium via
'truss -p 18445' and got:
[...]
kevent(26,{},0,{0x1b,EVFILT_READ,0x0,0,0x1,0x44cb600 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0},64,{9.469312000 }) = 116 (0x74)
-- UNKNOWN SYSCALL -14720592 --
write(-14720976,0x8080808080808000,0)= 41 (0x29)
select(94,0x6acd,{0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31 40 41 42 43 44 45 46 70 71 72 73 76 77 78 79 80 81 82
84 87 88 91},0x1,{0.85048848 }) = 73 (0x49)
-- UNKNOWN SYSCALL 303120384 --
#94(0x0,0x0,0x5e,0xb6cd600,0x83ed780,0x3dae410) = 189 (0xbd)
truss: Cannot malloc -14740096 bytes for fd_set array: Cannot allocate memory
... this is 100% reproducable, if i wait long enough. this will crash truss
along with chromium.
using '-f' in addition to the flags above gives me:
[...]
truss: Cannot malloc -4220992 bytes for fd_set array: Cannot allocate memory
otaku% truss: can not attach to target process: No such process
strange thing though, when i redirect the first command via ' bla 21', truss
leaves behind a core file, because it segfaults. without redirecting the
output, no core file gets created, because truss doesn't segfault.
cheers.
alex
___
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: chromium port causing massive I/O faults
On Mon Jul 25 11, Matthias Andree wrote: Am 25.07.2011 09:21, schrieb Alexander Best: On Mon Jul 25 11, Adrian Chadd wrote: Is it perhaps doing disk IO using mmap? how can i check, whether that's the case or not? Use truss(1) for instance. However, unless there are *practical* problems, a high number of page faults is not an indication for problems. Although it may sound scary, page faults are a feature of the memory management. unfortunately truss(1) is crashing chromium :( i opened up a new thread reagarding this issue on freebsd-current@. another thing i noticed is the increase in system calls caused by chromium. let's have a look at hub.freebsd.org: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls i ran the following command twice. first time without running chromium and the second time with chromium running: otaku% vmstat -s|grep system calls; sleep 1; vmstat -s|grep system calls 2178187850 system calls 2178189739 system calls otaku% vmstat -s|grep system calls; sleep 1; vmstat -s|grep system calls 2177998835 system calls 2178022003 system calls so it's 2k/sec vs. 23k/sec cheers. alex ___ 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: chromium port causing massive I/O faults
On Mon Jul 25 11, Adrian Chadd wrote: Is it perhaps doing disk IO using mmap? how can i check, whether that's the case or not? adrian On 25 July 2011 05:25, Alexander Best arun...@freebsd.org wrote: hi there, i noticed that chromium, expecially in combination with nspluginwrapper and flash, is causing a lot of I/O faults. i ran 'top -mio -I -n 99' and after only ~ 4 hours of running chromium (most of the time not loading any new pages), i got the following data: last pid: 39976; load averages: 0.37, 0.26, 0.19 up 3+02:38:30 23:15:26 72 processes: 2 running, 70 sleeping Mem: 755M Active, 662M Inact, 447M Wired, 51M Cache, 212M Buf, 45M Free Swap: 10G Total, 159M Used, 10G Free, 1% Inuse PID UID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 39908 1001 7409 51112 0 0 4 4 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39605 1001 598315 233115 11 0 3 14 0.01% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 1752 1001 22292378 29644471 138 0 696 834 0.38% /usr/local/bin/Xorg -nolisten inet6 1756 1001 1551733 2002630 480 0 455 935 0.43% /usr/local/bin/awesome 39140 1001 10672291 1240670 0 0 6522 6522 2.97% chrome: --type=zygote (chrome) 39116 1001 5967965 3237798 8249 20401 136394 165044 75.14% chromium-browser: (chrome) 39138 1001 6436642 994546 0 0 1785 1785 0.81% chrome: --type=zygote (chrome) 39135 1001 4334272 169320 0 0 1723 1723 0.78% chrome: --type=zygote (chrome) 39133 1001 4321593 169574 1 0 1717 1718 0.78% chrome: --type=zygote (chrome) 39132 1001 4292029 164913 6 0 1766 1772 0.81% chrome: --type=zygote (chrome) 39137 1001 4152284 139225 1 0 1762 1763 0.80% chrome: --type=zygote (chrome) 1629 560 356784 70399 25 0 40 65 0.03% /usr/local/sbin/hald 1767 1001 355603 87998 32 0 0 32 0.01% /usr/local/libexec/gam_server 39144 1001 2659919 409841 0 0 3578 3578 1.63% chrome: --type=plugin --plugin-path=/usr/home/arundel/.mozill 10217 1001 472898 258689 601 1 8 610 0.28% /usr/local/bin/musicpd /usr/local/etc/musicpd.conf 39121 1001 552140 44286 1 0 181 182 0.08% chrome: --type=zygote (chrome) 39358 1001 103237 20357 223 1479 211 1913 0.87% /usr/local/bin/sakura 39119 1001 91173 58899 2 0 14795 14797 6.74% chrome: --type=zygote (chrome) 39846 1001 275524 51575 0 0 7085 7085 3.23% chrome: --type=zygote (chrome) 39120 1001 60470 18204 0 0 22 22 0.01% chrome: --type=zygote (chrome) 1538 0 53910 6390 0 0 1 1 0.00% sendmail: accepting connections (sendmail) 39363 1001 33822 9157 1 1113 3 1117 0.51% /usr/local/bin/sakura 39805 1001 55542 43060 0 0 2787 2787 1.27% chrome: --type=zygote (chrome) 39117 1001 2935 13041 156 0 155 311 0.14% chromium-browser: (chrome) 39902 1001 43829 31005 0 0 4477 4477 2.04% chrome: --type=zygote (chrome) 362 0 28923 1878 1 0 5 6 0.00% /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant 1548 0 5122 672 11 0 0 11 0.01% /usr/sbin/cron -s 1217 0 13118 676 21 39 0 60 0.03% /usr/sbin/syslogd -s 39907 1001 16179 6366 0 0 2 2 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39118 1001 976 716 90 0 81 171 0.08% chrome: --type=zygote (chrome) 1345 0 1362 201 1 0 2 3 0.00% /usr/local/sbin/smartd -p /var/run/smartd.pid -c /usr/local/et 1685 1001 180 22 52 0 30 82 0.04% -zsh (zsh) 1458 65534 512 62 2 0 0 2 0.00% /usr/local/bin/mpdscribble --daemon-user nobody 39360 1001 394 287 14 0 5 19 0.01% /usr/local/bin/zsh 1636 0 184 181 8 0 0 8 0.00% hald-runner 39365 1001 98 113 18 0 0 18 0.01% /usr/local/bin/zsh 1633 0 648 133 29 0 5 34 0.02% /usr/local/libexec/polkitd 1631 0 608 71 15 0 24 39 0.02% /usr/local/sbin/console-kit-daemon --no-daemon 39931 1001 53 81 1 0 1 2 0.00% /usr/local/bin/zsh 1713 1001 21 16 0 0 2 2 0.00% ssh-agent 1352 556 176
chromium port causing massive I/O faults
hi there, i noticed that chromium, expecially in combination with nspluginwrapper and flash, is causing a lot of I/O faults. i ran 'top -mio -I -n 99' and after only ~ 4 hours of running chromium (most of the time not loading any new pages), i got the following data: last pid: 39976; load averages: 0.37, 0.26, 0.19 up 3+02:38:3023:15:26 72 processes: 2 running, 70 sleeping Mem: 755M Active, 662M Inact, 447M Wired, 51M Cache, 212M Buf, 45M Free Swap: 10G Total, 159M Used, 10G Free, 1% Inuse PIDUID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 39908 1001 7409 51112 0 0 4 4 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39605 1001 598315 233115 11 0 3 14 0.01% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 1752 1001 22292378 29644471138 0696834 0.38% /usr/local/bin/Xorg -nolisten inet6 1756 1001 1551733 2002630480 0455935 0.43% /usr/local/bin/awesome 39140 1001 10672291 1240670 0 0 6522 6522 2.97% chrome: --type=zygote (chrome) 39116 1001 5967965 3237798 8249 20401 136394 165044 75.14% chromium-browser: (chrome) 39138 1001 6436642 994546 0 0 1785 1785 0.81% chrome: --type=zygote (chrome) 39135 1001 4334272 169320 0 0 1723 1723 0.78% chrome: --type=zygote (chrome) 39133 1001 4321593 169574 1 0 1717 1718 0.78% chrome: --type=zygote (chrome) 39132 1001 4292029 164913 6 0 1766 1772 0.81% chrome: --type=zygote (chrome) 39137 1001 4152284 139225 1 0 1762 1763 0.80% chrome: --type=zygote (chrome) 1629560 356784 70399 25 0 40 65 0.03% /usr/local/sbin/hald 1767 1001 355603 87998 32 0 0 32 0.01% /usr/local/libexec/gam_server 39144 1001 2659919 409841 0 0 3578 3578 1.63% chrome: --type=plugin --plugin-path=/usr/home/arundel/.mozill 10217 1001 472898 258689601 1 8610 0.28% /usr/local/bin/musicpd /usr/local/etc/musicpd.conf 39121 1001 552140 44286 1 0181182 0.08% chrome: --type=zygote (chrome) 39358 1001 103237 20357223 1479211 1913 0.87% /usr/local/bin/sakura 39119 100191173 58899 2 0 14795 14797 6.74% chrome: --type=zygote (chrome) 39846 1001 275524 51575 0 0 7085 7085 3.23% chrome: --type=zygote (chrome) 39120 100160470 18204 0 0 22 22 0.01% chrome: --type=zygote (chrome) 1538 053910 6390 0 0 1 1 0.00% sendmail: accepting connections (sendmail) 39363 100133822 9157 1 1113 3 1117 0.51% /usr/local/bin/sakura 39805 100155542 43060 0 0 2787 2787 1.27% chrome: --type=zygote (chrome) 39117 1001 2935 13041156 0155311 0.14% chromium-browser: (chrome) 39902 100143829 31005 0 0 4477 4477 2.04% chrome: --type=zygote (chrome) 362 028923 1878 1 0 5 6 0.00% /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant 1548 0 5122672 11 0 0 11 0.01% /usr/sbin/cron -s 1217 013118676 21 39 0 60 0.03% /usr/sbin/syslogd -s 39907 100116179 6366 0 0 2 2 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39118 1001 976716 90 0 81171 0.08% chrome: --type=zygote (chrome) 1345 0 1362201 1 0 2 3 0.00% /usr/local/sbin/smartd -p /var/run/smartd.pid -c /usr/local/et 1685 1001 180 22 52 0 30 82 0.04% -zsh (zsh) 1458 65534 512 62 2 0 0 2 0.00% /usr/local/bin/mpdscribble --daemon-user nobody 39360 1001 394287 14 0 5 19 0.01% /usr/local/bin/zsh 1636 0 184181 8 0 0 8 0.00% hald-runner 39365 1001 98113 18 0 0 18 0.01% /usr/local/bin/zsh 1633 0 648133 29 0 5 34 0.02% /usr/local/libexec/polkitd 1631 0 608 71 15 0 24 39 0.02% /usr/local/sbin/console-kit-daemon --no-daemon 39931 1001 53 81 1 0 1 2 0.00% /usr/local/bin/zsh 1713 1001 21 16 0 0 2 2 0.00% ssh-agent 1352556 176125 2 0 0 2 0.00% /usr/local/bin/dbus-daemon --system 1494 0 62 17 45 0 14 59 0.03% /usr/local/sbin/cupsd -C /usr/local/etc/cups/cupsd.conf 1733 1001 20 0 1 0 0 1 0.00% /bin/sh /usr/local/bin/startx 1617 0 33 15 7 0 0 7 0.00% login [pam] (login) 1751 1001
buildworld failing in lib/libc/db/btree
hi there, for some reason buildworld always fails in lib/libc/db/btree :( clang: /usr/bin/clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -march=core2 -I/usr/git-freebsd-head/lib/libc/include -I/usr/git-freebsd-head/lib/libc/../../include -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/git-freebsd-head/lib/libc/. /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:2: warning: implicit declaration of function '__PAST_END' is invalid in C99 [-Wimplicit-function-declaration] __PAST_END(h-linp, 1) = h-upper -= NRINTERNAL; ^ /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:25: error: expression is not assignable __PAST_END(h-linp, 1) = h-upper -= NRINTERNAL; ~~ ^ /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:538:26: error: expression is not assignable __PAST_END(h-linp, 1) = h-upper -= nbytes; ~~ ^ /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:554:26: error: expression is not assignable __PAST_END(h-linp, 1) = h-upper -= nbytes; ~~ ^ 1 warning and 3 errors generated. *** Error code 1 Stop in /usr/git-freebsd-head/lib/libc. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. gcc: /usr/bin/cc -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -frename-registers -march=core2 -I/usr/git-freebsd-head/lib/libc/include -I/usr/git-freebsd-head/lib/libc/../../include -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/git-freebsd /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c: In function 'bt_rroot': /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486: warning: implicit declaration of function '__PAST_END' /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486: error: lvalue required as left operand of assignment /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c: In function 'bt_broot': /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:538: error: lvalue required as left operand of assignment /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:554: error: lvalue required as left operand of assignment *** Error code 1 Stop in /usr/git-freebsd-head/lib/libc. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. ...any recommendations how i can fix this? i'm tracking HEAD btw. cheers. alex ___ 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: buildworld failing in lib/libc/db/btree
On Thu Jul 21 11, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/21/11 00:08, Alexander Best wrote: hi there, for some reason buildworld always fails in lib/libc/db/btree :( clang: /usr/bin/clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -march=core2 -I/usr/git-freebsd-head/lib/libc/include -I/usr/git-freebsd-head/lib/libc/../../include -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/git-freebsd-head/lib/libc/. /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:2: warning: implicit declaration of function '__PAST_END' is invalid in C99 [-Wimplicit-function-declaration] __PAST_END(h-linp, 1) = h-upper -= NRINTERNAL; This is quite weird, __PAST_END is defined in sys/param.h... And it compiled just fine here, what's your hosting system? amd64. param.h might be the problem: otaku% grep PAST_END /usr/git-freebsd-head/sys/sys/param.h #define __PAST_END(array, offset) (((typeof(*(array)) *)(array))[offset]) otaku% grep PAST_END /usr/include/sys/param.h ...maybe copying /usr/git-freebsd-head/sys/sys/param.h to /usr/include/sys manually will solve the issue? cheers. alex Cheers, - -- Xin LI delp...@delphij.net https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJOJ9KBAAoJEATO+BI/yjfBnRQIAKGRJezmtmjmICp68nEIYmTR /VH/Y+ubIwCFBagwAKZ1qu+xQD+IG50cyAYujva/5loSejPMGQY4xFsV/iyptZhX g2XnTmO37TQl+gfQPE0Vj3pats22acsneb0UbABP2Ah2rzWN/sEV4B5RFbVYUpNq G5dFQR1Xdkx3qMkoZotFvVzvclMyxguJZDPy4HHIm8FqkjQE93m0x6KJQTj7a/80 nM6u7lyyD/8obhfb7ms1tc7hO3TLFqOv92IdYqTjl7RHTetj+Aa5MECUaQDJqeUP PoOBLpUWjDrFefrXtlCXhSK0mlLJcezLPGQP6ZqgYTUwNcug1zS69gsHpCaT+L0= =GRG2 -END PGP SIGNATURE- ___ 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: buildworld failing in lib/libc/db/btree
On Thu Jul 21 11, Dimitry Andric wrote: On 2011-07-21 09:08, Alexander Best wrote: for some reason buildworld always fails in lib/libc/db/btree :( clang: /usr/bin/clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -march=core2 -I/usr/git-freebsd-head/lib/libc/include -I/usr/git-freebsd-head/lib/libc/../../include -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/git-freebsd-head/lib/libc/. /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:2: warning: implicit declaration of function '__PAST_END' is invalid in C99 [-Wimplicit-function-declaration] __PAST_END(h-linp, 1) = h-upper -= NRINTERNAL; ^ What have you set CC to (in e.g make.conf, src.conf, in the environment, or on the command line)? If you are including any path, e.g. CC=/usr/bin/clang, buildworld will not work. Remove the path and try again. THANKS! ...exactly that was the problem. :) after changing CC/CXX so it doesn't contain a full path, buildworld succeeded! cheers. alex ___ 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] Export per-thread resource usage via sysctl
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?
cheers.
alex
It also fixes a bug in that the code in calcru() to try to account for the
current thread's runtime wasn't correctly accounting charging that time to
the current thread.
Index: sys/kern/kern_proc.c
===
--- sys/kern/kern_proc.c (revision 224058)
+++ sys/kern/kern_proc.c (working copy)
@@ -848,6 +848,8 @@
kp-ki_tdaddr = td;
PROC_LOCK_ASSERT(p, MA_OWNED);
+ if (preferthread)
+ PROC_SLOCK(p);
thread_lock(td);
if (td-td_wmesg != NULL)
strlcpy(kp-ki_wmesg, td-td_wmesg, sizeof(kp-ki_wmesg));
@@ -899,6 +901,7 @@
kp-ki_pri.pri_user = td-td_user_pri;
if (preferthread) {
+ rufetchtd(td, kp-ki_rusage);
kp-ki_runtime = cputick2usec(td-td_rux.rux_runtime);
kp-ki_pctcpu = sched_pctcpu(td);
kp-ki_estcpu = td-td_estcpu;
@@ -911,6 +914,8 @@
kp-ki_siglist = td-td_siglist;
kp-ki_sigmask = td-td_sigmask;
thread_unlock(td);
+ if (preferthread)
+ PROC_SUNLOCK(p);
}
/*
Index: sys/kern/kern_resource.c
===
--- sys/kern/kern_resource.c (revision 224058)
+++ sys/kern/kern_resource.c (working copy)
@@ -813,7 +813,7 @@
calcru(struct proc *p, struct timeval *up, struct timeval *sp)
{
struct thread *td;
- uint64_t u;
+ uint64_t runtime, u;
PROC_LOCK_ASSERT(p, MA_OWNED);
PROC_SLOCK_ASSERT(p, MA_OWNED);
@@ -826,7 +826,9 @@
td = curthread;
if (td-td_proc == p) {
u = cpu_ticks();
- p-p_rux.rux_runtime += u - PCPU_GET(switchtime);
+ runtime = u - PCPU_GET(switchtime);
+ td-td_runtime += runtime;
+ td-td_incruntime += runtime;
PCPU_SET(switchtime, u);
}
/* Make sure the per-thread stats are current. */
@@ -838,6 +840,34 @@
calcru1(p, p-p_rux, up, sp);
}
+/* Collect resource usage for a single thread. */
+void
+rufetchtd(struct thread *td, struct rusage *ru)
+{
+ struct proc *p;
+ uint64_t runtime, u;
+
+ p = td-td_proc;
+ PROC_SLOCK_ASSERT(p, MA_OWNED);
+ THREAD_LOCK_ASSERT(td, MA_OWNED);
+ /*
+ * If we are getting stats for the current thread, then add in the
+ * stats that this thread has accumulated in its current time slice.
+ * We reset the thread and CPU state as if we had performed a context
+ * switch right here.
+ */
+ if (td == curthread) {
+ u = cpu_ticks();
+ runtime = u - PCPU_GET(switchtime);
+ td-td_runtime += runtime;
+ td-td_incruntime += runtime;
+ PCPU_SET(switchtime, u);
+ }
+ ruxagg(p, td);
+ *ru = td-td_ru;
+ calcru1(p, td-td_rux, ru-ru_utime, ru-ru_stime);
+}
+
static void
calcru1(struct proc *p, struct rusage_ext *ruxp, struct timeval *up,
struct timeval *sp)
@@ -955,12 +985,10 @@
case RUSAGE_THREAD:
PROC_SLOCK(p);
- ruxagg(p, td);
- PROC_SUNLOCK(p);
thread_lock(td);
- *rup = td-td_ru;
- calcru1(p, td-td_rux, rup-ru_utime, rup-ru_stime);
+ rufetchtd(td, rup);
thread_unlock(td);
+ PROC_SUNLOCK(p);
break;
default:
Index: sys/sys/resourcevar.h
===
--- sys/sys/resourcevar.h (revision 224058)
+++ sys/sys/resourcevar.h (working copy)
@@ -136,6 +136,7 @@
void rufetch(struct proc *p, struct rusage *ru);
void rufetchcalc(struct proc *p, struct rusage *ru, struct timeval *up,
struct timeval *sp);
+void rufetchtd(struct thread *td, struct rusage *ru);
void ruxagg(struct proc *p, struct thread *td);
int suswintr(void
Re: [PATCH] Export per-thread resource usage via sysctl
On Sat Jul 16 11, Pan Tsu wrote: 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. hmmm...not here. i did the following: 'top -mio -b -H -d2 99' and had a look at the second output, where if found these lines: [...] 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) [...] 2068 1001 383137 0 0 0 0 0.00% /usr/local/jdk1.6.0/bin/java -Xmx512m -jar JDownloader.jar 2068 1001 383137 0 0 0 0 0.00% /usr/local/jdk1.6.0/bin/java -Xmx512m -jar JDownloader.jar [...] the first output seems to behave similar: [...] 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon [...] cheers. alex ___ 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] Make top -P an interactive toggle
On Mon Jul 11 11, John Baldwin wrote: On Saturday, July 09, 2011 5:44:16 am Alexander Best wrote: On Sat Jul 9 11, Alexander Best wrote: On Fri Jul 8 11, Alexander Best wrote: On Fri Jul 8 11, John Baldwin wrote: This patch lets you use 'P' while top is running to toggle between per-CPU and global CPU stats. very cool. i always thought that being able to interactivly enable/disable per-cpu stats in top would be a useful feature. great to see this being implemented. oh...and of course i tested your patch. ;) works great without any issues. would it be possible to display a note when using 'P'? E.g. when pressing 'z' top informs the user with one of these messages: Displaying system idle process. or Not displaying system idle process. would be nice to have something similar when pressing the 'P' key. Maybe: Display per-cpu CPU usage statistics. and Not display per-cpu CPU usage statistics. Ok, I went with Displaying per-CPU statistics and Displaying global CPU statistics. cool! thanks. :) i've discovered a few other top-related issues and will be posting problem reports and patches throughout the next week. i also got a mail by bruce evans describing some more issues. since some of them are pretty techie, i might not be able to provide patches for each one of them, however i'll try to document them all. cheers. alex -- John Baldwin ___ 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] Make top -P an interactive toggle
On Fri Jul 8 11, Alexander Best wrote:
On Fri Jul 8 11, John Baldwin wrote:
This patch lets you use 'P' while top is running to toggle between per-CPU
and
global CPU stats.
very cool. i always thought that being able to interactivly enable/disable
per-cpu stats in top would be a useful feature. great to see this being
implemented.
oh...and of course i tested your patch. ;) works great without any issues.
top is nearing perfection. ;)
Index: contrib/top/top.c
===
--- contrib/top/top.c (revision 223873)
+++ contrib/top/top.c (working copy)
@@ -196,9 +196,9 @@
fd_set readfds;
#ifdef ORDER
-static char command_chars[] = \f qh?en#sdkriIutHmSCajzo;
+static char command_chars[] = \f qh?en#sdkriIutHmSCajzPo;
#else
-static char command_chars[] = \f qh?en#sdkriIutHmSCajz;
+static char command_chars[] = \f qh?en#sdkriIutHmSCajzP;
#endif
/* these defines enumerate the strchrs of the commands in command_chars
*/
#define CMD_redraw 0
@@ -225,8 +225,9 @@
#defineCMD_showargs20
#defineCMD_jidtog 21
#define CMD_kidletog 22
+#define CMD_pcputog23
#ifdef ORDER
-#define CMD_order 23
+#define CMD_order 24
#endif
/* set the buffer for stdout */
@@ -411,7 +412,7 @@
break;
case 'P':
- pcpu_stats = Yes;
+ pcpu_stats = !pcpu_stats;
break;
case 'z':
@@ -1088,6 +1089,12 @@
ps.kidle ? D : Not d);
putchar('\r');
break;
+ case CMD_pcputog:
+ pcpu_stats = !pcpu_stats;
+ toggle_pcpustats(statics);
+ max_topn = display_updatecpus(statics);
+ reset_display();
+ break;
default:
new_message(MT_standout, BAD CASE IN
SWITCH!);
putchar('\r');
Index: contrib/top/display.c
===
--- contrib/top/display.c (revision 223873)
+++ contrib/top/display.c (working copy)
@@ -151,16 +151,14 @@
return(smart_terminal ? lines : Largest);
}
-int display_init(statics)
+int display_updatecpus(statics)
struct statics *statics;
{
register int lines;
-register char **pp;
-register int *ip;
register int i;
-
+
/* call resize to do the dirty work */
lines = display_resize();
num_cpus = statics-ncpus;
@@ -170,6 +168,21 @@
for (i = num_cpus; i 9; i /= 10)
cpustates_column++;
+return(lines);
+}
+
+int display_init(statics)
+
+struct statics *statics;
+
+{
+register int lines;
+register char **pp;
+register int *ip;
+register int i;
+
+lines = display_updatecpus(statics);
+
/* only do the rest if we need to */
if (lines -1)
{
Index: contrib/top/top.X
===
--- contrib/top/top.X (revision 223873)
+++ contrib/top/top.X (working copy)
@@ -205,6 +205,7 @@
.BR \-H ,
.BR \-I ,
.BR \-j ,
+.BR \-P ,
.BR \-S ,
.BR \-t ,
.BR \-u ,
@@ -314,6 +315,9 @@
.IR jail (8)
ID.
.TP
+.B P
+Toggle the display of per-CPU statistics.
+.TP
.B t
Toggle the display of the
.I top
Index: usr.bin/top/machine.c
===
--- usr.bin/top/machine.c (revision 223873)
+++ usr.bin/top/machine.c (working copy)
@@ -239,19 +239,48 @@
static void getsysctl(const char *name, void *ptr, size_t len);
static int swapmode(int *retavail, int *retfree);
+void
+toggle_pcpustats(struct statics *statics)
+{
+
+ if (ncpus == 1)
+ return;
+
+ /* Adjust display based on ncpus */
+ if (pcpu_stats) {
+ y_mem += ncpus - 1; /* 3 */
+ y_swap += ncpus - 1;/* 4 */
+ y_idlecursor += ncpus - 1; /* 5 */
+ y_message += ncpus - 1; /* 5 */
+ y_header += ncpus - 1; /* 6 */
+ y_procs += ncpus - 1; /* 7 */
+ Header_lines += ncpus - 1; /* 7 */
+ statics-ncpus = ncpus;
+ } else {
+ y_mem = 3;
+ y_swap = 4;
+ y_idlecursor = 5;
+ y_message = 5;
+ y_header = 6;
+ y_procs = 7;
+ Header_lines = 7;
+ statics-ncpus = 1;
+ }
+}
+
int
machine_init(struct statics *statics, char do_unames)
{
- int pagesize;
- size_t modelen;
+ int i, j, empty, pagesize
Re: [PATCH] Make top -P an interactive toggle
On Sat Jul 9 11, Alexander Best wrote:
On Fri Jul 8 11, Alexander Best wrote:
On Fri Jul 8 11, John Baldwin wrote:
This patch lets you use 'P' while top is running to toggle between
per-CPU and
global CPU stats.
very cool. i always thought that being able to interactivly enable/disable
per-cpu stats in top would be a useful feature. great to see this being
implemented.
oh...and of course i tested your patch. ;) works great without any issues.
would it be possible to display a note when using 'P'? E.g. when pressing 'z'
top informs the user with one of these messages:
Displaying system idle process.
or
Not displaying system idle process.
would be nice to have something similar when pressing the 'P' key. Maybe:
Display per-cpu CPU usage statistics.
and
Not display per-cpu CPU usage statistics.
cheers.
alex
top is nearing perfection. ;)
Index: contrib/top/top.c
===
--- contrib/top/top.c (revision 223873)
+++ contrib/top/top.c (working copy)
@@ -196,9 +196,9 @@
fd_set readfds;
#ifdef ORDER
-static char command_chars[] = \f qh?en#sdkriIutHmSCajzo;
+static char command_chars[] = \f qh?en#sdkriIutHmSCajzPo;
#else
-static char command_chars[] = \f qh?en#sdkriIutHmSCajz;
+static char command_chars[] = \f qh?en#sdkriIutHmSCajzP;
#endif
/* these defines enumerate the strchrs of the commands in
command_chars */
#define CMD_redraw 0
@@ -225,8 +225,9 @@
#define CMD_showargs20
#define CMD_jidtog 21
#define CMD_kidletog 22
+#define CMD_pcputog 23
#ifdef ORDER
-#define CMD_order 23
+#define CMD_order 24
#endif
/* set the buffer for stdout */
@@ -411,7 +412,7 @@
break;
case 'P':
- pcpu_stats = Yes;
+ pcpu_stats = !pcpu_stats;
break;
case 'z':
@@ -1088,6 +1089,12 @@
ps.kidle ? D : Not d);
putchar('\r');
break;
+ case CMD_pcputog:
+ pcpu_stats = !pcpu_stats;
+ toggle_pcpustats(statics);
+ max_topn = display_updatecpus(statics);
+ reset_display();
+ break;
default:
new_message(MT_standout, BAD CASE IN
SWITCH!);
putchar('\r');
Index: contrib/top/display.c
===
--- contrib/top/display.c (revision 223873)
+++ contrib/top/display.c (working copy)
@@ -151,16 +151,14 @@
return(smart_terminal ? lines : Largest);
}
-int display_init(statics)
+int display_updatecpus(statics)
struct statics *statics;
{
register int lines;
-register char **pp;
-register int *ip;
register int i;
-
+
/* call resize to do the dirty work */
lines = display_resize();
num_cpus = statics-ncpus;
@@ -170,6 +168,21 @@
for (i = num_cpus; i 9; i /= 10)
cpustates_column++;
+return(lines);
+}
+
+int display_init(statics)
+
+struct statics *statics;
+
+{
+register int lines;
+register char **pp;
+register int *ip;
+register int i;
+
+lines = display_updatecpus(statics);
+
/* only do the rest if we need to */
if (lines -1)
{
Index: contrib/top/top.X
===
--- contrib/top/top.X (revision 223873)
+++ contrib/top/top.X (working copy)
@@ -205,6 +205,7 @@
.BR \-H ,
.BR \-I ,
.BR \-j ,
+.BR \-P ,
.BR \-S ,
.BR \-t ,
.BR \-u ,
@@ -314,6 +315,9 @@
.IR jail (8)
ID.
.TP
+.B P
+Toggle the display of per-CPU statistics.
+.TP
.B t
Toggle the display of the
.I top
Index: usr.bin/top/machine.c
===
--- usr.bin/top/machine.c (revision 223873)
+++ usr.bin/top/machine.c (working copy)
@@ -239,19 +239,48 @@
static void getsysctl(const char *name, void *ptr, size_t len);
static int swapmode(int *retavail, int *retfree);
+void
+toggle_pcpustats(struct statics *statics)
+{
+
+ if (ncpus == 1)
+ return;
+
+ /* Adjust display based on ncpus */
+ if (pcpu_stats) {
+ y_mem += ncpus - 1; /* 3 */
+ y_swap += ncpus - 1;/* 4 */
+ y_idlecursor += ncpus - 1; /* 5 */
+ y_message += ncpus - 1; /* 5 */
+ y_header += ncpus - 1; /* 6 */
+ y_procs += ncpus - 1; /* 7
Re: [PATCH] Make top -P an interactive toggle
On Fri Jul 8 11, John Baldwin wrote:
This patch lets you use 'P' while top is running to toggle between per-CPU and
global CPU stats.
very cool. i always thought that being able to interactivly enable/disable
per-cpu stats in top would be a useful feature. great to see this being
implemented.
top is nearing perfection. ;)
Index: contrib/top/top.c
===
--- contrib/top/top.c (revision 223873)
+++ contrib/top/top.c (working copy)
@@ -196,9 +196,9 @@
fd_set readfds;
#ifdef ORDER
-static char command_chars[] = \f qh?en#sdkriIutHmSCajzo;
+static char command_chars[] = \f qh?en#sdkriIutHmSCajzPo;
#else
-static char command_chars[] = \f qh?en#sdkriIutHmSCajz;
+static char command_chars[] = \f qh?en#sdkriIutHmSCajzP;
#endif
/* these defines enumerate the strchrs of the commands in command_chars */
#define CMD_redraw 0
@@ -225,8 +225,9 @@
#define CMD_showargs20
#define CMD_jidtog 21
#define CMD_kidletog 22
+#define CMD_pcputog 23
#ifdef ORDER
-#define CMD_order 23
+#define CMD_order 24
#endif
/* set the buffer for stdout */
@@ -411,7 +412,7 @@
break;
case 'P':
- pcpu_stats = Yes;
+ pcpu_stats = !pcpu_stats;
break;
case 'z':
@@ -1088,6 +1089,12 @@
ps.kidle ? D : Not d);
putchar('\r');
break;
+ case CMD_pcputog:
+ pcpu_stats = !pcpu_stats;
+ toggle_pcpustats(statics);
+ max_topn = display_updatecpus(statics);
+ reset_display();
+ break;
default:
new_message(MT_standout, BAD CASE IN
SWITCH!);
putchar('\r');
Index: contrib/top/display.c
===
--- contrib/top/display.c (revision 223873)
+++ contrib/top/display.c (working copy)
@@ -151,16 +151,14 @@
return(smart_terminal ? lines : Largest);
}
-int display_init(statics)
+int display_updatecpus(statics)
struct statics *statics;
{
register int lines;
-register char **pp;
-register int *ip;
register int i;
-
+
/* call resize to do the dirty work */
lines = display_resize();
num_cpus = statics-ncpus;
@@ -170,6 +168,21 @@
for (i = num_cpus; i 9; i /= 10)
cpustates_column++;
+return(lines);
+}
+
+int display_init(statics)
+
+struct statics *statics;
+
+{
+register int lines;
+register char **pp;
+register int *ip;
+register int i;
+
+lines = display_updatecpus(statics);
+
/* only do the rest if we need to */
if (lines -1)
{
Index: contrib/top/top.X
===
--- contrib/top/top.X (revision 223873)
+++ contrib/top/top.X (working copy)
@@ -205,6 +205,7 @@
.BR \-H ,
.BR \-I ,
.BR \-j ,
+.BR \-P ,
.BR \-S ,
.BR \-t ,
.BR \-u ,
@@ -314,6 +315,9 @@
.IR jail (8)
ID.
.TP
+.B P
+Toggle the display of per-CPU statistics.
+.TP
.B t
Toggle the display of the
.I top
Index: usr.bin/top/machine.c
===
--- usr.bin/top/machine.c (revision 223873)
+++ usr.bin/top/machine.c (working copy)
@@ -239,19 +239,48 @@
static void getsysctl(const char *name, void *ptr, size_t len);
static int swapmode(int *retavail, int *retfree);
+void
+toggle_pcpustats(struct statics *statics)
+{
+
+ if (ncpus == 1)
+ return;
+
+ /* Adjust display based on ncpus */
+ if (pcpu_stats) {
+ y_mem += ncpus - 1; /* 3 */
+ y_swap += ncpus - 1;/* 4 */
+ y_idlecursor += ncpus - 1; /* 5 */
+ y_message += ncpus - 1; /* 5 */
+ y_header += ncpus - 1; /* 6 */
+ y_procs += ncpus - 1; /* 7 */
+ Header_lines += ncpus - 1; /* 7 */
+ statics-ncpus = ncpus;
+ } else {
+ y_mem = 3;
+ y_swap = 4;
+ y_idlecursor = 5;
+ y_message = 5;
+ y_header = 6;
+ y_procs = 7;
+ Header_lines = 7;
+ statics-ncpus = 1;
+ }
+}
+
int
machine_init(struct statics *statics, char do_unames)
{
- int pagesize;
- size_t modelen;
+ int i, j, empty, pagesize;
+ size_t size;
struct passwd *pw;
- modelen = sizeof(smpmode);
- if ((sysctlbyname(machdep.smp_active, smpmode, modelen,
+ size = sizeof(smpmode);
+ if ((sysctlbyname(machdep.smp_active, smpmode,
displaying thread id in top -H
hi there, any reason why bin/139389 hasn't been committed, yet? i think seeing the thread id in top -H output is extremely useful! cheers. alex ___ 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: Heavy I/O blocks FreeBSD box for several seconds
On Wed Jul 6 11, arrowdodger wrote: 2011/7/6 O. Hartmann ohart...@zedat.fu-berlin.de When performing an update on the ports tree via portsnap fetch update or when checking out (or) large Subversion repositories or when copying large data files (~ 50 to 250 GB in size, results from numerical modelings) or when compiling world, FreeBD 9.0 and FreeBSD 8.2-STABLE tend to freeze for several seconds or drop overall performance dramatically for seconds. On boxes with only console- or terminal access (no GUI) a running 'vi' gets stuck for seconds while one of the processes producing heavy I/O is running, or the output of a 'cat' of a large file stops for several seconds. this might be a scheduling issue. iirc i/o intensive tasks have higher priority than cpu intensive tasks, because they are expected to only issue a i/o request and then free the processor, while cpu intensive tasks occupy the cpu a lot longer. so maybe a process whith cyclic i/o requests blocks processes which aren't doing i/o. maybe playing with ULE's options can improve the situation. since you're running GENERIC, preemption *should* be enabled. however you should double check. i once tried running ULE without preemption and experienced exactly the same situation you described in your mail. for ULE preemption is pretty much mandatory. for the old 4bsd scheduler, running without preemtion doesn't really make that much of a difference, compared to running with preemption. you might also want to try enabling options IPI_PREEMPTION. no idea, if this improves your situation, though. cheers. alex Using X11, this phenomenon gets even worse and the 'freezing' tends to persist sometimes for more than 10 or 15 seconds. I've also had (and still having) this problem on FreeBSD 7.2-RELEASE and 8-STABLE with both UFS and ZFS. Though, i've been running FreeBSD not on powerful servers, but on laptops (2-core CPU's, 2 GB of RAM). But still, KDE4 on Linux performs much better during high disk IO. ___ 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: Heavy I/O blocks FreeBSD box for several seconds
On Wed Jul 6 11, Andriy Gapon wrote: on 06/07/2011 16:33 Alexander Best said the following: you might also want to try enabling options IPI_PREEMPTION. no idea, if this improves your situation, though. Just in case, this option has effect for 4BSD scheduler only. thanks. i did not know that. maybe we could add a small note to NOTES or even mention in sched_ule(4) and sched_4bsd(4), which kernel options affect the according scheduler. sched_ule(4) e.g. doesn't mention kern.sched.preemption, so one can assume that defining PREEMPTION in the kernel or not doesn't make a difference. however it *does* make a huge difference. i believe sched_ule(4) in general needs a lot more details about the various sysctl vars available and their semantics. cheers. alex -- Andriy Gapon ___ 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: displaying thread id in top -H
On Wed Jul 6 11, Sergey Kandaurov wrote: On 6 July 2011 13:19, Alexander Best arun...@freebsd.org wrote: hi there, any reason why bin/139389 hasn't been committed, yet? i think seeing the thread id in top -H output is extremely useful! I think the main reason is that tid takes a log of space (6 digits + 2 spaces), and top already suffers from a lack of free columns. ah i see. thanks for the info. i think i'll suspend or even close that PR then. cheers. alex -- wbr, pluknet ___ 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
