Re: Switchover to CAM ATA?
Alexander Motin writes: > I haven't dug really deep into current ataraid(4), but AFAIK it is all > done in software. At least there is no any offloading support on the > controller drivers level. None of ata(4) drivers do anything except > executing one ATA command at a time. Correct. That doesn't mean they *shouldn't* use offloading. Like I said, I started working on checksum offloading for Promise SATA controllers, but ZFS came along and I replaced the controllers because of data corruption issues (which turned out to be either a driver bug or a PCI timing bug which sos@ worked around in the driver, I forget which) > Any URLs? Google "Promise FastTrak SATA RAID" I have two or three of those, including one with on-board SDRAM (but no battery backup) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Saturday 17 April 2010 03:08:18 Roman Divacky wrote: > Hi, > > ClangBSD is a branch of FreeBSD that aims at integrating clang > (clang.llvm.org) into FreeBSD, replacing GCC as a system compiler. > > Recently, we've achieved the state when clang can compile all of FreeBSD > world on i386/amd64 platforms (including all the C++ apps we have and > itself) and a bootable kernel. Thus we feel that the time has come to ask > the FreeBSD community for wider testing on i386/amd64 (you sure can help > with other platforms too :)). > Great works, thanks! But I have a problem with recently-compiled clangbsd (in chroot) while building lang/ruby18: clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -I. -I. -I/usr/include -c main.c clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -L. - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o libruby18-static.a -lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) from ./mkconfig.rb:11:in `require' from ./mkconfig.rb:11 *** Error code 1 host system: [r...@fluffy] ~# uname -a FreeBSD Fluffy.Khv.RU 9.0-900010-CURRENT FreeBSD 9.0-900010-CURRENT #0 r207097M: Fri Apr 23 19:20:05 VLAST 2010 r...@fluffy.khv.ru:/usr/obj/usr/src/sys/Spot amd64 clangbsd: /base/!svn/ver/206467/projects/clangbsd/sys -- Dima "Red Fox" Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018 Khabarovsk, Russia | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29 k...@freebsd Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995 Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024 ___ 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: xorg hangs after last commits
On Wed, 2010-04-28 at 10:27 +0400, Alex Keda wrote: > 27.04.2010 18:13, Robert Noland пишет: > > > > > > Alex Keda wrote: > >> 27.04.2010 17:55, Robert Noland пишет: > >>> > >>> > >>> Alex Keda wrote: > Following recent changes in dri, xorg server freezes after 20-30 > seconds of work. mouse works, but the image does not change. > process xorg get 100% cpu > if I delete/rename drm.ko - all OK (but, very slow) > > > vgap...@pci0:1:5:0: class=0x03 card=0x12ff103c > chip=0x791e1002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, > Inc.' > device = 'ATI RADEON X1200 Series (RS690)' > class = display > subclass = VGA > bar [10] = type Prefetchable Memory, range 64, base > 0xd000, size 134217728, enabled > bar [18] = type Memory, range 64, base 0xd850, size > 65536, enabled > bar [20] = type I/O Port, range 32, base 0x1100, size 256, > enabled > bar [24] = type Memory, range 32, base 0xd840, size > 1048576, enabled > cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 > cap 05[80] = MSI supports 1 message, 64 bit > >>> > >>> Ok, does this patch help? > >> yes. I work without freeze more than 3 minutes =)) > > > > How about this one? > I reverse previous and apply it patch > working time more than without it (without ~1 minutes, with last patch > ~2-3 minutes), but - one final - Xorg get 100% CPU and freeze Ok, the IGP chips are strange... Just go with the first patch for now and let it keep snooping... Performance impact shouldn't be substantial. robert. > ___ > 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" -- Robert Noland FreeBSD ___ 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"
Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now)
According to Dima Panov: > while building lang/ruby18: Which options to you use? _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1 WITHOUT_ONIGURUMA=true WITH_RDOC=true WITHOUT_DEBUG=true I notice your ruby is compiling w/o any -On, try with -O at least? > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -I. -I. > -I/usr/include > -c main.c > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -L. - > rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > libruby18-static.a -lrt > -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) > from ./mkconfig.rb:11:in `require' > from ./mkconfig.rb:11 > *** Error code 1 Interesting, using a fairly recent clang snapshot from trunk, I get a sig11 :( -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.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: [CFT]: ClangBSD is selfhosting, we need testers now
According to Brooks Davis: > For the foreseeable future, doing anything but using the latest port is a > recipe for problems. The "make BOOTSTRAP=yes makesum" is a wonderful trick, thanks Brooks! -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.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"
New Marvell SATA driver for testing
Hi. I'm glad to present new driver (mvs) for several series of Marvell SATA controllers (PCI-X, PCIe and SoC-integrated), to work with CAM ATA infrastructure. Driver supports following Marvell chips: Gen-I (SATA 1.5Gbps): 88SX5040, 88SX5041, 88SX5080, 88SX5081 Gen-II (SATA 3Gbps, NCQ, PMP): 88SX6040 ,88SX6041 (including Adaptec 1420SA), 88SX6080, 88SX6081 Gen-IIe (SATA 3Gbps, NCQ, PMP with FBS): 88SX6042, 88SX7042 (including Adaptec 1430SA); 88F5182, 88F6281, MV78100 SoCs. , same as atamarvell + ataadaptec + atamvsata legacy ata(4) drivers together. Driver supports most of hardware features, including command queues, NCQ, Port Multipliers, hot-swap, SATA power management, Command Completion Coalescing, Asynchronous Notifications and MSI. Driver also supports ATAPI devices, though it may be not very reliable due to strange ATA shadow registers behavior in these chips. I've successfully tested it with Supermicro SAT2-MV8 (88SX6081) on i386 and sparc64, Adaptec 1430SA (88SX7042) on i386, and SheevaPlug (88F6281) on arm. I haven't tested it on Gen-I chips due to lack of such hardware. Complete fresh patch for HEAD can be found here: http://people.freebsd.org/~mav/mvs.20100328.patch (make sure to run patch with -p to create directories). Testing results, comments and feedback welcome. Special thanks to iXsystems, Inc. for supporting this work. -- Alexander Motin ___ 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"
Problem with reboot
Hello! I have a trouble with my FreeBSD-CURRENT virtual machine running on VmWare ESX server. uname -a prints: FreeBSD host 9.0-CURRENT FreeBSD 9.0-CURRENT #16 r207299: Wed Apr 28 04:15:07 UTC 2010 r...@host:/usr/obj/usr/src/sys/GENERIC amd64 The problem lies in that FreeBSD hangs after "reboot" command. I see the following on console: http://www.freeimagehosting.net/image.php?8885b3c6ea.png Is it a known problem? Are there any solutions? Thanks in advance! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmi...@gmail.com skype: krivenok_dmitry jabber: krivenok_dmi...@jabber.ru icq: 242-526-443 ___ 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: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now)
On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote: > According to Dima Panov: > > while building lang/ruby18: > Which options to you use? > > _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1 > WITHOUT_ONIGURUMA=true > WITH_RDOC=true > WITHOUT_DEBUG=true > > I notice your ruby is compiling w/o any -On, try with -O at least? same here. also on 1.8.7.249 snapshot. ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o dln.o enum.o enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o variable.o version.o dmyext.o clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC -DRUBY_EXPORT -I. -I. -I/usr/include-c main.c clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC -DRUBY_EXPORT -L. -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o libruby18-static.a - lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment ruby 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9] *** Signal 6 Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249. *** Error code 1 _OPTIONS_READ=ruby-1.8.7.249,1 WITHOUT_ONIGURUMA=true WITH_RDOC=true WITHOUT_DEBUG=true > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -I. > > -I. -I/usr/include -c main.c > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -L. > > - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > > libruby18-static.a -lrt -lcrypt -lm -L/usr/lib > > -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) > > > > from ./mkconfig.rb:11:in `require' > > from ./mkconfig.rb:11 > > > > *** Error code 1 > > Interesting, using a fairly recent clang snapshot from trunk, I get a sig11 > :( Ruby is bad? -- Dima "Red Fox" Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018 Khabarovsk, Russia | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29 k...@freebsd Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995 Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024 ___ 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"
fixes for enhanced coredump
I was recently working on the enhanced coredumps
internal to Juniper and realized that there were
some defects in the code I pushed (mostly due to
mismerge), can someone please review?
1) don't allocate hostname[] on the stack
2) don't leak the temp buffer in imgact_elf_coredump.
thank you,
-Alfred
Index: kern/kern_sig.c
===
--- kern/kern_sig.c (revision 207329)
+++ kern/kern_sig.c (working copy)
@@ -3004,8 +3004,9 @@
char *temp;
size_t i;
int indexpos;
- char hostname[MAXHOSTNAMELEN];
+ char *hostname;
+ hostname = NULL;
format = corefilename;
temp = malloc(MAXPATHLEN, M_TEMP, M_NOWAIT | M_ZERO);
if (temp == NULL)
@@ -3021,6 +3022,19 @@
sbuf_putc(&sb, '%');
break;
case 'H': /* hostname */
+ if (hostname == NULL) {
+ hostname = malloc(MAXHOSTNAMELEN,
+ M_TEMP, M_NOWAIT);
+ if (hostname == NULL) {
+ log(LOG_ERR,
+ "pid %ld (%s), uid (%lu): "
+ "unable to alloc memory "
+ "for corefile hostname\n",
+ (long)pid, name,
+ (u_long)uid);
+goto nomem;
+}
+}
getcredhostname(td->td_ucred, hostname,
sizeof(hostname));
sbuf_printf(&sb, "%s", hostname);
@@ -3054,9 +3068,10 @@
}
#endif
if (sbuf_overflowed(&sb)) {
- sbuf_delete(&sb);
log(LOG_ERR, "pid %ld (%s), uid (%lu): corename is too "
"long\n", (long)pid, name, (u_long)uid);
+nomem:
+ sbuf_delete(&sb);
free(temp, M_TEMP);
return (NULL);
}
Index: kern/imgact_elf.c
===
--- kern/imgact_elf.c (revision 207329)
+++ kern/imgact_elf.c (working copy)
@@ -1088,8 +1088,10 @@
hdrsize = 0;
__elfN(puthdr)(td, (void *)NULL, &hdrsize, seginfo.count);
- if (hdrsize + seginfo.size >= limit)
- return (EFAULT);
+ if (hdrsize + seginfo.size >= limit) {
+ error = EFAULT;
+ goto done;
+ }
/*
* Allocate memory for building the header, fill it up,
@@ -1097,7 +1099,8 @@
*/
hdr = malloc(hdrsize, M_TEMP, M_WAITOK);
if (hdr == NULL) {
- return (EINVAL);
+ error = EINVAL;
+ goto done;
}
error = __elfN(corehdr)(td, vp, cred, seginfo.count, hdr, hdrsize,
gzfile);
@@ -1125,8 +1128,8 @@
curproc->p_comm, error);
}
+done:
#ifdef COMPRESS_USER_CORES
-done:
if (core_buf)
free(core_buf, M_TEMP);
if (gzfile)
--
- Alfred Perlstein
.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10
.- FreeBSD committer
___
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 kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
On Tue, Apr 27, 2010 at 7:06 PM, Maxim Sobolev wrote: > Alexander Sack wrote: >> >> On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin wrote: >>> >>> On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote: John Baldwin wrote: > > On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote: >> >> John Baldwin wrote: >>> >>> Hmm, I think you should definitely commit the atkbdc_isa.c change >>> first of >>> all. I'm still thinking about the other change. I wonder if we can >>> figure >>> out that a keyboard isn't present sooner somehow? Do you know if the >>> keyboard >>> appears to be present but just slow vs if the keyboard is eventually >>> found to >>> not be present? >> >> Our syscons does keyboard probing two times - once early during kernel >> initialization before most of the subsystems have been initialized >> yet, >> and then "real" probing later in boot process. Interesting thing is >> that >> initially keyboard looks present. Reading status port in >> atkbdc_configure() gives value other than 0xff, although reading is >> thousand times slower than usually. This causes syscons try attaching >> it. Even though reading status port works, apparently either emulation >> is not complete or there is some other issue, so that it never >> responds >> to some commands. Slow access and lack of response results in >> wait_for_data() function waiting several minutes instead of 200ms as >> designed. This what causes that 6-10 minutes delay in boot process. > > I believe the USB driver has disabled the keyboard emulation by the > time the > second probe happens in syscons. Can you try disabling legacy USB > support in > the BIOS just to make sure that is what causes the delay? Unfortunately it's not possible. Hosting provider doesn't allow me to have access to BIOS settings. >> >> Stunt double: I tried it and it has no effect. The waits in atkdbd >> kills it with or without USB legacy support on. The wait on this >> machine is about 1-2 minutes before boot. Just another data point. > > Have you tried my patch? Does it help? Maxim, yes I have. Works much better. Wait time is nominal. I would definitely document the time delay code as its non-intuitive looking at it. -aps ___ 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: newsyslog patch implementing file includes
On Thu, 22 Apr 2010, krad wrote: > On 22 April 2010 08:33, Alex Keda wrote: > > > 22.04.2010 11:29, Gordon Tetlow ?: > > > >> On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda >> ad...@lissyara.su>> wrote: > >> > >>It's need feature. I test patch - it work for me (CURRENT, amd64) > >>Can I use some as: > >> /path/to/dir/*.conf > >>? > >>and can I create recursive include? > >> > >> > >> Yes, wildcards and recursive includes are supported. > >> > > great job! > > 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" > > > > > i would be real nice is newsyslog also supported a date based file renaming > shceme rather than the cyclic 0,1,2,3, much like the datext option in > logrotate. eg > > messages > messages.20100422 > messages.20100421 > messages.20100420 > ... > > The cyclic renaming is a pain for incremental backups as all the log files > are backed up every time as their contents changes compared to their > filename Even nicer if it could use the strftime() syntax format. ie: %Y%m%d to get the date. This way it could also be named in week number. /Bjorn ___ 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: Switchover to CAM ATA?
Hello, Dag-Erling. You wrote 27 апреля 2010 г., 17:34:14: > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. Why are they called ``PSEUDO-raids'' then? -- // Black Lion AKA Lev Serebryakov ___ 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: Switchover to CAM ATA?
Lev Serebryakov writes: > "Dag-Erling Smørgrav" writes: > > Most pseudo-raid kit has nifty features like checksum offloading, > > composite writes etc. > Why are they called ``PSEUDO-raids'' then? Several reasons - they don't present the array to the OS as a single device, they don't handle failover, etc. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now)
On Thu, Apr 29, 2010 at 02:40:24AM +1100, Dima Panov wrote: > On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote: > > According to Dima Panov: > > > while building lang/ruby18: > > Which options to you use? > > > > _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1 > > WITHOUT_ONIGURUMA=true > > WITH_RDOC=true > > WITHOUT_DEBUG=true > > > > I notice your ruby is compiling w/o any -On, try with -O at least? > > same here. also on 1.8.7.249 snapshot. > > ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o dln.o > enum.o > enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o > math.o > numeric.o object.o pack.o parse.o process.o prec.o random.o range.o > re.o regex.o > ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o > variable.o > version.o dmyext.o > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC > -DRUBY_EXPORT -I. > -I. -I/usr/include-c main.c > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC > -DRUBY_EXPORT -L. > -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > libruby18-static.a - > lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o > miniruby > ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment > ruby 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9] > > *** Signal 6 > > Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249. > *** Error code 1 > > > _OPTIONS_READ=ruby-1.8.7.249,1 > WITHOUT_ONIGURUMA=true > WITH_RDOC=true > WITHOUT_DEBUG=true > > > > > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -I. > > > -I. -I/usr/include -c main.c > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -L. > > > - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > > > libruby18-static.a -lrt -lcrypt -lm -L/usr/lib > > > -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > > > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) > > > > > > from ./mkconfig.rb:11:in `require' > > > from ./mkconfig.rb:11 > > > > > > *** Error code 1 > > > > Interesting, using a fairly recent clang snapshot from trunk, I get a sig11 > > :( > > > Ruby is bad? > For the record, ruby compilation also fails with base gcc inside i386 ports tinderbox on amd64-CURRENT host: [snip] cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -I. -I. -I/usr/include-c variable.c cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -I. -I. -I/usr/include-c version.c In file included from version.c:14: version.h:29:41: warning: no newline at end of file cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -I. -I. -I/usr/include-c dmyext.c ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o dln.o enum.o enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o variable.o version.o dmyext.o cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -I. -I. -I/usr/include-c main.c cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -L. -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o libruby18-static.a -lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby ./lib/fileutils.rb:1030: retry outside of rescue clause rbconfig.rb updated *** Error code 1 Stop in /work/a/ports/lang/ruby18/work/ruby-1.8.7-p248. *** Error code 1 Stop in /a/ports/lang/ruby18. build of /usr/ports/lang/ruby18 ended at Sat Apr 24 04:57:59 UTC 2010 I don't know why it is failing in the same file (is it just included first or is it really troublesome?), but it looks quite suspicious. I am nowhere the ruby expert but it may be that the problem is in ruby itself. Note, that I have successfully built quite a lot of packages inside this i386 tinderbox on amd64 host including full kde4, openoffice3, jdk16, virtualbox-ose, mplayer, ... On the topic, if I understand it correctly, one can build clandbsd branch with normal gcc from base, so it is "backward compatible". What are the general showstoppers then to merge to HEAD the part of clangbsd that allows building HEAD with llvm from ports? I think this will significantly increase the number of testers... Alexey. ___ 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: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now)
On Wed, Apr 28, 2010 at 10:32:41PM +0200, Alexey Shuvaev wrote: > On Thu, Apr 29, 2010 at 02:40:24AM +1100, Dima Panov wrote: > > On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote: > > > According to Dima Panov: > > > > while building lang/ruby18: > > > Which options to you use? > > > > > > _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1 > > > WITHOUT_ONIGURUMA=true > > > WITH_RDOC=true > > > WITHOUT_DEBUG=true > > > > > > I notice your ruby is compiling w/o any -On, try with -O at least? > > > > same here. also on 1.8.7.249 snapshot. > > > > ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o > > dln.o enum.o > > enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o > > marshal.o math.o > > numeric.o object.o pack.o parse.o process.o prec.o random.o range.o > > re.o regex.o > > ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o > > variable.o > > version.o dmyext.o > > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC > > -DRUBY_EXPORT -I. > > -I. -I/usr/include-c main.c > > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC > > -DRUBY_EXPORT -L. > > -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > > libruby18-static.a - > > lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o > > miniruby > > ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment > > ruby 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9] > > > > *** Signal 6 > > > > Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249. > > *** Error code 1 > > > > > > _OPTIONS_READ=ruby-1.8.7.249,1 > > WITHOUT_ONIGURUMA=true > > WITH_RDOC=true > > WITHOUT_DEBUG=true > > > > > > > > > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -I. > > > > -I. -I/usr/include -c main.c > > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC-DRUBY_EXPORT -L. > > > > - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > > > > libruby18-static.a -lrt -lcrypt -lm -L/usr/lib > > > > -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > > > > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) > > > > > > > > from ./mkconfig.rb:11:in `require' > > > > from ./mkconfig.rb:11 > > > > > > > > *** Error code 1 > > > > > > Interesting, using a fairly recent clang snapshot from trunk, I get a > > > sig11 > > > :( > > > > > > Ruby is bad? > > > For the record, ruby compilation also fails with base gcc inside > i386 ports tinderbox on amd64-CURRENT host: > > [snip] > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -I. > -I. -I/usr/include-c variable.c > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -I. > -I. -I/usr/include-c version.c > In file included from version.c:14: > version.h:29:41: warning: no newline at end of file > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -I. > -I. -I/usr/include-c dmyext.c > ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o dln.o > enum.o enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o > marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o > random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o > struct.o time.o util.o variable.o version.o dmyext.o > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -I. > -I. -I/usr/include-c main.c > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC-DRUBY_EXPORT -L. > -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > libruby18-static.a -lrt -lcrypt -lm -L/usr/lib > -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > ./lib/fileutils.rb:1030: retry outside of rescue clause > rbconfig.rb updated > *** Error code 1 > > Stop in /work/a/ports/lang/ruby18/work/ruby-1.8.7-p248. > *** Error code 1 > > Stop in /a/ports/lang/ruby18. > > build of /usr/ports/lang/ruby18 ended at Sat Apr 24 04:57:59 UTC 2010 > > I don't know why it is failing in the same file (is it just included first > or is it really troublesome?), but it looks quite suspicious. > I am nowhere the ruby expert but it may be that the problem is in ruby itself. > Note, that I have successfully built quite a lot of packages inside > this i386 tinderbox on amd64 host including full kde4, openoffice3, jdk16, > virtualbox-ose, mplayer, ... This should be fixed by r206992 on HEAD, and by r207271 on stable/8. > > On the topic, if I understand it correctly, one can build clandbsd branch > with normal gcc from base, so it is "backward compatible". > What are the general showstoppers then to merge to HEAD > the part of clangbsd that allows building HEAD with llvm from ports? > I think this will significantly increase the number of testers... > > Alexey. >
sleep bug in taskqueue(9)
It looks to me like taskqueue_drain(taskqueue_thread, foo) will not
correctly detect whether or not a task is currently running. The check
is against a field in the taskqueue struct, but for the taskqueue_thread
queue with more than one thread, multiple threads can simultaneously be
running a task, thus stomping over the tq_running field.
I have not seen any problem with the code as-is in actual use, so this
is purely an inspection bug.
The following patch should fix the problem. Because it changes the size
of struct task I'm not sure if it would be suitable for MFC.
Thanks,
matthew
diff --git a/sys/kern/subr_taskqueue.c b/sys/kern/subr_taskqueue.c
index 8405b3d..3b18269 100644
--- a/sys/kern/subr_taskqueue.c
+++ b/sys/kern/subr_taskqueue.c
@@ -51,7 +51,6 @@ __FBSDID("$FreeBSD$");
const char *tq_name;
taskqueue_enqueue_fntq_enqueue;
void*tq_context;
- struct task *tq_running;
struct mtx tq_mutex;
struct thread **tq_threads;
int tq_tcount;
@@ -233,13 +232,13 @@ taskqueue_run(struct taskqueue *queue)
STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link);
pending = task->ta_pending;
task->ta_pending = 0;
- queue->tq_running = task;
+ task->ta_flags |= TA_FLAGS_RUNNING;
TQ_UNLOCK(queue);
task->ta_func(task->ta_context, pending);
TQ_LOCK(queue);
- queue->tq_running = NULL;
+ task->ta_flags &= ~TA_FLAGS_RUNNING;
wakeup(task);
}
@@ -256,14 +255,16 @@ taskqueue_drain(struct taskqueue *queue, struct
task *task)
{
if (queue->tq_spin) { /* XXX */
mtx_lock_spin(&queue->tq_mutex);
- while (task->ta_pending != 0 || task ==
queue->tq_running)
+ while (task->ta_pending != 0 ||
+ (task->ta_flags & TA_FLAGS_RUNNING) != 0)
msleep_spin(task, &queue->tq_mutex, "-", 0);
mtx_unlock_spin(&queue->tq_mutex);
} else {
WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
__func__);
mtx_lock(&queue->tq_mutex);
- while (task->ta_pending != 0 || task ==
queue->tq_running)
+ while (task->ta_pending != 0 ||
+ (task->ta_flags & TA_FLAGS_RUNNING) != 0)
msleep(task, &queue->tq_mutex, PWAIT, "-", 0);
mtx_unlock(&queue->tq_mutex);
}
diff --git a/sys/sys/_task.h b/sys/sys/_task.h
index 2a51e1b..c57bdd5 100644
--- a/sys/sys/_task.h
+++ b/sys/sys/_task.h
@@ -36,15 +36,21 @@
* taskqueue_run(). The first argument is taken from the 'ta_context'
* field of struct task and the second argument is a count of how many
* times the task was enqueued before the call to taskqueue_run().
+ *
+ * List of locks
+ * (c) const after init
+ * (q) taskqueue lock
*/
typedef void task_fn_t(void *context, int pending);
struct task {
- STAILQ_ENTRY(task) ta_link; /* link for queue */
- u_short ta_pending; /* count times queued */
- u_short ta_priority;/* Priority */
- task_fn_t *ta_func; /* task handler */
- void*ta_context;/* argument for handler */
+ STAILQ_ENTRY(task) ta_link; /* (q) link for queue */
+ u_char ta_flags; /* (q) state of this task */
+#defineTA_FLAGS_RUNNING0x01
+ u_short ta_pending; /* (q) count times queued */
+ u_short ta_priority;/* (c) Priority */
+ task_fn_t *ta_func; /* (c) task handler */
+ void*ta_context;/* (c) argument for handler */
___
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"
kmem_map too small: 3832475648 total allocated
FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206111: Mon Apr 26 01:13:00 CDT 2010 r...@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 svn 206111 is April 2 system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12 GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. The system was running this in the clang build area: while true do make -j7 buildworld done The panic happened during the 27th iteration. panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated ___ 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: kmem_map too small: 3832475648 total allocated
Do you have vm.kmem_size set in /boot/loader.conf? If not, do set it to about double of your physical RAM size. Defaults are way too conservative for use with large amounts of memory and ZFS. --Artem On Wed, Apr 28, 2010 at 8:07 PM, James R. Van Artsdalen wrote: > FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206111: > Mon Apr 26 01:13:00 CDT 2010 > r...@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > > svn 206111 is April 2 > > system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12 > GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. > > The system was running this in the clang build area: > > while true > do > make -j7 buildworld > done > > The panic happened during the 27th iteration. > > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated > > ___ > 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"
Re[2]: kmem_map too small: 3832475648 total allocated
On Wed, Apr 28, 2010 at 8:07 PM, James R. Van Artsdalen wrote: > FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206111: > Mon Apr 26 01:13:00 CDT 2010 > r...@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC ?amd64 > > svn 206111 is April 2 > > system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12 > GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. > > The system was running this in the clang build area: > > while true > do > ?make -j7 buildworld > done > > The panic happened during the 27th iteration. > > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated > I open PR amd64/145654 with problem like it. Have you increasing Wired memory at buildworld ? ___ 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"
