using -ftracer stops buildworld at shutdown.c

2005-07-26 Thread jason henson
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

2005-05-09 Thread jason henson
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

2005-03-29 Thread jason henson
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

2005-03-28 Thread jason henson
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

2005-03-21 Thread jason henson
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

2005-03-14 Thread Jason Henson
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

2005-02-13 Thread Jason Henson
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

2005-02-12 Thread Jason Henson
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

2005-01-24 Thread Jason Henson
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

2005-01-20 Thread Jason Henson
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)

2005-01-19 Thread Jason Henson
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)

2005-01-19 Thread Jason Henson
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]