Re: JKH Project: x86: pcb_ext
On Wed, 19 Sep 2001, Peter Wemm wrote: : :One comment: : :- cmpl$0, PCB_USERLDT(%edx) /* if there is one */ :+ movlTD_PROC(%ecx), %eax /* load struct proc from CURTHREAD */ :+ lealP_MD(%eax), %eax/* get mdproc from proc */ :+ cmpl$0, MD_LDT(%eax)/* if there is one */ : : :This can be written as: : movlTD_PROC(%ecx), %eax : cmpl$0, P_MD+MD_LDT(%eax) : :This is evaluated at assemble time. Yea, Kinda dumb on my part :-/ : :And this change: :movl %eax,PCPU(CURRENTLDT) /* store what we have */ : jmp 2f : :-1:pushl %edx/* call a non-trusting routine */ :+1:pushl %eax/* call a non-trusting routine */ : callset_user_ldt/* to check and load the ldt */ :- popl%edx :+ popl%eax : 2: : :is not good.. you still need to save %edx since set_user_ldt is free :to trash it (%edx is the secondary return value from a C function). : Hmm interesting. Thanks. :eg: :0xc02e75c4 : mov0x10(%ebx),%edx :0xc02e75c7 : mov%edx,(%eax,%ecx,1) :0xc02e75ca : mov0x14(%ebx),%edx :0xc02e75cd : mov%edx,0x4(%eax,%ecx,1) : :The code after this in swtch.s depends on %edx being preserved. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] :"All of this is for nothing if we don't go to the stars" - JMS/B5 : : *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
"Andrew R. Reiter" wrote: > On Wed, 19 Sep 2001, Julian Elischer wrote: > > :> > :> We still would need to sync LDT reloads.. > : > :that's more of a worry for me. > :Do we still have separate a LDT for threads? > : > > LDT is per process therefore, in the patch I made, I moved pcb_ldt out > of struct pcb and into mdproc (which is in struct proc). > > I've asked Peter to take a look at it and jhb, however, it is located at: > http://www.watson.org/~arr/fbsd-patches/ldt-2-mdproc.diff One comment: - cmpl$0, PCB_USERLDT(%edx) /* if there is one */ + movlTD_PROC(%ecx), %eax /* load struct proc from CURTHREAD */ + lealP_MD(%eax), %eax/* get mdproc from proc */ + cmpl$0, MD_LDT(%eax)/* if there is one */ This can be written as: movlTD_PROC(%ecx), %eax cmpl$0, P_MD+MD_LDT(%eax) This is evaluated at assemble time. And this change: movl%eax,PCPU(CURRENTLDT) /* store what we have */ jmp 2f -1: pushl %edx/* call a non-trusting routine */ +1: pushl %eax/* call a non-trusting routine */ callset_user_ldt/* to check and load the ldt */ - popl%edx + popl%eax 2: is not good.. you still need to save %edx since set_user_ldt is free to trash it (%edx is the secondary return value from a C function). eg: 0xc02e75c4 : mov0x10(%ebx),%edx 0xc02e75c7 : mov%edx,(%eax,%ecx,1) 0xc02e75ca : mov0x14(%ebx),%edx 0xc02e75cd : mov%edx,0x4(%eax,%ecx,1) The code after this in swtch.s depends on %edx being preserved. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
On Wed, 19 Sep 2001, Julian Elischer wrote: :> :> We still would need to sync LDT reloads.. : :that's more of a worry for me. :Do we still have separate a LDT for threads? : LDT is per process therefore, in the patch I made, I moved pcb_ldt out of struct pcb and into mdproc (which is in struct proc). I've asked Peter to take a look at it and jhb, however, it is located at: http://www.watson.org/~arr/fbsd-patches/ldt-2-mdproc.diff Cheers, Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
Peter Wemm wrote: > > John Baldwin wrote: > > > > On 19-Sep-01 Peter Wemm wrote: > > > The more I think about it, the right place may be the kse, since that > > > outlives > > > the threads and is per-cpu unlike the process. > > > > > > Or, we just say "no pcb extensions for kse processes". > > > > Each thread would need its own TSS, and to preserve existing semantics, we > > would have to change the TSS of all threads for each TSS related syscall. In > > light of that, I vote in favor of "no TSS's for kse processes" since TSS's ar > e > > used for very few things anyways. LDT's are another matter and can be moved > > w/o a problem. > > The main two things we seem to use the per-process TSS stuff for are: > Fine grained IO port permission bitmap > VM86 mode > I think we can well do without the complexity of mixing KSE with those two. I could IMAGINE a vm86 version that ran the control/exception thread on another processor as a different thread. (though who would write it?) I could also imagine a muli-threaded program doing IO to a device as a userland driver. but of course hey'd need to be writen explicitly for it.. > > We still would need to sync LDT reloads.. that's more of a worry for me. Do we still have separate a LDT for threads? > > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
John Baldwin wrote: > > On 19-Sep-01 Peter Wemm wrote: > > The more I think about it, the right place may be the kse, since that > > outlives > > the threads and is per-cpu unlike the process. > > > > Or, we just say "no pcb extensions for kse processes". > > Each thread would need its own TSS, and to preserve existing semantics, we > would have to change the TSS of all threads for each TSS related syscall. In > light of that, I vote in favor of "no TSS's for kse processes" since TSS's ar e > used for very few things anyways. LDT's are another matter and can be moved > w/o a problem. The main two things we seem to use the per-process TSS stuff for are: Fine grained IO port permission bitmap VM86 mode I think we can well do without the complexity of mixing KSE with those two. We still would need to sync LDT reloads.. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Need testers, Broadcom BCM570x gigE driver
Ok, it's taken some doing, but I finally have a preliminary driver for the Broadcom BCM570x gigE controllers ready for testing. The code is at: http://www.freebsd.org/~wpaul/Broadcom/4.x This is for people with the following hardware: 3Com 3c996-T gigE NIC SysKonnect 9D21 gigE NIC Dell PowerEdge 2550 server with integrated BCM5700 I should have a FreeBSD 5.0-current driver ready soon (like, probably tomorrow). For now, only the source is available, and you need to perform the following steps to use it: 1) Install FreeBSD 4.3-RELEASE or later 2) Make sure you have the kernel source installed in /usr/src 3) Copy brgphy.c and brgphyreg.h to /sys/dev/mii. These files replace the copies that are already there. (You can save the older versions if you want.) 4) mkdir /sys/dev/bge 5) Copy if_bge.c and if_bgereg.h to /sys/dev/bge 6) Edit /sys/conf/files and add the following line: dev/bge/if_bge.coptional bge 7) Edit your kernel config file (e.g. /sys/i386/conf/MYKERNEL) and add the following line device bge # Broadcom BCM570x gigabit ethernet 8) Config and compile a new kernel Preliminary tests have yielded the following results: TCP, normal size frames: 440Mbps TCP, jumbo frames: 650Mbps UDP TX, normal frames: 710Mbps UDP TX, jumbo frames: 915Mbps Hardware checksum offload is enabled by default. These tests were done with the card in a 64-bit PCI slot. Anyone who has one of these cards and can test this driver for me, please do so and let me know your results. There may be one or two rough edges, so don't be too surprised if you run into an unusual problem. Only problem I've observed so far: on my 32-bit test box, RX checksum offload sometimes didn't behave right. To disable checksum offload, #define BGE_CSUM_FEATURES to 0, then recompile. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot proccess
Hello, | In short, which program gives enough knowledge to the microprocessor (?) | and allow him to use kern.flp & mfsroot.flp in order to boot and make the | operating system running. your BIOS reads the first sektor from your floppy which consists of a boot loader, which usually loads the 2nd step boot loader and this one loads the kernel. -- Mit freundlichen Gruessen, Marco Wertejuk - mwcis.com Computer/Internet/Security-Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
On Wed, 19 Sep 2001, John Baldwin wrote: : :Each thread would need its own TSS, and to preserve existing semantics, we :would have to change the TSS of all threads for each TSS related syscall. In :light of that, I vote in favor of "no TSS's for kse processes" since TSS's are :used for very few things anyways. LDT's are another matter and can be moved :w/o a problem. Currently fixing a bug in my patch for moving ldt -> mdproc (in struct proc), when done I will let you know -- should be mid-day today. Cheers, Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
On 19-Sep-01 Peter Wemm wrote: > The more I think about it, the right place may be the kse, since that > outlives > the threads and is per-cpu unlike the process. > > Or, we just say "no pcb extensions for kse processes". Each thread would need its own TSS, and to preserve existing semantics, we would have to change the TSS of all threads for each TSS related syscall. In light of that, I vote in favor of "no TSS's for kse processes" since TSS's are used for very few things anyways. LDT's are another matter and can be moved w/o a problem. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with IPFW and NATD (refined) !!!
[Please don't cross-post] You did not tell us what exactly does not work. DNS should work, and FTP should not as it requires data channel on a separate port. If that's the case, you may run natd(8) with the -punch_fw option. On Wed, Sep 19, 2001 at 05:06:38PM +0300, Vladimir Terziev wrote: > Sorry, but there is a rule number mistake in my previous e-mail with the same > subject. > > I have a gateway machine which runs NATD (natd -unregistered_only -interface > an0) and have IP packet filter IPFW with the following rules: > > > ipfw add 100 allow ip from any to any via lo0 > > ipfw add 10002 skipto 2 tcp from 192.168.15.2 to any 21 > ipfw add 10003 skipto 2 tcp from 192.168.15.2 to any 53,6667,6668 > ipfw add 10004 skipto 2 udp from 192.168.15.2 to any 53,4000 > > ipfw add 11000 deny ip from 192.168.15.0/24 to any > > ipfw add 2 divert natd ip from any to any via an0 > > ipfw add 3 allow ip from PUBLIC_IP to any > ipfw add 3 allow ip from any to PUBLIC_IP > > ipfw add 40001 allow tcp from any 21 to 192.168.15.2 established > ipfw add 40002 allow tcp from any 53,6667,6668 to 192.168.15.2 established > ipfw add 40003 allow udp from any 53,4000 to 192.168.15.2 > > ipfw add 65000 deny ip from any to any > > > The gateway machine is FreeBSD 4.4-RC and has 2 interfaces (internal, and > external - an0). I need only one of machines in the local network to have > connectivity to "the rest of the world". > > I've read all the documentation about ipfw(8), divert(4) and natd(8). > Regarding to it the above rules should provide what I want, but they don't !!! > > Does anybody have an idea why? > > regards, > Vladimir -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problem with IPFW and NATD (refined) !!!
Sorry, but there is a rule number mistake in my previous e-mail with the same subject. I have a gateway machine which runs NATD (natd -unregistered_only -interface an0) and have IP packet filter IPFW with the following rules: ipfw add 100 allow ip from any to any via lo0 ipfw add 10002 skipto 2 tcp from 192.168.15.2 to any 21 ipfw add 10003 skipto 2 tcp from 192.168.15.2 to any 53,6667,6668 ipfw add 10004 skipto 2 udp from 192.168.15.2 to any 53,4000 ipfw add 11000 deny ip from 192.168.15.0/24 to any ipfw add 2 divert natd ip from any to any via an0 ipfw add 3 allow ip from PUBLIC_IP to any ipfw add 3 allow ip from any to PUBLIC_IP ipfw add 40001 allow tcp from any 21 to 192.168.15.2 established ipfw add 40002 allow tcp from any 53,6667,6668 to 192.168.15.2 established ipfw add 40003 allow udp from any 53,4000 to 192.168.15.2 ipfw add 65000 deny ip from any to any The gateway machine is FreeBSD 4.4-RC and has 2 interfaces (internal, and external - an0). I need only one of machines in the local network to have connectivity to "the rest of the world". I've read all the documentation about ipfw(8), divert(4) and natd(8). Regarding to it the above rules should provide what I want, but they don't !!! Does anybody have an idea why? regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Boot proccess
Hi, Newbie, I need to understand the differents steps of a booting process from the 2 floppies (kern.flp & mfsroot.flp). How it comes and the FreeBSD machine can understand the fact that it has to find kern.flp & mfsroot.flp from the floppy, uncompress them, load them in the RAM and make them running ? In short, which program gives enough knowledge to the microprocessor (?) and allow him to use kern.flp & mfsroot.flp in order to boot and make the operating system running. Thanks in advance. Christophe. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: no memory problem
Mathieu Arnold wrote: > > Mathieu Arnold wrote: > > > > Frank Volf wrote: > > > > > > Mathieu Arnold wrote: > > > > > What is the output of > > > > > > > > > > vmstat -m | egrep -i '(pfil|filter|temp)' > > > > > > > > well, for now, it's ok, as I rebooted the box yesterday > > > > temp 27491 12187K 16963K 40960K 150216330 0 > > > > 16,32,64,128,256,512,1K,4K,16K,512K > > > > but it will soon reach the 40960K limit. And I don't see where I can > > > > move this limit upper. > > > > > > You haven't reached the limits yet. I was wondering whether you were hitting > > > the limit for the zone or the limit for all malloced area. > > > > well, that's because I rebooted the box, usually, the max is 40964K. > > here we go again : > IP states added: > 9469918 TCP > 1654588 UDP > 1451233 ICMP > 2869559782 hits > 100258517 misses > 0 maximum > 72605 no memory > 2915 bkts in use > 9766 active > 3099381 expired > 9393987 closed > > temp 82729 39223K 40961K 40960K 510822430 442 > 16,32,64,128,256,512,1K,4K,16K,512K > > does someone here know how to raise that 40960K limit ? answering to myself, I found out (raised kern.vm.kmem.size in my loader.conf). but my point now is this : # ifdefM_PFIL # define KMALLOC(a, b) MALLOC((a), b, sizeof(*(a)), M_PFIL, M_NOWAIT) # define KMALLOCS(a, b, c) MALLOC((a), b, (c), M_PFIL, M_NOWAIT) # define KFREE(x)FREE((x), M_PFIL) # define KFREES(x,s) FREE((x), M_PFIL) # else # define KMALLOC(a, b) MALLOC((a), b, sizeof(*(a)), M_TEMP, M_NOWAIT) # define KMALLOCS(a, b, c) MALLOC((a), b, (c), M_TEMP, M_NOWAIT) # define KFREE(x)FREE((x), M_TEMP) # define KFREES(x,s) FREE((x), M_TEMP) # endif /* M_PFIL */ which is in ip_compat.h from the ipfilter source tree. why does it not define somewhere a space for itself ? should it be : MALLOC_DEFINE(M_PFIL, "ipfilter", "some bigger description"); or static MALLOC_DEFINE(M_PFIL, "ipfilter", "some bigger description"); ? regards -- Mathieu Arnold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problem with IPFW and NATD (also sent to freebad-net mailing list)
Hi, I have a gateway machine which runs NATD and have IP packet filter IPFW with the following rules: ipfw add 100 allow ip from any to any via lo0 ipfw add 10002 skipto 2 tcp from 192.168.15.2 to any 21 ipfw add 10003 skipto 2 tcp from 192.168.15.2 to any 53,6667,6668 ipfw add 10004 skipto 2 udp from 192.168.15.2 to any 53,4000 ipfw add 11000 deny ip from 192.168.15.0/24 to any ipfw add 2 divert natd ip from any to any via an0 ipfw add 63000 allow ip from PUBLIC_IP to any ipfw add 64000 allow ip from any to PUBLIC_IP ipfw add 30001 allow tcp from any 21 to 192.168.15.2 established ipfw add 30002 allow tcp from any 53,6667,6668 to 192.168.15.2 established ipfw add 30003 allow udp from any 53,4000 to 192.168.15.2 ipfw add 65000 deny ip from any to any The gateway machine is FreeBSD 4.4-RC and has 2 interfaces (internal, and external - an0). I need only one of machines in the local network to have connectivity to "the rest of the world". I've read all the documentation about ipfw(8), divert(4) and natd(8). Regarding to it the above rules should provide what I want, but they don't !!! Does anybody have an idea why? regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: CAN bus
I designed a CAN controller for an embedded app some years ago now. However, I seem to remember the serial bit rate was pretty slow. Here's a link to more info if anyone's interested: http://www.can-ucan.com/ Regards Ak > Subject: Re: CAN bus > > mark tinguely wrote: > > > > > it is quite standard in industrial environments and still popular (at > > > least in europe) but existant installations slowly get replaced with > > > ethernet based (100baseFX) or industrial ethernet (10Mbit) > transceivers. > > > > I believe it was designed for noisy environments and is still used in > > automotive and large equipment (farm tractors, combines, etc). > > Thats why I chose it for my home automation project. There are a > lot of places > where I had to run the network wires right next to power wires. > Since CAN is > supposedly noise resistant and I don't need much bandwidth it > seemed like a > logical choice. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: CAN bus
I designed a CAN controller for an embedded app some years ago now. However, I seem to remember the serial bit rate was pretty slow. Here's a link to more info if anyone's interested: http://www.can-ucan.com/ Regards Ak > Subject: Re: CAN bus > > mark tinguely wrote: > > > > > it is quite standard in industrial environments and still popular (at > > > least in europe) but existant installations slowly get replaced with > > > ethernet based (100baseFX) or industrial ethernet (10Mbit) > transceivers. > > > > I believe it was designed for noisy environments and is still used in > > automotive and large equipment (farm tractors, combines, etc). > > Thats why I chose it for my home automation project. There are a > lot of places > where I had to run the network wires right next to power wires. > Since CAN is > supposedly noise resistant and I don't need much bandwidth it > seemed like a > logical choice. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: no memory problem
Mathieu Arnold wrote: > > Mathieu Arnold wrote: > > > > Frank Volf wrote: > > > > > > Mathieu Arnold wrote: > > > > > What is the output of > > > > > > > > > > vmstat -m | egrep -i '(pfil|filter|temp)' > > > > > > > > well, for now, it's ok, as I rebooted the box yesterday > > > > temp 27491 12187K 16963K 40960K 150216330 0 > > > > 16,32,64,128,256,512,1K,4K,16K,512K > > > > but it will soon reach the 40960K limit. And I don't see where I can > > > > move this limit upper. > > > > > > You haven't reached the limits yet. I was wondering whether you were hitting > > > the limit for the zone or the limit for all malloced area. > > > > well, that's because I rebooted the box, usually, the max is 40964K. > > here we go again : > IP states added: > 9469918 TCP > 1654588 UDP > 1451233 ICMP > 2869559782 hits > 100258517 misses > 0 maximum > 72605 no memory > 2915 bkts in use > 9766 active > 3099381 expired > 9393987 closed > > temp 82729 39223K 40961K 40960K 510822430 442 > 16,32,64,128,256,512,1K,4K,16K,512K > > does someone here know how to raise that 40960K limit ? answering to myself, I found out (raised kern.vm.kmem.size in my loader.conf). but my point now is this : # ifdefM_PFIL # define KMALLOC(a, b) MALLOC((a), b, sizeof(*(a)), M_PFIL, M_NOWAIT) # define KMALLOCS(a, b, c) MALLOC((a), b, (c), M_PFIL, M_NOWAIT) # define KFREE(x)FREE((x), M_PFIL) # define KFREES(x,s) FREE((x), M_PFIL) # else # define KMALLOC(a, b) MALLOC((a), b, sizeof(*(a)), M_TEMP, M_NOWAIT) # define KMALLOCS(a, b, c) MALLOC((a), b, (c), M_TEMP, M_NOWAIT) # define KFREE(x)FREE((x), M_TEMP) # define KFREES(x,s) FREE((x), M_TEMP) # endif /* M_PFIL */ which is in ip_compat.h from the ipfilter source tree. why does it not define somewhere a space for itself ? should it be : MALLOC_DEFINE(M_PFIL, "ipfilter", "some bigger description"); or static MALLOC_DEFINE(M_PFIL, "ipfilter", "some bigger description"); ? regards -- Mathieu Arnold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
