using -ftracer stops buildworld at shutdown.c
Adding -ftracer to my make.conf causes problems with /src/sbin/shutdown/shutdown.c This is my make.conf settings CPUTYPE=athlon-xp CFLAGS=-O2 -pipe -ffast-math -funroll-loops -ftracer COPTFLAGES=-O2 -pipe -funroll-loops -ffast-math -ftracer Doing a little research I found these items: -ftracer Perform tail duplication to enlarge superblock size. This transformation simplifies the control flow of the function allowing other optimizations to do better job. Why do I get warning: variable (or argument) `blah' might be clobbered by `longjmp' or `vfork' and how do I fix it? When the C runtime executes a longjmp, the flow of control passes back to the last setjmp that was executed. In the process, the stack (which contains arguments and local variables) must be 'unwound', that is, returned to the exact same state that it was in when setjmp was executed. Unfortunately, due to optimizations such as storing the value of a variable in a register instead of on the stack, the compiler cannot always guarantee that the stack will be restored precisely to its original state. Thus some local variables and/or arguments can be 'clobbered'. To avoid this warning, the variables and/or arguments should be prevented from being optimized by declaring them as volatile. So I sprinkled some volatiles around, but mostly got more errors that said gcc volatile discards qualifiers from pointer target type in the fprintf functions. The error went away after I removed -ftracer, but from what I have read it would be advantageous to change the variable pf to be stored on the stack and not in a register. That is if it is not stored on the stack. I did a search of all the listed include files in shutdown.c and found no matches for pf. Anyone one have any thoughts or insights on this? Am I completely off in left field? Jason === sbin/shutdown (all) cc -O2 -pipe -DNOPROFILE -ffast-math -ftracer -funroll-loops -march=athlon-xp -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/sbin/shutdown/shutdown.c /usr/src/sbin/shutdown/shutdown.c: In function `timewarn': /usr/src/sbin/shutdown/shutdown.c:276: warning: variable 'pf' might be clobbered by `longjmp' or `vfork' *** Error code 1 Stop in /usr/src/sbin/shutdown. *** Error code 1 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Low HDD tranfer rate with FreeBSD 5.3-Release
Amandeep wrote: Hi all, I am using Tyan S2098 MB with 160GB Maxtor ATA Drive and the transfer rate is very low. FreeBSD 5.3-Release. Any ideas what is going on here. The transfer rate is about 15MB/s when I run #dd if=/dev/zero of=/usr/junk bs=8192 then do #iostat 1 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Check the performance archive for a long thread on disk tweaking. sysctl vfs.read_max=32 should give you a good boost, but read that thread being attempting this. There was another tweak in there I found interesting, but can be dangerous. I'll let you look that one up. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: 5-STABLE kernel build with icc broken
Peter Jeremy wrote: On Mon, 2005-Mar-28 23:23:19 -0800, David Leimbach wrote: meant to send this to the list too... sorry Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel? I believe it does use SIMD for some of it's fast memcopy stuff for it's messaging system actually. I remember Matt saying he was working on it. http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00262.html That's almost a year ago and specifically for the amd64. Does anyone know what the results were? If you can manage the alignment issues it can be a huge win. For message passing within the kernel, you should be able to mandate alignment as part of the API. I see the bigger issue being the need to save/restore the SIMD engine's state during a system call. Currently, this is only saved on if a different process wants to use the SIMD engine. For MMX, the SIMD state is the FPU state - which is non-trivial. The little reading I've done suggests that SSE and SSE2 are even larger. Saving the SIMD state would be more expensive that using integer registers for small (and probably medium-sized) copies. Later in that thread they discuss skipping the restore state to make things faster. The minimum buffer size they say this will be good for is between 2-4k. Does this make sense, or am I showing my ignorance? http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00264.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
Alexander Leidinger wrote: On Sun, 27 Mar 2005 05:40:44 -0800 Avleen Vig [EMAIL PROTECTED] wrote: On Sun, Mar 27, 2005 at 01:30:59PM +0200, Alexander Leidinger wrote: It seems to me that building kernel with icc is currently broken, at least in 5-STABLE. Could somebody investigate this? I don't have a problem to compile it with a recent -current and a recent icc (-stable not tested), but the resulting kernel imediatly panics (page fault in _mtx_...()). Without intending to start any compiler holy wars, what benefits does ICC provide over GCC for the end user? Various: - auto-vectorizer (no benefit for the kernel, since we can't use FPU/SIMD instructions at any time... yet (interested hackers can have a look how DragonFly handles it, I can provide the necessary commit logs)) Are you implying DragonFly uses FPU/SIMD? For that matter does any kernel? Thanks, jason - optimizations for Intel CPUs direct from the manufacturer of the CPU (they have a lot of interest to produce very fast code) - a different set of compiler warnings - better code quality (if is compilable by more than one compiler it may be more portable) Icc already pointed out some bad code (asm code in the IP checksumming code... DragonFly changed it already), and the panic as noticed above may also be an indication that we have some code in the tree which smells bad. Bye, Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NIC detected, but won't DHCP or configure
Andrew Robinson wrote: Dear FreeBSD hackers, I posted the following question on freebsd-questions. Two kind souls kicked it around for a little and suggested that I pass it on to you. I have a laptop with a netowrk card that seems to be successfully detected under FreeBSD, Knoppix, and WinXP, but will only work under Knoppix and WinXP. I tender the following for your information. Windows identifies the card as Realtek RTL8169/8110 Family Gigabit Ethernet NIC. scanpci and pciconf (see below) seem to agree. Under FreeBSD: dmesg: pciconf -lv output is: == [EMAIL PROTECTED]:3:0: class=0x02 card=0x09001558 chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter' class = network subclass = ethernet [EMAIL PROTECTED]:5:0: class=0x028000 card=0x68331462 chip=0x02011814 rev=0x01 hdr=0x00 vendor = 'Ralink Technology Corp' class = network Try kldload if_re.ko, and man if_re. This means that you have no driver attached to it: [EMAIL PROTECTED]:3:0: See how I have the if_nv.ko loaded and working. [EMAIL PROTECTED]:4:0: class=0x02 card=0x10001695 chip=0x006610de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T Networking Adapter' class= network subclass = etherne ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freebsd 5.3 problem
On 03/14/05 15:34:59, Amandeep Pannu wrote: Hi Kris, I had this problem before and I changed the MB and the memory and today it did the same thing it did before. memtest doesnt give any errors. Thanks A Memtest86 right? There is another that you run in an os like any other program. Did you leave memtest86 running over night or the weekend? How are your temps under load? Do you use a ups? On Mon, Mar 14, 2005 at 12:23:59PM -0800, Amandeep Pannu wrote: HI all, I am running FreeBSd 5.3-REL Today my system simply locked up. There was no error sent to console, to any logs, nor the monitor screen. It was totally unresponsive to network, serial console, or keyboard. After 4 power-cycles, we were unable to get past the BIOS as it was reporting RAM R/W error. I have a screen shot of this from the serial port console, but it is the same as the one from before. If I hit the F1 Looks like hardware failure. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] -- Amandeep.S [EMAIL PROTECTED] http://aman.chamkila.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc vs ptmalloc2
On 02/13/05 03:21:29, David Schultz wrote: On Sun, Feb 13, 2005, Jason Henson wrote: I saw on a few of the lists here how linux uses ptmalloc2 and it outperforms bsd's malloc. I tried to do some research into it and found PHK's pdf on it and it seems bsd's malloc was ment to be ok in most every situation. Because of this it shines when primary storage is seriously over committed. So here is my question, I use FreeBSD as a desktop and never ever use swap(I just don't stress my system enough?), can I use ptmalloc in stead of malloc? Like defining SCHED_ULE instead of SCHED_4BSD. Can the system malloc be switched out? With a little bit of work, you should be able to replace src/lib/libc/stdlib/malloc.c. ptmalloc is much more heavyweight, but it would probably do better in cases where you have a large number of threads doing a massive number of malloc/free operations on a multiprocessor system. Other than that, I don't know enough details about ptmalloc to speculate, except to say that for most real-world workloads on modern systems, the impact of the malloc implementation is likely to be negligible. Of course, test results would be interesting... I see what you mean by heavy weight! Looking through the sources. The gains looked promising in this thread http://docs.freebsd.org/cgi/mid.cgi?420BB1FF.11156.68F6CEC I might find the time for it, and if I do I hope it is not too difficult. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
malloc vs ptmalloc2
I saw on a few of the lists here how linux uses ptmalloc2 and it outperforms bsd's malloc. I tried to do some research into it and found PHK's pdf on it and it seems bsd's malloc was ment to be ok in most every situation. Because of this it shines when primary storage is seriously over committed. So here is my question, I use FreeBSD as a desktop and never ever use swap(I just don't stress my system enough?), can I use ptmalloc in stead of malloc? Like defining SCHED_ULE instead of SCHED_4BSD. Can the system malloc be switched out? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GENERIC build broken
On 01/24/05 20:32:04, Ryan Sommers wrote: Michael Nottebrock wrote: Poul-Henning Kamp wrote: I have stared with fascination on this email for a full 30 minutes. What could possibly be going on in the mind which came up with the idea to take a five year old email, change Matt Dillons name and repost it to our mailing list ? So that's what this lowlife is quoting, heh. I already wondered last time, but it just didn't occur to me I had to go _that_ far back into the list archives :-). Will the pipermail archive on the main site even go back that far? I had to go to mail-archive.com to go back that far. Furthest I saw on the main page (mind you I didn't bother downloading the full raw mbox file) was back to Apr 2003 http://docs.freebsd.org/mail/ Year SizeE-Mails 19942 MB758 1995 121 MB 58,079 1996 192 MB 85,428 1997 231 MB 98,264 1998 393 MB160,988 1999 456 MB191,178 2000 534 MB216,844 2001 688 MB242,827 2002 838 MB250,604 2003 884 MB229,810 2004 2005 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resize freebsd partition
On 01/20/05 01:42:19, Kamal R. Prasad wrote: Hello, Can someone tell me how to resize the freebsd partition without losing any data? I have a 8GB freebsd partition and 1/2 GB swap and want to install another *bsd onto the harddisk. thanks -kamal I don't think you can shrink, but you can grow a file system. Do man growfs. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce3 NIC on 5.3 (i386)
On 01/19/05 02:29:45, Sven Ahtama wrote: Hello folks, Anyone here who have managed to get the nForce3 MCP NIC to work with FreeBSD 5.3 on i386 platform? After several hours of retries and kernel configuration i managed to get the if_nv.ko successfully loaded. No complaints, no errors, but also, no nv0 device found. Just like it didn't exist. I also read that one of the common problems in such cases was the agp driver, however i'm not even using one. Even more, I tried a kernel run entirely without agp support. I got the if_nv loaded as module and tried compiled-in as well. I'd really appreciate any pointers, or a conclusive confirmation, that there is no success yet. Regards, chance. When you first load the driver you have to reboot or run some scripts by hand. After the install did you reboot with no other changes and it not work? IIRC, you need linux loaded as well as miibus. I made a pr about the nvnet port being out of date and it was updated so the nic would work in 64bit mode. http://www.freebsd.org/cgi/query-pr.cgi?pr=71548 So I know atleast it has worked on amd64. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce3 NIC on 5.3 (i386)
On 01/19/05 16:59:07, chance wrote: Jason Henson wrote: When you first load the driver you have to reboot or run some scripts by hand. After the install did you reboot with no other changes and it not work? IIRC, you need linux loaded as well as miibus. I made a pr about the nvnet port being out of date and it was updated so the nic would work in 64bit mode. In fact I did reboot after install and confirmed that both the miibus and if_nv were loaded. However I read from various sources that linux compatibility is not required. So I tried without, I will give it a try with linux emulation loaded, just to be sure. What comes to the PCI IDs, it seems to me they are there. At least in the source part of the freebsd fix. I could not verify what is included in the linux binary, but the nVidia site claims that these drivers support nForce3 and so I have heard they do. Regards, chance. BTW checkout this link http://www.onthenet.com.au/~q/nvnet/ You say the ids seem to be there, do you mean in /usr/ports/net/nvnet/ wprk/src/if_nvreg.h? This will be different on your machine: $ pciconf -lv|grep nv [EMAIL PROTECTED]:4:0: class=0x02 card=0x10001695 chip=0x006610de rev=0xa1 hdr=0x00 but does the chip equal 0x00D610de on your machine? D6 is the chip id an 10de is for manufacturer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]