[head tinderbox] failure on i386/pc98
TB --- 2012-04-02 06:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-02 06:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-02 06:20:00 - cleaning the object tree TB --- 2012-04-02 06:23:19 - cvsupping the source tree TB --- 2012-04-02 06:23:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-02 06:25:12 - building world TB --- 2012-04-02 06:25:12 - CROSS_BUILD_TESTING=YES TB --- 2012-04-02 06:25:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-02 06:25:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-02 06:25:12 - SRCCONF=/dev/null TB --- 2012-04-02 06:25:12 - TARGET=pc98 TB --- 2012-04-02 06:25:12 - TARGET_ARCH=i386 TB --- 2012-04-02 06:25:12 - TZ=UTC TB --- 2012-04-02 06:25:12 - __MAKE_CONF=/dev/null TB --- 2012-04-02 06:25:12 - cd /src TB --- 2012-04-02 06:25:12 - /usr/bin/make -B buildworld World build started on Mon Apr 2 06:25:13 UTC 2012 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 [...] /obj/pc98.i386/src/tmp/usr/include/netinet/ip_compat.h:1543: warning: previous declaration of 'bcopywrap' was here In file included from ioctl.c:123: /obj/pc98.i386/src/tmp/usr/include/sys/timepps.h: In function 'time_pps_fetch': /obj/pc98.i386/src/tmp/usr/include/sys/timepps.h:200: warning: declaration of 'timeout' shadows a global declaration /obj/pc98.i386/src/tmp/usr/include/sys/systm.h:316: warning: shadowed declaration is here /obj/pc98.i386/src/tmp/usr/include/sys/timepps.h: In function 'time_pps_fetch_ffc': /obj/pc98.i386/src/tmp/usr/include/sys/timepps.h:218: warning: declaration of 'timeout' shadows a global declaration /obj/pc98.i386/src/tmp/usr/include/sys/systm.h:316: warning: shadowed declaration is here *** Error code 1 Stop in /src/usr.bin/kdump. *** 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 --- 2012-04-02 08:39:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-02 08:39:16 - ERROR: failed to build world TB --- 2012-04-02 08:39:16 - 5758.82 user 807.01 system 8356.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.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
[head tinderbox] failure on mips/mips
TB --- 2012-04-02 08:39:42 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-02 08:39:42 - starting HEAD tinderbox run for mips/mips TB --- 2012-04-02 08:39:42 - cleaning the object tree TB --- 2012-04-02 08:41:17 - cvsupping the source tree TB --- 2012-04-02 08:41:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-04-02 08:42:55 - building world TB --- 2012-04-02 08:42:55 - CROSS_BUILD_TESTING=YES TB --- 2012-04-02 08:42:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-02 08:42:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-02 08:42:55 - SRCCONF=/dev/null TB --- 2012-04-02 08:42:55 - TARGET=mips TB --- 2012-04-02 08:42:55 - TARGET_ARCH=mips TB --- 2012-04-02 08:42:55 - TZ=UTC TB --- 2012-04-02 08:42:55 - __MAKE_CONF=/dev/null TB --- 2012-04-02 08:42:55 - cd /src TB --- 2012-04-02 08:42:55 - /usr/bin/make -B buildworld World build started on Mon Apr 2 08:42:56 UTC 2012 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 -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 kfd.8.gz === kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mips/src/tmp/usr/bin/ld: /obj/mips.mips/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mips/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-02 09:32:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-02 09:32:16 - ERROR: failed to build world TB --- 2012-04-02 09:32:16 - 2006.20 user 451.55 system 3153.42 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.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
[head tinderbox] failure on ia64/ia64
TB --- 2012-04-02 08:39:17 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-02 08:39:17 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-02 08:39:17 - cleaning the object tree TB --- 2012-04-02 08:41:27 - cvsupping the source tree TB --- 2012-04-02 08:41:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-02 08:42:56 - building world TB --- 2012-04-02 08:42:56 - CROSS_BUILD_TESTING=YES TB --- 2012-04-02 08:42:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-02 08:42:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-02 08:42:56 - SRCCONF=/dev/null TB --- 2012-04-02 08:42:56 - TARGET=ia64 TB --- 2012-04-02 08:42:56 - TARGET_ARCH=ia64 TB --- 2012-04-02 08:42:56 - TZ=UTC TB --- 2012-04-02 08:42:56 - __MAKE_CONF=/dev/null TB --- 2012-04-02 08:42:56 - cd /src TB --- 2012-04-02 08:42:56 - /usr/bin/make -B buildworld World build started on Mon Apr 2 08:42:57 UTC 2012 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 [...] /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h: In function 'bus_space_write_1': /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h:250: warning: implicit declaration of function 'ia64_st1' /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h: In function 'bus_space_write_2': /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h:261: warning: implicit declaration of function 'ia64_st2' /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h: In function 'bus_space_write_4': /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h:272: warning: implicit declaration of function 'ia64_st4' /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h: In function 'bus_space_write_8': /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h:283: warning: implicit declaration of function 'ia64_st8' *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-02 10:09:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-02 10:09:09 - ERROR: failed to build world TB --- 2012-04-02 10:09:09 - 3964.23 user 618.88 system 5391.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.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: Awkward booting issue
Mark wrote: Hi, I have been trying to get FreeBSD 9 amd64 to boot on my 1U server but am unsuccesful and am out of ideas. I tried to boot the iso from CD-ROM, I tried multiple USB memory sticks and I even tried to boot from hard discs, I'll explain this further below. Oddly enough every boot attempt fails. Right after the hard discs are recognised the system just sits there, silent, with no errors. The last Have you tried waiting a long long long time? I have a problem where the boot hangs but it does actually eventually boot. The most infomation I managed to get out of the system before I had to give up and revert to the previous config was that although Hz was configured as 1000, it was only ticking 19 times a second, so machine time was running about 50 slower than wallclock time. You might or not be experiencing the same issue. Ian -- Ian Freislich ___ 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: Using TMPFS for /tmp and /var/run?
On (29/03/2012 21:49), O. Hartmann wrote:
Am 03/29/12 18:14, schrieb David Wolfskill:
On Thu, Mar 29, 2012 at 04:18:06PM +0200, O. Hartmann wrote:
I was wondering if there are some objections using TMPFS for /tmp and
/var/run.
...
My question is whether there are objections using TMPFS for bot /tmp/
and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64?
I have no experience using tmpfs for /var/run, but I have been using it
for /tmp for some time (mostly in i386, though).
While I use it quite successfully on machines with a small number of
folks actively busy -- e.g., my desktop; my laptop; my home machines), I
encountered some issues when I tried to do so on machines that were
intended for significantly heavier use. Specifically:
* Compared to an md-resident /tmp, a tmpfs-resident /tmp has much less
flexibility for specifying the size. Per mdconfig(8), the former
uses:
-s size
Size of the memory disk. Size is the number of 512 byte
sectors
unless suffixed with a b, k, m, g, or t which denotes byte,
kilo-
byte, megabyte, gigabyte and terabyte respectively. Options -a
and -t swap are implied if not specified.
while the latter uses:
sizeSpecifies the total file system size in bytes. If zero (the
default) or a value larger than SIZE_MAX - PAGE_SIZE is given,
the available amount of memory (including main memory and swap
space) will be used.
In this configuration, I would have preferred to have specified
about 10GB for /tmp. I wouldn't mind if it spilled to swap space,
but I certaianly didn't want it using 10GB of RAM -- especially since
the machines only had 6GB RAM.
Nor did I especially want *all* of the swap space used for /tmp. I
would have allocated (say) 20GB for swap. I wouldn't mind if half of
that were used for /tmp -- but a reason I allocate so much swap is
that I've seen what happens when a machine runs out of swap, and it
wasn't pretty.
In any case, effective maximum usable size for tmpfs involves SIZE_MAX
(~4G) PAGE_SIZE (4K, in my case).
size_t is 64-bit on 64-bit archs.
* Even when I went ahead and created a tmpfs for /tmp, I'd get ENOSPC
whenever I tried to allocate anything on it -- until I dropped the
size specification to 2G (2**32). Well, 2GB for /tmp just wasn't at
all likely to be useful for my purposes in this case.
Are you using ZFS alongside tmpfs? It should be fixed in 9-STABLE.
So I continue to use tmpfs for /tmp for machines with fewer folks
logging in, but I'm a bit less enthusiastic about its use unless the
workload and other requirements are fairly carefully considered
beforehand.
Peace,
david
It seems there is only one switch which determines the size of the tmpfs
in question (size) and there is no convenient way to say what amount of
RAM is being used before using the swap space. I'd like to have at least
a knob determining the limit of RAM being used.
There is no way to force tmpfs to use given amount of RAM only. It's VM
subsystem that decides what pages to swap. Although some tweaking for VM
to prefer swapping tmpfs pages prior to process pages would be nice.
You could try the patch attached. It adds support for size option suffixes
(like 1g) and introduces swap limit (part of the older patch, not sure
if it's any use).
Patch is against 10-CURRENT.
Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d
Thanks,
Gleb.
On the other hand - my view of those things is really naiv. I think
having tmpfs isn't even a benefit in terms of security, it should also
offer a speedy access to files kept in memory, doesn't it?
Linux is using TMPFS filesystems a lot for these purposes. How do they
overcome restrictions of the size or not flloding RAM and/or swap?
Regards,
Oliver
diff --git a/sys/fs/tmpfs/tmpfs.h b/sys/fs/tmpfs/tmpfs.h
index efa7c6d..3fc72ab 100644
--- a/sys/fs/tmpfs/tmpfs.h
+++ b/sys/fs/tmpfs/tmpfs.h
@@ -337,11 +337,10 @@ struct tmpfs_mount {
* system, set during mount time. This variable must never be
* used directly as it may be bigger than the current amount of
* free memory; in the extreme case, it will hold the SIZE_MAX
-* value. Instead, use the TMPFS_PAGES_MAX macro. */
+* value. */
size_t tm_pages_max;
- /* Number of pages in use by the file system. Cannot be bigger
-* than the value returned by TMPFS_PAGES_MAX in any case. */
+ /* Number of pages in use by the file system. */
size_t tm_pages_used;
/* Pointer to the node representing the root directory of this
@@ -486,58 +485,32 @@ int tmpfs_truncate(struct vnode *, off_t);
* Memory management stuff.
*/
-/* Amount of memory pages to reserve for
Re: x220 notes
Well I can't do the brightness switching. acpi_call port is installed, but: # kldload acpi_call kldload: can't load acpi_call: No such file or directory # acpi_call -p '\VBRC' -i 14 ioctl: Device not configured At least closing the lid turns off the monitor (not going to sleep), which is OK to conserve energy when not using. I would like to be able to change brightness, however. And have dimming. A minor problem, with the KMS Intel patch, when I log out of X (startx or xfce4), screen goes black. I don't know if this is acpi related. I typed reboot, and nothing happened. Using all.13.7-stable-9.patch with 9.0-STABLE. Cheers. -- Lyubomir Grigorov (bgalakazam) ___ 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: Using TMPFS for /tmp and /var/run?
I commonly use mfs for /var and /tmp. Sometimes even symlinking /var/tmp - /tmp to save ram. Mostly because I want nothing leftover in them on boot, and it's fast. rc/mtree/etc takes care of populating them. /, /boot, /usr and /usr/local are read-only. [nssswitch host.conf still needs fixed to deal with that] User and daemon writeables are on other mountpoints. Thus I don't have any persistent needs in mfs. No swap either. And cron is wiped out too. No real problems. There used to be some msgs emitted about rc populating it or rc being misordered using it. Those seem fixed. mfs is a lot more stable than it used to be. In fact, the crashes were what held me back till recently. Seems now I can hammer on it with dd, fsx and iozone and it won't die. Performance is fine whether under disk UFS+soft_updates or mfs. The options below are fine for creating either. I don't care about defaults... so long as both disk and ram options exist, I'm happy. All depends on how you use it. I like nice clean separation. Some (strange) people put everything in /. Oh well. I'd rather see the legacy /sys and /compat symlinks removed. rc_debug=YES rc_info=YES syslogd_flags=-sC root_rw_mount=NO tmpmfs_flags=-SM tmpsize=64m varmfs_flags=-SM varsize=128m ___ 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: Using TMPFS for /tmp and /var/run?
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote: ... In any case, effective maximum usable size for tmpfs involves SIZE_MAX (~4G) PAGE_SIZE (4K, in my case). size_t is 64-bit on 64-bit archs. OK. Still, the requirement that the size specification be in bytes is awkward (in my experience) -- and I was using i386. * Even when I went ahead and created a tmpfs for /tmp, I'd get ENOSPC whenever I tried to allocate anything on it -- until I dropped the size specification to 2G (2**32). Well, 2GB for /tmp just wasn't at all likely to be useful for my purposes in this case. Are you using ZFS alongside tmpfs? It should be fixed in 9-STABLE. I have not tried ZFS yet. I don't expect to do so unless I switch to amd64. ... It seems there is only one switch which determines the size of the tmpfs in question (size) and there is no convenient way to say what amount of RAM is being used before using the swap space. I'd like to have at least a knob determining the limit of RAM being used. There is no way to force tmpfs to use given amount of RAM only. It's VM subsystem that decides what pages to swap. Although some tweaking for VM to prefer swapping tmpfs pages prior to process pages would be nice. You could try the patch attached. It adds support for size option suffixes (like 1g) and introduces swap limit (part of the older patch, not sure if it's any use). Patch is against 10-CURRENT. Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d ... I'll plan to try this on a currrently-underutilized slice on my laptop, then -- thanks! :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp4RE09VWuHd.pgp Description: PGP signature
FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
Hello out there. My FreeBSD 10 box is at revision r233779. I updated the sources this morning and made a buildworld successfully. After a reboot of the box, I witness several bad issues. Firefox, for instance, is droppimng a core now when starting. Using portmaster for updates produces a lot of Segmentation faults on the screen. Othe minor clients which were working prior to the update today (last makeworl on Friday last week) aren't any more and dropping cores. Does anyone also realize this on FreeBSD 10 boxes? I use CLANG as the base compiler and also for the ports (for those which are compiling with CLANG). Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: Using TMPFS for /tmp and /var/run?
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote: ... You could try the patch attached. It adds support for size option suffixes (like 1g) and introduces swap limit (part of the older patch, not sure if it's any use). Patch is against 10-CURRENT. Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d OK; here's a summary of what I found so far, now running: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 233772M: Mon Apr 2 05:42:48 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 * First, the patch applied cleanly (via patch -p1). * Resulting sources build with no issues. * Prior specification I had in /etc/fstab: tmpfs/tmptmpfsrw,size=2147483648 00 worked same as before the patch; df -h /tmp reported a size of 2.0G. * Changing the above to read: tmpfs/tmptmpfsrw,size=2g 00 also provided the same result, so the unit-specification code looks as if it's working as expected. * I have 20G specified for swap, and 4G RAM (and, as above, I'm running i386). Changing the above tmpfs line in /etc/fstab to tmpfs/tmptmpfsrw,size=8g 00 (still) yields: g1-227(10.0-C)[3] df -h /tmp FilesystemSizeUsed Avail Capacity Mounted on tmpfs 23G 12k 23G 0%/tmp g1-227(10.0-C)[4] (Yes, I'm using a whopping total of 12kB while running X. I know of *very* few folks who use the window manager I prefer. :-}) I'll try exercising it a bit during the day at work report anything noteworthy. But so far, I see no evidence of regression, and there is some measure of usability improvement (IMO). So it's looking encouraging. :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpCxjDuDVwUA.pgp Description: PGP signature
Re: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
02.04.2012 16:32, O. Hartmann пишет: Hello out there. My FreeBSD 10 box is at revision r233779. I updated the sources this morning and made a buildworld successfully. After a reboot of the box, I witness several bad issues. Firefox, for instance, is droppimng a core now when starting. Using portmaster for updates produces a lot of Segmentation faults on the screen. Othe minor clients which were working prior to the update today (last makeworl on Friday last week) aren't any more and dropping cores. Does anyone also realize this on FreeBSD 10 boxes? I use CLANG as the base compiler and also for the ports (for those which are compiling with CLANG). Regards, Oliver confirm, for amd64 using gcc ___ 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: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
On Mon, 02 Apr 2012 14:32:51 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Hello out there. My FreeBSD 10 box is at revision r233779. I updated the sources this morning and made a buildworld successfully. After a reboot of the box, I witness several bad issues. Firefox, for instance, is droppimng a core now when starting. Using portmaster for updates produces a lot of Segmentation faults on the screen. Othe minor clients which were working prior to the update today (last makeworl on Friday last week) aren't any more and dropping cores. Does anyone also realize this on FreeBSD 10 boxes? I use CLANG as the base compiler and also for the ports (for those which are compiling with CLANG). Regards, Oliver Since you did not provide any details, I'd have to guess and I am guessing this is an interaction between rtld and new libstdc++ that is a likely cause for the crashes. Please try with revision r233778. -- Alexander Kabaev signature.asc Description: PGP signature
Re: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
On Mon, 2 Apr 2012 10:06:38 -0400 Alexander Kabaev kab...@gmail.com wrote: On Mon, 02 Apr 2012 14:32:51 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Hello out there. My FreeBSD 10 box is at revision r233779. I updated the sources this morning and made a buildworld successfully. After a reboot of the box, I witness several bad issues. Firefox, for instance, is droppimng a core now when starting. Using portmaster for updates produces a lot of Segmentation faults on the screen. Othe minor clients which were working prior to the update today (last makeworl on Friday last week) aren't any more and dropping cores. Does anyone also realize this on FreeBSD 10 boxes? I use CLANG as the base compiler and also for the ports (for those which are compiling with CLANG). Regards, Oliver I guess I should correct myself, you already should have the fix in. Please collect some backtraces. -- Alexander Kabaev signature.asc Description: PGP signature
Re: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
In message 4f79abf1.70...@lissyara.su, Alex Keda writes: 02.04.2012 16:32, O. Hartmann пиÑеÑ: Firefox, for instance, is droppimng a core now when starting. I tried r233749M and saw the same thing. This Warning looks non-ignorable to me, but I havn't investigated: === gnu/lib/libssp (all) /freebsd/head/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c: In function 'fail': /freebsd/head/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:109: warning: implicit declaration of function 'alloca' /freebsd/head/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:109: warning: incompatible implicit declaration of built-in function 'alloca' -- 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: Using TMPFS for /tmp and /var/run?
jb jb.1234abcd at gmail.com writes: ... Chuck Burns brea...@gmail.com 1:01 AM (16 hours ago) My experiences with using tmpfs as /tmp -- It works fine. until it doesn't. I've had mountpoints run out of space, checked df and the mountpoint had been reduced to something like 2 MiB TOTAL, with nothing free.. on a machine with 8GiB RAM.. however, rebooting restores the mount to around 2GiB.. but then after some heavy usage, the mountpoint once again starts shrinking in size. I've noticed this behavior in multiple versions of FreeBSD, and switched to using md instead, with no more issues. I'm not willing to use tmpfs until it's proven to be more stable than it was when I was using it. --- Chuck, plz check your posting to the list (I received it, which I reposted here). jb ___ 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: Using TMPFS for /tmp and /var/run?
On 2 Apr 2012 16:47, jb jb.1234a...@gmail.com wrote: jb jb.1234abcd at gmail.com writes: ... Chuck Burns brea...@gmail.com 1:01 AM (16 hours ago) My experiences with using tmpfs as /tmp -- It works fine. until it doesn't. I've had mountpoints run out of space, checked df and the mountpoint had been reduced to something like 2 MiB TOTAL, with nothing free.. on a machine with 8GiB RAM.. however, rebooting restores the mount to around 2GiB.. but then after some heavy usage, the mountpoint once again starts shrinking in size. I've noticed this behavior in multiple versions of FreeBSD, and switched to using md instead, with no more issues. I'm not willing to use tmpfs until it's proven to be more stable than it was when I was using it. --- Chuck, plz check your posting to the list (I received it, which I reposted here). jb This is a known issue with ZFS. Is that your case? 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
Potential deadlock on mbuf
Dear, I have currently having troubles with a basic socket stress. The socket are setup to use non-blocking I/O. During this stress-test, the kernel is running mbuf exhaustion, the goal is to see system limits. If the program make a write on a socket during this mbuf exhaustion, it become blocked in write system call. The status of the process is zonelimit and whole network I/O fall in timeout. I have found the root cause of the block : http://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?view=markup#l1279 So, the question is : Why m_uiotombuf is called with a blocking parameter (M_WAITOK) even if is for a non-blocking socket ? Then, if M_NOWAIT is used, maybe it will be usefull to have an 'ENOMEM' error. Regards -- Alexandre Martins ___ 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
[head tinderbox] failure on i386/pc98
TB --- 2012-04-02 14:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-02 14:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-02 14:10:00 - cleaning the object tree TB --- 2012-04-02 14:13:49 - cvsupping the source tree TB --- 2012-04-02 14:13:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-02 14:14:35 - building world TB --- 2012-04-02 14:14:35 - CROSS_BUILD_TESTING=YES TB --- 2012-04-02 14:14:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-02 14:14:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-02 14:14:35 - SRCCONF=/dev/null TB --- 2012-04-02 14:14:35 - TARGET=pc98 TB --- 2012-04-02 14:14:35 - TARGET_ARCH=i386 TB --- 2012-04-02 14:14:35 - TZ=UTC TB --- 2012-04-02 14:14:35 - __MAKE_CONF=/dev/null TB --- 2012-04-02 14:14:35 - cd /src TB --- 2012-04-02 14:14:35 - /usr/bin/make -B buildworld World build started on Mon Apr 2 14:14:36 UTC 2012 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 [...] /obj/pc98.i386/src/tmp/usr/include/netinet/ip_compat.h:1543: warning: previous declaration of 'bcopywrap' was here In file included from ioctl.c:123: /obj/pc98.i386/src/tmp/usr/include/sys/timepps.h: In function 'time_pps_fetch': /obj/pc98.i386/src/tmp/usr/include/sys/timepps.h:200: warning: declaration of 'timeout' shadows a global declaration /obj/pc98.i386/src/tmp/usr/include/sys/systm.h:316: warning: shadowed declaration is here /obj/pc98.i386/src/tmp/usr/include/sys/timepps.h: In function 'time_pps_fetch_ffc': /obj/pc98.i386/src/tmp/usr/include/sys/timepps.h:218: warning: declaration of 'timeout' shadows a global declaration /obj/pc98.i386/src/tmp/usr/include/sys/systm.h:316: warning: shadowed declaration is here *** Error code 1 Stop in /src/usr.bin/kdump. *** 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 --- 2012-04-02 16:25:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-02 16:25:58 - ERROR: failed to build world TB --- 2012-04-02 16:25:58 - 5976.96 user 825.15 system 8158.08 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.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: Build error in bin/sh/jobs.c if DEBUG=2
On Sun, Apr 01, 2012 at 04:14:24PM +0200, Kristof Provost wrote: While chasing down an odd issue with alignment faults I activated debugging in bin/sh. bin/sh/Makefile has a commented out line (# DEBUG_FLAGS+= -g -DDEBUG=2 -fno-inline) to do this so that's what I did. This fails to compile in bin/sh/jobs.c in vforkexecshell(). The debug TRACE() tries to print variables which don't exist. The patch below fixes the compilation problem, but I'm unsure if it's printing the relevant information. Thanks, I committed a fix. I fairly arbitrarily chose some information to print, since I do not use -DDEBUG=2 myself. -- Jilles Tjoelker ___ 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
[head tinderbox] failure on mips/mips
TB --- 2012-04-02 16:26:56 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-02 16:26:56 - starting HEAD tinderbox run for mips/mips TB --- 2012-04-02 16:26:56 - cleaning the object tree TB --- 2012-04-02 16:29:16 - cvsupping the source tree TB --- 2012-04-02 16:29:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-04-02 16:30:34 - building world TB --- 2012-04-02 16:30:34 - CROSS_BUILD_TESTING=YES TB --- 2012-04-02 16:30:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-02 16:30:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-02 16:30:34 - SRCCONF=/dev/null TB --- 2012-04-02 16:30:34 - TARGET=mips TB --- 2012-04-02 16:30:34 - TARGET_ARCH=mips TB --- 2012-04-02 16:30:34 - TZ=UTC TB --- 2012-04-02 16:30:34 - __MAKE_CONF=/dev/null TB --- 2012-04-02 16:30:34 - cd /src TB --- 2012-04-02 16:30:34 - /usr/bin/make -B buildworld World build started on Mon Apr 2 16:30:35 UTC 2012 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 -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 kfd.8.gz === kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mips/src/tmp/usr/bin/ld: /obj/mips.mips/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mips/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-02 17:21:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-02 17:21:12 - ERROR: failed to build world TB --- 2012-04-02 17:21:12 - 2098.14 user 467.49 system 3255.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.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
[head tinderbox] failure on ia64/ia64
TB --- 2012-04-02 16:25:59 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-02 16:25:59 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-02 16:25:59 - cleaning the object tree TB --- 2012-04-02 16:27:40 - cvsupping the source tree TB --- 2012-04-02 16:27:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-02 16:28:47 - building world TB --- 2012-04-02 16:28:47 - CROSS_BUILD_TESTING=YES TB --- 2012-04-02 16:28:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-02 16:28:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-02 16:28:47 - SRCCONF=/dev/null TB --- 2012-04-02 16:28:47 - TARGET=ia64 TB --- 2012-04-02 16:28:47 - TARGET_ARCH=ia64 TB --- 2012-04-02 16:28:47 - TZ=UTC TB --- 2012-04-02 16:28:47 - __MAKE_CONF=/dev/null TB --- 2012-04-02 16:28:47 - cd /src TB --- 2012-04-02 16:28:47 - /usr/bin/make -B buildworld World build started on Mon Apr 2 16:28:48 UTC 2012 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 [...] /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h: In function 'bus_space_write_1': /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h:250: warning: implicit declaration of function 'ia64_st1' /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h: In function 'bus_space_write_2': /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h:261: warning: implicit declaration of function 'ia64_st2' /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h: In function 'bus_space_write_4': /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h:272: warning: implicit declaration of function 'ia64_st4' /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h: In function 'bus_space_write_8': /obj/ia64.ia64/src/tmp/usr/include/machine/bus.h:283: warning: implicit declaration of function 'ia64_st8' *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-02 17:58:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-02 17:58:20 - ERROR: failed to build world TB --- 2012-04-02 17:58:20 - 4142.78 user 639.62 system 5541.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.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: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
Am 04/02/12 16:06, schrieb Alexander Kabaev: On Mon, 02 Apr 2012 14:32:51 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Hello out there. My FreeBSD 10 box is at revision r233779. I updated the sources this morning and made a buildworld successfully. After a reboot of the box, I witness several bad issues. Firefox, for instance, is droppimng a core now when starting. Using portmaster for updates produces a lot of Segmentation faults on the screen. Othe minor clients which were working prior to the update today (last makeworl on Friday last week) aren't any more and dropping cores. Does anyone also realize this on FreeBSD 10 boxes? I use CLANG as the base compiler and also for the ports (for those which are compiling with CLANG). Regards, Oliver Since you did not provide any details, I'd have to guess and I am guessing this is an interaction between rtld and new libstdc++ that is a likely cause for the crashes. Please try with revision r233778. Sorry for the late response. Indeed, I use the tag WITH_LIBCPLUSPLUS= YES in /etc/src.cnf. After an upgrade of the sources shortly after I posted the mail in the list, I recompiled the newly sources and reinstalled the system again and all problems I reported before were gone. Sorry for the noise. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: Using TMPFS for /tmp and /var/run?
On (02/04/2012 06:26), David Wolfskill wrote:
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote:
...
You could try the patch attached. It adds support for size option suffixes
(like 1g) and introduces swap limit (part of the older patch, not sure
if it's any use).
Patch is against 10-CURRENT.
Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d
OK; here's a summary of what I found so far, now running:
FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 233772M:
Mon Apr 2 05:42:48 PDT 2012
r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
* First, the patch applied cleanly (via patch -p1).
* Resulting sources build with no issues.
* Prior specification I had in /etc/fstab:
tmpfs/tmptmpfsrw,size=214748364800
worked same as before the patch; df -h /tmp reported a size of 2.0G.
* Changing the above to read:
tmpfs/tmptmpfsrw,size=2g00
also provided the same result, so the unit-specification code looks
as if it's working as expected.
* I have 20G specified for swap, and 4G RAM (and, as above, I'm running
i386). Changing the above tmpfs line in /etc/fstab to
tmpfs/tmptmpfsrw,size=8g00
(still) yields:
g1-227(10.0-C)[3] df -h /tmp
FilesystemSizeUsed Avail Capacity Mounted on
tmpfs 23G 12k 23G 0%/tmp
g1-227(10.0-C)[4]
tmpfs-32bit-size_max.patch.txt should fix the problem. I don't have i386
installations to test it myself.
Do you run PAE kernel? Could you try filling up /tmp at least to 10g.
(Yes, I'm using a whopping total of 12kB while running X. I know of
*very* few folks who use the window manager I prefer. :-})
I'll try exercising it a bit during the day at work report anything
noteworthy. But so far, I see no evidence of regression, and there is
some measure of usability improvement (IMO). So it's looking
encouraging. :-)
Peace,
david
--
David H. Wolfskillda...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
commit 44f68235e23ab4bababeafe07d31e07feabb84ba
Author: Gleb Kurtsou gleb.kurt...@gmail.com
Date: Tue Apr 3 00:02:33 2012 +0300
tmpfs: Support file system sizes up to 4GB*PAGE_SIZE on 32 bit archs
diff --git a/sys/fs/tmpfs/tmpfs_vfsops.c b/sys/fs/tmpfs/tmpfs_vfsops.c
index 29f2ca4..6b3ecc0 100644
--- a/sys/fs/tmpfs/tmpfs_vfsops.c
+++ b/sys/fs/tmpfs/tmpfs_vfsops.c
@@ -233,17 +233,13 @@ tmpfs_mount(struct mount *mp)
* allowed to use, based on the maximum size the user passed in
* the mount structure. A value of zero is treated as if the
* maximum available space was requested. */
- if (size_max PAGE_SIZE || size_max SIZE_MAX - PAGE_SIZE)
+ if (size_max PAGE_SIZE || size_max UINT64_MAX - PAGE_SIZE ||
+ (SIZE_MAX UINT64_MAX size_max / PAGE_SIZE = SIZE_MAX))
pages = SIZE_MAX;
else
pages = howmany(size_max, PAGE_SIZE);
MPASS(pages 0);
- if (pages SIZE_MAX / PAGE_SIZE)
- size_max = pages * PAGE_SIZE;
- else
- size_max = SIZE_MAX;
-
if (nodes_max = 3) {
if (pages INT_MAX / nodes_per_page)
nodes_max = pages * nodes_per_page;
___
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: Using TMPFS for /tmp and /var/run?
On 4/2/2012 10:52 AM, Chris Rees wrote: This is a known issue with ZFS. Is that your case? Chris Yes. Interesting that it happens only with ZFS. and jb, thanks, I could've sworn I'd hit Reply to list - thanks for forwarding it for me. 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
ixgbe-2.4.4 compile error
I used the 9.0-RELEASE memstick to install, did a cvsup to STABLE... When I downloaded Intel's (Jack's) ixgbe driver, I got an error: Warning: Object directory not changed from original /usr/local/src/ixgbe-2.4.4/src @ - /usr/src/sys machine - /usr/src/sys/amd64/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h : opt_bdg.h cc -O2 -pipe -DSMP -DIXGBE_FDIR -DINET -DINET6 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c ixgbe.c In file included from ixgbe_type.h:38, from ixgbe_api.h:38, from ixgbe.h:96, from ixgbe.c:40: ixgbe_osdep.h:104: error: conflicting types for 'bool' @/sys/types.h:271: error: previous declaration of 'bool' was here *** Error code 1 Stop in /usr/local/src/ixgbe-2.4.4/src. This patch fixed the 'conflict'. diff -u @/sys/types.h.orig @/sys/types.h --- @/sys/types.h.orig2012-04-02 14:18:26.0 -0700 +++ @/sys/types.h2012-04-02 14:20:19.0 -0700 @@ -268,7 +268,7 @@ #if __STDC_VERSION__ 199901L __GNUC__ 3 !defined(__INTEL_COMPILER) typedefint_Bool; #endif -typedef_Boolbool; +// typedef_Boolbool; #endif /* !__bool_true_false_are_defined !__cplusplus */ Any advice... FreeBSD guava 9.0-STABLE FreeBSD 9.0-STABLE #0: Fri Mar 30 23:19:22 PDT 2012 root@guava:/usr/obj/usr/src/sys/GUAVA amd64 Rudy ___ 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: Using TMPFS for /tmp and /var/run?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/29/2012 13:52, Xin Li wrote: On 03/29/12 09:41, Chris Rees wrote: On 29 Mar 2012 16:49, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. I figured out some problems with some rc.d scripts when using TMPFS for /var/run, samba and OpenLDAP do store some informations like PID in a subfolder of their own in /var/run, but the rc.d scripts are not checking properly the existence of the appropritae folder (unlike dbus and hald, they check properly!). I already submitted two PRs, but for SAMBA, my hack is trivial and obviously to clumsy, so it should be check properly. My question is whether there are objections using TMPFS for bot /tmp/ and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64? Any rc script that complains about an empty /var/run is buggy- it should be assumed that it will be emptied on boot. Agreed. We may want a generic way of registering custom mtrees (or something) that creates the hierarchy on boot, by the way. Currently this has to be done by individual rc.d scripts if they need a separate directory. I think there is some confusion here, so hopefully I can help clear it up. For BASE rc.d scripts, definitions for needed subdirectories and their permissions for /var/run are located in /etc/mtree/BSD.var.dist, which is called by /etc/rc.d/var at boot time. Anything IN THE BASE that complains about a missing directory in /var/run needs to be fixed, and should be reported. For PORTS rc.d scripts, they are expected to create (or check for the existence of) the needed directories/permissions *in the script* (not at port/package install time, this is why). Any variations on that theme should also be reported. In short, there is nothing in rc.d (ports or base) that should fail if you start with an empty /var/run. If it does, it's a bug. Meanwhile, as much as I find it personally distasteful, I can't imagine us changing the default for clear_tmp_enable at this point. hth, Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPeiaxAAoJEFzGhvEaGryEefQH/14QUKTun4njDF6YHHPlBcqz 1Ky97Dlu3cka9rNee8y7aJWSK61mg/OjacjgViKrrA6isOg/wsaJ6qK9XCk1Npb/ ZKEvszPvdHcdy+XA78HS/UTa1Pqxx+H6UPiF2s0f80LkP468UthfszXXhw8jJbSh dWG9OluprWd/21iHco5S/V+i0zgcEHHkdWAT+N5+w4Cw8cUiVk+hV90YpUK9PnO4 bzfvqppP9tCdnt9J/q8bUwNy4iK3orfSMRZ5SFFpKqeUTI4fbY3CuZHsEXf1AXQI LhVlRoCa35exFv5k9ivJ3IJMorNsLSulXluCrULn38yvtlRSazWWFCcVha18mbs= =cPrk -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: x220 notes
On 04/01/12 22:49, Kevin Oberman wrote: 2012/4/1 Любомир Григоровnm.kn...@gmail.com: Well I can't do the brightness switching. acpi_call port is installed, but: # kldload acpi_call kldload: can't load acpi_call: No such file or directory # acpi_call -p '\VBRC' -i 14 ioctl: Device not configured At least closing the lid turns off the monitor (not going to sleep), which is OK to conserve energy when not using. I would like to be able to change brightness, however. And have dimming. A minor problem, with the KMS Intel patch, when I log out of X (startx or xfce4), screen goes black. I don't know if this is acpi related. I typed reboot, and nothing happened. Using all.13.7-stable-9.patch with 9.0-STABLE. # cd /usr/ports/sysutils/acpi_call make install clean # rehash # kld_load acpi_call # acpi_call -p '\VBRC' -i 5 Exactly...I'd like to add it does require appropriate kernel sources, something I discovered as I'm currently testing off a 4gb USB...appropriately to current discussions, /usr/obj /usr/ports/distfiles /tmp /var/run are all tmpfs :) (we'll see how that goes too!). Some general followup/status of brightness: The hotkeys are working just fine out of the box, at least as far as they seem to adjust the brightness value seen by acpi_video, however as we know this doesn't actually seem to do much. There are a couple of branches in the ACPI code when brightness is called, one of which checks for integrated or discrete graphics (why I do not know as discrete is not an option). If \VIGD returns 1 (which I think means graphics are integrated) it talks to the \_SB.PCI0.LPC.EC.BRNS method, which doesn't seem to do anything for us. If \VIGD returns 0 (which I think would mean discrete graphics if available) it calls \VBRC The above method simply bypasses the VIGD switch and calls \VBRC directly. There are other ACPI methods which seem to be related, but I have yet to figure out what they mean...VBTC is one, and some _Q(X)(X) methods also seem to talk to the EC about the panel and brightness etc. It seems like we need to find how to make the EC be in charge of brightness instead of whatever VBRC is doing (it's an SMI call). I think brightness might just work fine...another note is the fact that acpi_video sees lcd0 as inactive...not sure why. Regarding acpi_ibm, it appears that it is also talking to the EC, which is why brightness cannot work there. Although for some reason, probably an alignment or address change, the fan speed appears corrupt after setting brightness via acpi_ibm, the fan controls still work fine in both manual and automatic as far as I can tell. It seems like if we can determine why the EC does not care for brightness settings, or isn't in charge of brightness, that we would be a small patch away from fixing acpi_ibm for this model. HOWEVER, it appears resume is now toast on CURRENT, since at least a few months, with or without Konstantin's patches. I'm not sure what's hanging, although setting suspend_beep=1 creates a horrible sound during the failing resume, which may indicate it's something fairly early in the resume, or even concurrent with beeping. Even bounce does not work, and debugging is complicated by the lack of display. If anyone has anyone ideas for fixing resume on CURRENT, we'd be awful close to having a pretty damn nice laptop for FreeBSD. Matt ___ 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
[head tinderbox] failure on mips/mips
TB --- 2012-04-03 01:10:03 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-03 01:10:03 - starting HEAD tinderbox run for mips/mips TB --- 2012-04-03 01:10:03 - cleaning the object tree TB --- 2012-04-03 01:10:46 - cvsupping the source tree TB --- 2012-04-03 01:10:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-04-03 01:11:27 - building world TB --- 2012-04-03 01:11:27 - CROSS_BUILD_TESTING=YES TB --- 2012-04-03 01:11:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-03 01:11:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-03 01:11:27 - SRCCONF=/dev/null TB --- 2012-04-03 01:11:27 - TARGET=mips TB --- 2012-04-03 01:11:27 - TARGET_ARCH=mips TB --- 2012-04-03 01:11:27 - TZ=UTC TB --- 2012-04-03 01:11:27 - __MAKE_CONF=/dev/null TB --- 2012-04-03 01:11:27 - cd /src TB --- 2012-04-03 01:11:27 - /usr/bin/make -B buildworld World build started on Tue Apr 3 01:11:28 UTC 2012 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 -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 kfd.8.gz === kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mips/src/tmp/usr/bin/ld: /obj/mips.mips/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mips/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-03 01:59:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-03 01:59:55 - ERROR: failed to build world TB --- 2012-04-03 01:59:55 - 2060.05 user 435.80 system 2991.37 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.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: x220 notes
Interesting. So brightness value is changed, but not acted upon then when using the hotkeys? I could care less about suspend/resume as I don't really use it. Brightness and the fan (thanks for reminding me about the corruption) are what is killing my use. I have a SSD so even though boot isn't 5sec on FreeBSD, I can still live with waiting 10 extra seconds. Having brightness eat up my battery time and fan spinning like crazy is a problem, though. What do you mean by the fan controls still work in manual and automatic? Does that mean every time brightness is changed, fan speed needs to be set to auto again for it to work properly? Also, I assume the dimming from inactivity will not work until EC is responsible for brightness change? ... and then I have the issue with Konstantin's latest patch for STABLE where after I exit X, I have no monitor or keyboard control. I guess I can bypass this with a login manager. Cheers. -- Lyubomir Grigorov (bgalakazam) ___ 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: x220 notes
On 04/02/12 18:42, Любомир Григоров wrote: Interesting. So brightness value is changed, but not acted upon then when using the hotkeys? Yes, value changes with no effect when hotkeys are pressed...I am not sure why there is no effect. I could care less about suspend/resume as I don't really use it. Brightness and the fan (thanks for reminding me about the corruption) are what is killing my use. I have a SSD so even though boot isn't 5sec on FreeBSD, I can still live with waiting 10 extra seconds. Having brightness eat up my battery time and fan spinning like crazy is a problem, though. The fan is horribly noisy on this model. However, it will quiet down a bit on its own when temperature goes down...enabling C states and running powerd -a adaptive -b adaptive should help a lot...I don't recommend manual fan control as at least my i7 already runs way too hot in linux and win7 (for the 10 minutes I had it :) ). Run Lenovo bios updates as well, many complaints about post tsunami fans from Lenovo China instead of Lenovo Japan... What do you mean by the fan controls still work in manual and automatic? Does that mean every time brightness is changed, fan speed needs to be set to auto again for it to work properly? Only the fan speed value shows as 0x or something, however it can still be set 1-7 or back to automatic as usual Also, I assume the dimming from inactivity will not work until EC is responsible for brightness change? I'm not sure...that might be accomplished with dpms.ko, haven't tried ... and then I have the issue with Konstantin's latest patch for STABLE where after I exit X, I have no monitor or keyboard control. I guess I can bypass this with a login manager. http://wiki.freebsd.org/Intel_GPU On Konstantin's page he mentions this...it's a known issue Matt ___ 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
