FreeBSD on Bochs
Hi All: I have a question about Freebsd on bochs. I'm interesting to build owner Freebsd scratch. Due the hardware limited , I want to run this scratch on Bochs. Therefore , I refered a article , http://sig9.com/articles/freebsd-on-bochs , to build a image under 5.2R. when I booted the image file under Bochs-2.0.2 .. it stoped on a prompt , mountroot . The bochs' console screenshot is following lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 500159 Hz quality 800 Timecounters tick every 10.000 msec ad0: FAILURE - SETFEATURES ENABLE RCACHE status=41READY,ERROR error=4ABORTED ad0: FAILURE - SETFEATURES ENABLE WCACHE status=41READY,ERROR error=4ABORTED GEOM: create disk ad0 dp=0xc1a81e60 ad0: 511MB Generic 1234 [1040/16/63] at ata0-master PIO2 Manual root filesystem specification: fstype:device Mount device using filesystem fstype eg. ufs:da0s1a ? List valid disk boot devices empty line Abort manual input -- the bochs' log records 00505152373i[HD ] SET FEATURES subcommand 0xaa not supported by disk. 00505289771i[HD ] SET FEATURES subcommand 0x02 not supported by disk. What's happen?! Did I miss something else ?! ps. my bochs configuration is as following -- megs: 64 romimage: file=$BXSHARE/BIOS-bochs-latest, address=0xf vgaromimage: $BXSHARE/VGABIOS-lgpl-latest floppya: 1_44=/dev/fd0, status=ejected # hard disk ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ata0-master: type=disk, path=freebsd.img, mode=flat, cylinders=1040, heads=16, spt=63 boot: disk log: out.txt mouse: enabled=0 keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/sdl-pc-us.map Regards Jumbler ___ 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
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. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
On Tue, 2005-Mar-29 10:50:32 +0300, Giorgos Keramidas wrote: A file may be repo-copied to a new location, then removed from the HEAD branch in the old location and deleted from the rest of the branches in the new location. This way the history will be there, in both places but the file will only 'live' in one place at a time. At the cost of approximately doubling the repository size - ncvs/src/sys is currently abut 366MB. There are an awful lot of repository copies lying around and even at current disk prices, the total cost in dollars is non-trivial. The bigger cost is developer time - kernel developers are familiar with the current re-organisation. It will probably take at least a month for a developer to get used to a new organisation. Multiply that by the number of developers and there's an awful lot of lost productive time. The new layout would have to offer really good incentives to have a net benefit. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Interrupt Service Routines
Do you guys know of any example code of ISR's in the kernel? Ash ___ 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
jason henson [EMAIL PROTECTED] wrote:
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?
AFAIK DragonFly _allows_ code to use the FPU/SIMD in the kernel. And AFAIR
they use SIMD in b{copy,zero} (we do this too, but we do this is in a
controlled environment whereas DFly just allows the use of FPU/SIMD in an
use as you like manner everywhere).
Bye,
Alexander.
--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Closet extrovert.
___
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
On Tue, Mar 29, 2005 at 09:11:07PM +1000, Peter Jeremy wrote: That's almost a year ago and specifically for the amd64. Does anyone know what the results were? I had a quick dig around on cvsweb this morning: http://grappa.unix-ag.uni-kl.de/cgi-bin/cvsweb/src/sys/i386/i386/bcopy.s?cvsroot=dragonfly I dunno if Matt has benchmarks for before and after. David. ___ 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
On Tue, Mar 29, 2005 at 02:12:53PM +0100, David Malone wrote: On Tue, Mar 29, 2005 at 09:11:07PM +1000, Peter Jeremy wrote: That's almost a year ago and specifically for the amd64. Does anyone know what the results were? I had a quick dig around on cvsweb this morning: http://grappa.unix-ag.uni-kl.de/cgi-bin/cvsweb/src/sys/i386/i386/bcopy.s?cvsroot=dragonfly I dunno if Matt has benchmarks for before and after. David. I believe it was asserted on the list that the modification doubled the performance. I have not tested this. --Devon pgpvyrjtIvlIN.pgp Description: PGP signature
System Panic (Trap 12)
Greets,
I am getting numerous panics. It seems to be totally random with no
bearing on load. This is a dual proc. AMD 2600, 2 GB Ram.
I have included the where results of three seperate core files.
Please advise.
Thanks in advance.
FreeBSD sbftp.sc.emaglink.com 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #7: Mon Mar
28 13:26:07 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SBFTP i386
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
#0 doadump () at pcpu.h:159
159 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) where
#0 doadump () at pcpu.h:159
#1 0xc0627d67 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc06280bd in panic (fmt=0xc08275a2 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
#3 0xc07deb14 in trap_fatal (frame=0xe4d73c5c, eva=2883669) at
/usr/src/sys/i386/i386/trap.c:809
#4 0xc07de847 in trap_pfault (frame=0xe4d73c5c, usermode=0, eva=2883669) at
/usr/src/sys/i386/i386/trap.c:727
#5 0xc07de45d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1017036800, tf_esi =
-1008433408, tf_ebp = -455656272, tf_isp = -455656312, tf_ebx = 2883655, tf_edx
= 32, tf_ecx = 2883653, tf_eax = 2014, tf_trapno = 12, tf_err = 2, tf_eip =
-1068330083, tf_cs = 8, tf_eflags = 66054, tf_esp = 2, tf_ss = -455671807}) at
/usr/src/sys/i386/i386/trap.c:417
#6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0x0018 in ?? ()
#8 0x0010 in ?? ()
#9 0x0010 in ?? ()
#10 0xc3614000 in ?? ()
#11 0xc3e48700 in ?? ()
#12 0xe4d73cb0 in ?? ()
#13 0xe4d73c88 in ?? ()
#14 0x002c0047 in ?? ()
#15 0x0020 in ?? ()
#16 0x002c0045 in ?? ()
#17 0x07de in ?? ()
#18 0x000c in ?? ()
#19 0x0002 in ?? ()
#20 0xc052939d in fxp_add_rfabuf (sc=0xc3614000, rxp=0xc3614610) at
/usr/src/sys/dev/fxp/if_fxp.c:2288
#21 0xc05285ec in fxp_intr_body (sc=0xc3614000, ifp=0xc3614000, statack=16
'\020', count=-1) at /usr/src/sys/dev/fxp/if_fxp.c:1682
#22 0xc05283d0 in fxp_intr (xsc=0xc3614000) at
/usr/src/sys/dev/fxp/if_fxp.c:1555
#23 0xc0613d11 in ithread_loop (arg=0xc34f2600) at
/usr/src/sys/kern/kern_intr.c:547
#24 0xc0612dad in fork_exit (callout=0xc0613bb8 ithread_loop, arg=0xc34f2600,
frame=0xe4d73d48) at /usr/src/sys/kern/kern_fork.c:790
#25 0xc07ccd1c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
#0 doadump () at pcpu.h:159
#1 0xc0627d67 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc06280bd in panic (fmt=0xc08275a2 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
#3 0xc07deb14 in trap_fatal (frame=0xe4d73bb4, eva=3217033792) at
/usr/src/sys/i386/i386/trap.c:809
#4 0xc07de847 in trap_pfault (frame=0xe4d73bb4, usermode=0, eva=3217033792) at
/usr/src/sys/i386/i386/trap.c:727
#5 0xc07de45d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 32, tf_esi = -1017067520,
tf_ebp = -455656364, tf_isp = -455656480, tf_ebx = 0, tf_edx = 0, tf_ecx =
2686976, tf_eax = 656, tf_trapno = 12, tf_err = 0, tf_eip = -1065570907, tf_cs
= 8, tf_eflags = 66070, tf_esp = -1064291104, tf_ss = 2689093}) at
/usr/src/sys/i386/i386/trap.c:417
#6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0x0018 in ?? ()
#8 0x0010 in ?? ()
#9 0x0010 in ?? ()
#10 0x0020 in ?? ()
#11 0xc360c800 in ?? ()
#12 0xe4d73c54 in ?? ()
#13 0xe4d73be0 in ?? ()
#14 0x in ?? ()
#15 0x in ?? ()
#16 0x0029 in ?? ()
#17 0x0290 in ?? ()
#18 0x000c in ?? ()
#19 0x in ?? ()
#20 0xc07cada5 in bus_dmamap_load_mbuf (dmat=0xc35d8e00, map=0xc3623340,
m0=0xc3b2ad00, callback=0xc058f4b8 re_dma_map_desc, callback_arg=0xe4d73c80,
flags=1) at pmap.h:200
#21 0xc058ffe3 in re_newbuf (sc=0xc360c800, idx=32, m=0xc3b2ad00) at
/usr/src/sys/dev/re/if_re.c:1403
#22 0xc05902f9 in re_rxeof (sc=0xc360c800) at /usr/src/sys/dev/re/if_re.c:1588
#23 0xc0590811 in re_intr (arg=0xc360c800) at /usr/src/sys/dev/re/if_re.c:1860
#24 0xc0613d11 in ithread_loop (arg=0xc34f2600) at
/usr/src/sys/kern/kern_intr.c:547
#25 0xc0612dad in fork_exit (callout=0xc0613bb8 ithread_loop, arg=0xc34f2600,
frame=0xe4d73d48) at /usr/src/sys/kern/kern_fork.c:790
#26 0xc07ccd1c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
#0 doadump () at pcpu.h:159
#1 0xc0627d67 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc06280bd in panic (fmt=0xc08275a2 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
#3 0xc07deb14 in trap_fatal (frame=0xe4d73c5c, eva=5177429) at
/usr/src/sys/i386/i386/trap.c:809
#4
Re: organization
The biggest problem is keeping history here. Doing something like that with CVS is a major PITA. We didn't have any old release, so moving the repository files didn't create a problem. That's impossible in FreeBSD land :) wasnt here some discussion about moving FreeBSD to subversion (as some other projects did - samba, mono etc.)? and subversion solves this... roman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interrupt Service Routines
On Tue, 29 Mar 2005 19:48, Ashwin Chandra wrote: Do you guys know of any example code of ISR's in the kernel? Most of the drivers in the kernel? Look for intr in /usr/src/sys/dev/*/*.c eg line 1507 of /usr/src/sys/dev/fxp/if_fxp.c -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpfhFNLyS6hT.pgp Description: PGP signature
Re: organization
guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . if ls the files in freebsd sys subdir , u will got about 54 subdirs and a makefile while linux contains about 15 subdirs only. guys, don't take my words against bsd , i admit that the performace of bsd is much better than linux and i'm planning to change to it as my primary os. but we can get the good things from linux and through out the bad ones. On Mon, 28 Mar 2005 18:39:14 -0300, Patrick Tracanelli [EMAIL PROTECTED] wrote: Hey there Mohamed, hello. I did not take it as a flame war initiative nor reason for such a thing. This kind of consideration is good to make people think about some points which are rarerely discussed. I personally disagree w/ you but it is also my very personal opinion. Anyway, this is not the reason I am emailing you now. You reply came to me only, since the list does not change the reply-to header you should retype the address or Reply All. I think your points should go on the list, so resend it there if it is the case. I am considering you really intended to reply to the list. If its not the case and you wanted to reply only to me, do not consider this message. Thanks, Bye :-) mohamed aslan wrote: guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . if ls the files in freebsd sys subdir , u will got about 54 subdirs and a makefile while linux contains about 15 subdirs only. guys, don't take my words against bsd , i admit that the performace of bsd is much better than linux and i'm planning to change to it as my primary os. but we can get the good things from linux and through out the bad ones. On Mon, 28 Mar 2005 16:26:12 -0300, Patrick Tracanelli [EMAIL PROTECTED] wrote: Maybe you are just more familiar to Linux kernel. I am not a kernel hacker, like you and many people here. But I usually read source codes, FreeBSD and also NetBSD and Linux, specially the areas where I am a particular curious. FreeBSD code organization is close to BSD's roots (you can get those Walnut Creek historical CDROM which has code for 4BSD and 386BSD to compare). I like FreeBSD orgaization better. Maybe you will disagree it for a thousand years, or one day find NetBSD approach better than both. In any case I am sure spending more time under FreeBSD's src/ won't make the organization such a deal that deserves this comment. mohamed aslan wrote: hi guys it's my first post here, BTW i was a linux hacker and linux kernel mailing list member for 3 years. and i've a comment here , i think the freebsd kernel source files aren't well organized as linux ones. -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) http://www.maslanlab.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
From: mohamed aslan [EMAIL PROTECTED] Subject: Re: organization Date: Tue, 29 Mar 2005 07:41:25 -0800 guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . The problem is getting consensus on what is to be done. Sure, one can arbitrarily say this goes here or that goes there, but everyone's notion of reorg is a little different. It would take a lot of time and energy to get this consensus, which is better spent making things work better... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
mohamed aslan wrote: guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . if ls the files in freebsd sys subdir , u will got about 54 subdirs and a makefile while linux contains about 15 subdirs only. guys, don't take my words against bsd , i admit that the performace of bsd is much better than linux and i'm planning to change to it as my primary os. but we can get the good things from linux and through out the bad ones. Have you ever thought that time is better spent on engineering rather than silly dicussions of 'facts' like yours? I really don't give a hoot what Linux's layout is, nor whether you think that changing FreeBSD to be more like it is a trivial task. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
Warner Losh wrote: From: mohamed aslan [EMAIL PROTECTED] Subject: Re: organization Date: Tue, 29 Mar 2005 07:41:25 -0800 guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . The problem is getting consensus on what is to be done. Sure, one can arbitrarily say this goes here or that goes there, but everyone's notion of reorg is a little different. It would take a lot of time and energy to get this consensus, which is better spent making things work better... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] And the worts of all is that You are both right to some extent. The new developers want the source tree arranged in the way mohamed says it should be. Not some device drivers live in pci/ other in dev/ and things like that. And on the other hand experienced kernel hackers who want things to stay as they are so it is easy for them to navigate in know waters. IMHO mohamed is a bit more right. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
Iasen Kostov wrote: Warner Losh wrote: From: mohamed aslan [EMAIL PROTECTED] Subject: Re: organization Date: Tue, 29 Mar 2005 07:41:25 -0800 guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . The problem is getting consensus on what is to be done. Sure, one can arbitrarily say this goes here or that goes there, but everyone's notion of reorg is a little different. It would take a lot of time and energy to get this consensus, which is better spent making things work better... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] And the worts of all is that You are both right to some extent. The new developers want the source tree arranged in the way mohamed says it should be. Not some device drivers live in pci/ other in dev/ and things like that. And on the other hand experienced kernel hackers who want things to stay as they are so it is easy for them to navigate in know waters. IMHO mohamed is a bit more right. What do you think the reaction would be if you or Mr. Aslan trotted over to the linux kernel hackers list and told them that they were all 'wrong' for piling all of the storage drivers into linux/drivers/scsi instead of separating them out into subdirectories? What do you think the reaction would be if you told Theo DeRadt that OpenBSD is 'wrong' for piling dozens of drivers into sys/dev/ic instead of separating them out more logically? At best, you'd be ignored. Telling a group that they are right or wrong based on your personal opinion of how the world should be is, um, a waste of time. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
On Tue, Mar 29, 2005, Warner Losh wrote: From: mohamed aslan [EMAIL PROTECTED] Subject: Re: organization Date: Tue, 29 Mar 2005 07:41:25 -0800 guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . The problem is getting consensus on what is to be done. Sure, one can arbitrarily say this goes here or that goes there, but everyone's notion of reorg is a little different. It would take a lot of time and energy to get this consensus, which is better spent making things work better... I think few people would disagree with certain changes, like putting MD bits in subdirectories called 'arch' as in NetBSD. The real question is whether people care enough to justify the repo bloat and the extra load on the cvsup mirrors. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
At 7:41 AM -0800 3/29/05, mohamed aslan wrote: guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . One thing to watch out for is the mess this would cause in the CVS repository. CVS does not track file moves, so if we move a lot of things around then we just end up with them in *both* the old and the new locations. I certainly believe the tree could be organized better than it is, but the benefits from reorganizing are just not worth the time and effort it would take (*), and the mess it would make out of the CVS repository. (* - 99% of the time and effort would be in getting everyone to *agree* on the best layout...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [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: organization
In message: [EMAIL PROTECTED] David Schultz [EMAIL PROTECTED] writes: : On Tue, Mar 29, 2005, Warner Losh wrote: : From: mohamed aslan [EMAIL PROTECTED] : Subject: Re: organization : Date: Tue, 29 Mar 2005 07:41:25 -0800 : : guys this is not a flame war : but the linux way in arranging the source file is really better than : freebsd way, it's a fact. : however it's easy to rearrange it in 1 min as someone said before. : but i mean this step should be done from the core team. : for example all fs has to go in a subdir called fs : arch specific file should go in subdir called arch/(arch name) : and so on . : : The problem is getting consensus on what is to be done. Sure, one can : arbitrarily say this goes here or that goes there, but everyone's : notion of reorg is a little different. It would take a lot of time : and energy to get this consensus, which is better spent making things : work better... : : I think few people would disagree with certain changes, like : putting MD bits in subdirectories called 'arch' as in NetBSD. The : real question is whether people care enough to justify the repo : bloat and the extra load on the cvsup mirrors. You've proven my point exactly: Some folks want to see i386 moved to arch/i386, others think it is stupid to do that. Discussion isn't possible here, so nothing will happen since there's no compelling reason to do anything, just a weak argument about how things might be nicer. The fact that we even consider cvsup load when discussing this means that clearly it is a weak idea: if we have to worry about the impact on how we distribute the sources for a change, isn't that really a weird criteria to use? Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
[EMAIL PROTECTED] wrote: And the worts of all is that You are both right to some extent. The new developers want the source tree arranged in the way mohamed says it should be. Not some device drivers live in pci/ other in dev/ and things like that. And on the other hand experienced kernel hackers who want things to stay as they are so it is easy for them to navigate in know waters. IMHO mohamed is a bit more right. If you are really dedicated to studying the kernel sources at that level issues such as learning the layout are really nonissues, the time a new developer initially spends hunting around for files because they are not familiar with the layout is insignificant compared to the time experienced developers would lose as a result of a new layout being introduced, especially during a critical development stage. Once all the major changes are finished and we move to micro optimization a new, more consistent and logical layout would be an option, but until then, IMHO, things should stay the way they are. Also, the benefit of such a reorganization at this time does not justify the work needed to make it happen. It Would Be Nice (TM), but it's not practical. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ 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
On Tue, 29 Mar 2005 21:11:07 +1000, Peter Jeremy [EMAIL PROTECTED] 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? Actually I don't remember precisely what came of it, but I do remember that we had some interesting stability issues while Matt worked out some bugs around that time, I think they were related to the SIMD stuff. 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. Yes, you'd have to have a fairly smart copy to know when to avoid the setup overhead. Apple's bcopy stuff does a lot of checking if I recall. It's been a while since I've looked at that either. [the stuff that's mapped into the COMM_PAGE of Mac OS X 10.3.x processes] Dave -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
In message: [EMAIL PROTECTED] Divacky Roman [EMAIL PROTECTED] writes: : The biggest problem is keeping history here. Doing something like that : with CVS is a major PITA. We didn't have any old release, so moving : the repository files didn't create a problem. That's impossible in : FreeBSD land :) : : wasnt here some discussion about moving FreeBSD to subversion (as some other : projects did - samba, mono etc.)? and subversion solves this... Subversion was deemed to be insufficiently mature for FreeBSD last time it was evaluated formally. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
On Tue, Mar 29, 2005, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David Schultz [EMAIL PROTECTED] writes: : On Tue, Mar 29, 2005, Warner Losh wrote: : From: mohamed aslan [EMAIL PROTECTED] : Subject: Re: organization : Date: Tue, 29 Mar 2005 07:41:25 -0800 : : guys this is not a flame war : but the linux way in arranging the source file is really better than : freebsd way, it's a fact. : however it's easy to rearrange it in 1 min as someone said before. : but i mean this step should be done from the core team. : for example all fs has to go in a subdir called fs : arch specific file should go in subdir called arch/(arch name) : and so on . : : The problem is getting consensus on what is to be done. Sure, one can : arbitrarily say this goes here or that goes there, but everyone's : notion of reorg is a little different. It would take a lot of time : and energy to get this consensus, which is better spent making things : work better... : : I think few people would disagree with certain changes, like : putting MD bits in subdirectories called 'arch' as in NetBSD. The : real question is whether people care enough to justify the repo : bloat and the extra load on the cvsup mirrors. You've proven my point exactly: Some folks want to see i386 moved to arch/i386, others think it is stupid to do that. Discussion isn't possible here, so nothing will happen since there's no compelling reason to do anything, just a weak argument about how things might be nicer. The fact that we even consider cvsup load when discussing this means that clearly it is a weak idea: if we have to worry about the impact on how we distribute the sources for a change, isn't that really a weird criteria to use? Indeed, both the pro and con arguments are weak, which is probably why nothing has happened. I for one would love to see libm called libm and not msun, for instance, but when it comes down to it, I have better things to do. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
On Tue, Mar 29, 2005 at 05:05:38PM +0200, Divacky Roman wrote: wasnt here some discussion about moving FreeBSD to subversion (as some other projects did - samba, mono etc.)? and subversion solves this... Yes, a few people have looked at it from time to time (raises hand as one of the guilty parties). The last I heard, subversion did not scale well to the massive amount of files that are in the FreeBSD repository. IIRC it's been a while since this was tested, so it may or may not be true anymore. SVK may partially address this by bypassing libwc. Also, repository size is a big issue (no pun intended). If adding a few hundred megs for repo-copies is prohibitively expensive, I don't think increasing the repo size by many gigabytes would go over very well. Subversion repositories can easily be several times the size of a CVS repository containing the same data. Craig ___ 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.3R SMP Kernel not detecting 2nd CPU in a HP DL360(?)
On 28 Mar 2005, at 23:52, Ulf Zimmermann wrote: On Mon, Mar 28, 2005 at 05:48:55PM -0500, John Baldwin wrote: It's not finding an APIC table (either MPTable or MADT) at all, and it needs that to find CPUs. See if there are any BIOS options for things like MP Table or 'Separate APIC Table' under ACPI. Also, try running 'mptable' to see if it finds a table, and acpidump -t to see if that finds an APIC table. The DL380 g3 BIOS has different APIC settings for different OS. There is one setting in the main menu and then under advanced options is another menu for APIC. Happy to report the box is now up and running with 2 CPUs. There was indeed a BIOS setting along the lines of APIC 'Full Table' which was not the default. HTT was disabled which is why there are 2 not 4 CPUs Unfortunately the ISP's engineer also flashed the BIOS to the latest release at the same time so that may also have had an effect. Thanks for the help. greg. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
[EMAIL PROTECTED] wrote: You've proven my point exactly: Some folks want to see i386 moved to arch/i386, others think it is stupid to do that. Discussion isn't possible here, so nothing will happen since there's no compelling reason to do anything, just a weak argument about how things might be nicer. If such a layout change were to happen I think the least time wasting procedure would go something like this: - issue a request for new layout propositions - for a week accept proposition submissions (web based) - have the FreeBSD community vote on the proposed layouts (web based) - assign a deadline by which a decision has to be made and then discuss the most popular layouts and try to get the Core Team and the committers to reach a consensus No consensus, no change. In any case, a lot of time and energy would be spent discussing this change, it's more of a bike shed issue than some might think, it's just not worth even starting this process in the near future. The fact that we even consider cvsup load when discussing this means that clearly it is a weak idea: if we have to worry about the impact on how we distribute the sources for a change, isn't that really a weird criteria to use? It does not prove that the idea itself is weak, it's a criterion that proves that CVS is not well suited to such changes. The thing is that even if such a change would be trivial to implement with no additional overhead, the process of deciding which new layout to adopt would take too much time and energy compared to the benefits gained by adopting a new layout, at least at this stage of development. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
System Panic (Trap 12)
Greets,
I am getting numerous panics. It seems to be totally random with no
bearing on load. This is a dual proc. AMD 2600, 2 GB Ram.
I have included the where results of three seperate core files.
Please advise.
Thanks in advance.
FreeBSD sbftp.sc.emaglink.com 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #7: Mon Mar
28 13:26:07 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SBFTP i386
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
#0 doadump () at pcpu.h:159
159 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) where
#0 doadump () at pcpu.h:159
#1 0xc0627d67 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc06280bd in panic (fmt=0xc08275a2 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
#3 0xc07deb14 in trap_fatal (frame=0xe4d73c5c, eva=2883669) at
/usr/src/sys/i386/i386/trap.c:809
#4 0xc07de847 in trap_pfault (frame=0xe4d73c5c, usermode=0, eva=2883669) at
/usr/src/sys/i386/i386/trap.c:727
#5 0xc07de45d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1017036800, tf_esi =
-1008433408, tf_ebp = -455656272, tf_isp = -455656312, tf_ebx = 2883655, tf_edx
= 32, tf_ecx = 2883653, tf_eax = 2014, tf_trapno = 12, tf_err = 2, tf_eip =
-1068330083, tf_cs = 8, tf_eflags = 66054, tf_esp = 2, tf_ss = -455671807}) at
/usr/src/sys/i386/i386/trap.c:417
#6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0x0018 in ?? ()
#8 0x0010 in ?? ()
#9 0x0010 in ?? ()
#10 0xc3614000 in ?? ()
#11 0xc3e48700 in ?? ()
#12 0xe4d73cb0 in ?? ()
#13 0xe4d73c88 in ?? ()
#14 0x002c0047 in ?? ()
#15 0x0020 in ?? ()
#16 0x002c0045 in ?? ()
#17 0x07de in ?? ()
#18 0x000c in ?? ()
#19 0x0002 in ?? ()
#20 0xc052939d in fxp_add_rfabuf (sc=0xc3614000, rxp=0xc3614610) at
/usr/src/sys/dev/fxp/if_fxp.c:2288
#21 0xc05285ec in fxp_intr_body (sc=0xc3614000, ifp=0xc3614000, statack=16
'\020', count=-1) at /usr/src/sys/dev/fxp/if_fxp.c:1682
#22 0xc05283d0 in fxp_intr (xsc=0xc3614000) at
/usr/src/sys/dev/fxp/if_fxp.c:1555
#23 0xc0613d11 in ithread_loop (arg=0xc34f2600) at
/usr/src/sys/kern/kern_intr.c:547
#24 0xc0612dad in fork_exit (callout=0xc0613bb8 ithread_loop, arg=0xc34f2600,
frame=0xe4d73d48) at /usr/src/sys/kern/kern_fork.c:790
#25 0xc07ccd1c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
#0 doadump () at pcpu.h:159
#1 0xc0627d67 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc06280bd in panic (fmt=0xc08275a2 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
#3 0xc07deb14 in trap_fatal (frame=0xe4d73bb4, eva=3217033792) at
/usr/src/sys/i386/i386/trap.c:809
#4 0xc07de847 in trap_pfault (frame=0xe4d73bb4, usermode=0, eva=3217033792) at
/usr/src/sys/i386/i386/trap.c:727
#5 0xc07de45d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 32, tf_esi = -1017067520,
tf_ebp = -455656364, tf_isp = -455656480, tf_ebx = 0, tf_edx = 0, tf_ecx =
2686976, tf_eax = 656, tf_trapno = 12, tf_err = 0, tf_eip = -1065570907, tf_cs
= 8, tf_eflags = 66070, tf_esp = -1064291104, tf_ss = 2689093}) at
/usr/src/sys/i386/i386/trap.c:417
#6 0xc07cccba in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0x0018 in ?? ()
#8 0x0010 in ?? ()
#9 0x0010 in ?? ()
#10 0x0020 in ?? ()
#11 0xc360c800 in ?? ()
#12 0xe4d73c54 in ?? ()
#13 0xe4d73be0 in ?? ()
#14 0x in ?? ()
#15 0x in ?? ()
#16 0x0029 in ?? ()
#17 0x0290 in ?? ()
#18 0x000c in ?? ()
#19 0x in ?? ()
#20 0xc07cada5 in bus_dmamap_load_mbuf (dmat=0xc35d8e00, map=0xc3623340,
m0=0xc3b2ad00, callback=0xc058f4b8 re_dma_map_desc, callback_arg=0xe4d73c80,
flags=1) at pmap.h:200
#21 0xc058ffe3 in re_newbuf (sc=0xc360c800, idx=32, m=0xc3b2ad00) at
/usr/src/sys/dev/re/if_re.c:1403
#22 0xc05902f9 in re_rxeof (sc=0xc360c800) at /usr/src/sys/dev/re/if_re.c:1588
#23 0xc0590811 in re_intr (arg=0xc360c800) at /usr/src/sys/dev/re/if_re.c:1860
#24 0xc0613d11 in ithread_loop (arg=0xc34f2600) at
/usr/src/sys/kern/kern_intr.c:547
#25 0xc0612dad in fork_exit (callout=0xc0613bb8 ithread_loop, arg=0xc34f2600,
frame=0xe4d73d48) at /usr/src/sys/kern/kern_fork.c:790
#26 0xc07ccd1c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
#0 doadump () at pcpu.h:159
#1 0xc0627d67 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc06280bd in panic (fmt=0xc08275a2 %s) at
/usr/src/sys/kern/kern_shutdown.c:566
#3 0xc07deb14 in trap_fatal (frame=0xe4d73c5c, eva=5177429) at
/usr/src/sys/i386/i386/trap.c:809
#4
A few thoughts..
Hey all, I've been using FreeBSD for a long time, it's my favorite OS and I use it on all my servers and most workstations. However, due to the nature of some of the servers, I've always wondered about something, tho. It is related to something deep in the OS. Let me try to explain. For example, assume a shell server. There are permission restrictions everywhere, to avoid users from seeing information that should be available only to the administrator (ie: dmesg,systat, vmstat, and so on). One could assume users won't be able to access the information provided by these utilities. Please consider the following example: [EMAIL PROTECTED]:/home/UNAME/] sftp [EMAIL PROTECTED] Connecting to 192.168.0.254... -- lan gateway -- [EMAIL PROTECTED]'s password: sftp put /sbin/dmesg dmesg 100% 5392 122.4KB/s 00:00 sftp quit [EMAIL PROTECTED]:/home/UNAME/] ssh [EMAIL PROTECTED] -- lan gateway -- [EMAIL PROTECTED]'s password: Last login: Tue Mar 29 19:36:42 2005 from WORKSTATION Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD ?.?.? (UNKNOWN) Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/. If the doc distribution has been installed, they're also available formatted in /usr/share/doc. If you still have a question or problem, please take the output of `uname -a', along with any relevant error messages, and email it as a question to the [EMAIL PROTECTED] mailing list. If you are unfamiliar with FreeBSD's directory layout, please refer to the hier(7) manual page. If you are not familiar with manual pages, type `man man'. You may also use sysinstall(8) to re-enter the installation and configuration utility. Edit /etc/motd to change this login announcement. man tuning gives some tips how to tune performance of your FreeBSD system. -- David Scheidt [EMAIL PROTECTED] [EMAIL PROTECTED]:/home/USERNAME]$ ./dmesg Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #1: Wed Dec 15 20:18:13 WET 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/??? Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium/P55C (199.31-MHz 586-class CPU) Origin = GenuineIntel Id = 0x544 Stepping = 4 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 83886080 (80 MB) avail memory = 72318976 (68 MB) (changed hostnames/logins - 192.168.0.254 is a host on my lan) My USERNAME account doesn't have access to /sbin/dmesg, but I uploaded a /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could have access to this system information. The same goes for systat , vmstat, and all these commands that (most people think) shouldn't be available for regular users. Shouldn't this information be protected at kernel level? Am I missing something I can do about this ? Because this method works with everything that ressembles permissions in order to hide system information that can be obtained without root privileges. Another thought, one can use the logger utility to write to some logfile that is accessible via syslogd. example: [EMAIL PROTECTED]:/home/UNAME/] logger -t su: evilone to root on/dev/ttyp0 # tail /var/log/messages Mar 29 20:14:11 WORKSTATION su:: evilone to root on/dev/ttyp0 If you can't trust your logs.. This also poses another problem, with a little patience, one can fill up /var. Lastly, anyone knows if FreeBSD is getting systrace support ? I think of it as a major drawback in the security field, one can do very interesting things with systrace. Added with other freebsd features (jails, etc), it makes a very good security tool. Any comments appreciated! Regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
mohamed aslan wrote this message on Tue, Mar 29, 2005 at 07:41 -0800: Also, learn not to top post... it looses context... guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. well, as I stated in a previous email, if you make a statement without detailing your reasons, many people feel that you are attacking FreeBSD.. You should be impressed that you didn't get more flames... however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. No, this step should only be done by the repo manager... and let the people who have extensive experience handle it.. in some cases, it means that we'll have to keep two copies of the files for a long time so that all branches are properly buildable, or we'll have to go back and change all the old branches to make sure they use the new location.. That's a large undertaking... for example all fs has to go in a subdir called fs well, not even NetBSD does this, and they are better organized than FreeBSD is... but luckily, you can just do ls -d *fs and get them... Though the reasons that ufs and nfs and isofs aren't in the fs is hysterical raisins... It's been a while since I looked at this, but I was surprised how many were in the fs dir.. so, this is more of a minor point.. arch specific file should go in subdir called arch/(arch name) and so on . if ls the files in freebsd sys subdir , u will got about 54 subdirs and a makefile while linux contains about 15 subdirs only. Again, FreeBSD was originally only i386 (and pc64), and for a long time, only a two arch project.. it wasn't till a few years ago that we started to grow many new arches (amd64, ia64, sparc64, powerpc, arm, and others).. So, at the time, putting i386 (and pc98 and alpha) at the top level made sense, but now that we have so many, yes, it doesn't make sense, but at the same time the cost (as others have layed out) is expensive to do Also, as time permits, such as when new drivers are written, old drivers retires, drivers rewritten, things are improving... such as the dev dir, instead of putting the drivers in isa, they are moved into dev.. one example is sio.c.. that used to be an isa device driver, but now lives in dev/sio + the various bus attachments since it is no longer isa specific... guys, don't take my words against bsd , i admit that the performace of bsd is much better than linux and i'm planning to change to it as my primary os. but we can get the good things from linux and through out the bad ones. Or at least the ideas.. :) we can't take in too much GPL code into the tree.. then it'd just be pointless... :) -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few thoughts..
On Tue, 29 Mar 2005 13:19:06 -0600 (CST) H. S. [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:/home/USERNAME]$ ./dmesg Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [...] real memory = 83886080 (80 MB) avail memory = 72318976 (68 MB) My USERNAME account doesn't have access to /sbin/dmesg, but I uploaded a /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could have access to this system information. The same goes for systat , vmstat, and all these commands that (most people think) shouldn't be available for regular users. If you don't want users to run random binaries put /home and /tmp on their own partitions and mount them noexec. Also note that users can still read that info by accessing /var/log/messages and /var/run/ dmesg.boot Shouldn't this information be protected at kernel level? Am I missing something I can do about this ? Because this method works with everything that ressembles permissions in order to hide system information that can be obtained without root privileges. Sounds like security through obscurity to me. If you don't trust your shell users put them in a jail, where any bad behaviour can be contained. If you can't trust your logs.. This also poses another problem, with a little patience, one can fill up /var. Lastly, anyone knows if FreeBSD is getting systrace support ? I think of it as a major drawback in the security field, one can do very interesting things with systrace. Added with other freebsd features (jails, etc), it makes a very good security tool. Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but you can achieve similar results. Cheers, -- Miguel Mendez [EMAIL PROTECTED] http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 pgpW5jKdzsD4P.pgp Description: PGP signature
Re: FreeBSD on Bochs
On Tue, Mar 29, 2005 at 05:57:23PM +0800, jumbler chi wrote: Hi All: I have a question about Freebsd on bochs. I'm interesting to build owner Freebsd scratch. Due the hardware limited , I want to run this scratch on Bochs. Therefore , I refered a article , http://sig9.com/articles/freebsd-on-bochs , to build a image under 5.2R. when I booted the image file under Bochs-2.0.2 .. it stoped on a prompt , mountroot . This doesn't address you're question directly, but I'd like to point out that I've had very good luck with FreeBSD under qemu, and it feels much faster than Bochs did. Regards Jumbler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Brian Reichert [EMAIL PROTECTED] 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
On Tue, 29 Mar 2005 12:17:53 -0500 David Schultz [EMAIL PROTECTED] wrote: On Tue, Mar 29, 2005, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David Schultz [EMAIL PROTECTED] writes: : On Tue, Mar 29, 2005, Warner Losh wrote: : From: mohamed aslan [EMAIL PROTECTED] : Subject: Re: organization : Date: Tue, 29 Mar 2005 07:41:25 -0800 : : guys this is not a flame war : but the linux way in arranging the source file is really better than : freebsd way, it's a fact. : however it's easy to rearrange it in 1 min as someone said before. : but i mean this step should be done from the core team. : for example all fs has to go in a subdir called fs : arch specific file should go in subdir called arch/(arch name) : and so on . : : The problem is getting consensus on what is to be done. Sure, one can : arbitrarily say this goes here or that goes there, but everyone's : notion of reorg is a little different. It would take a lot of time : and energy to get this consensus, which is better spent making things : work better... : : I think few people would disagree with certain changes, like : putting MD bits in subdirectories called 'arch' as in NetBSD. The : real question is whether people care enough to justify the repo : bloat and the extra load on the cvsup mirrors. You've proven my point exactly: Some folks want to see i386 moved to arch/i386, others think it is stupid to do that. Discussion isn't possible here, so nothing will happen since there's no compelling reason to do anything, just a weak argument about how things might be nicer. The fact that we even consider cvsup load when discussing this means that clearly it is a weak idea: if we have to worry about the impact on how we distribute the sources for a change, isn't that really a weird criteria to use? Indeed, both the pro and con arguments are weak, which is probably why nothing has happened. I for one would love to see libm called libm and not msun, for instance, but when it comes down to it, I have better things to do. Equivalent (or nearly equivalent) gains could probably be made by simply documenting the current layout better. Also, that's the sort of project that someone like Mohamed could undertake with minimal contention from the rest of the project. -Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few thoughts..
On Tue, 29 Mar 2005 13:19:06 -0600 (CST) H. S. [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:/home/USERNAME]$ ./dmesg Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [...] real memory = 83886080 (80 MB) avail memory = 72318976 (68 MB) My USERNAME account doesn't have access to /sbin/dmesg, but I uploaded a /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could have access to this system information. The same goes for systat , vmstat, and all these commands that (most people think) shouldn't be available for regular users. If you don't want users to run random binaries put /home and /tmp on their own partitions and mount them noexec. Also note that users can still read that info by accessing /var/log/messages and /var/run/ dmesg.boot I do want them to run random binaries, such as psybncs, eggdrops, shoutcast servers, etc. Mounting /home noexec isn't an option, /tmp is noexec tho. Shouldn't this information be protected at kernel level? Am I missing something I can do about this ? Because this method works with everything that ressembles permissions in order to hide system information that can be obtained without root privileges. Sounds like security through obscurity to me. If you don't trust your shell users put them in a jail, where any bad behaviour can be contained. They need multiple IPs, and there are lots of users. Creating a jail for each user is not pratical in any mean (firewall rules, number of jails, disk space, to name a few). The ideal would be only root accessing this information, so users would need a setuid binary in order to be able to see such stuff. And since only the administrator could set the setuid bit.. This could be compared to what was done in FreeBSD lately, I remember in 4.7 (and probably later, up to 4.10 I think) a user could see the full connection lists (even connections from other users), only later the kern.ps_showallprocs/security.bsd.see_other_uids took effect for these matters too. I don't know how hard would it be to implement this kind of information containment in the heart of the system, and it surely could lead to many discussing about what should be hidden from users and what shouldnt. Personally, I don't like the hability of having users checking the kernel message buffer, or seeing the vmstat / tcp statistics etc. If you can't trust your logs.. This also poses another problem, with a little patience, one can fill up /var. Lastly, anyone knows if FreeBSD is getting systrace support ? I think of it as a major drawback in the security field, one can do very interesting things with systrace. Added with other freebsd features (jails, etc), it makes a very good security tool. Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but you can achieve similar results. Systrace is much more complex than mac. Cheers, -- Miguel Mendez [EMAIL PROTECTED] http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
If memory serves me right, Craig Boston wrote:
On Tue, Mar 29, 2005 at 05:05:38PM +0200, Divacky Roman wrote:
wasnt here some discussion about moving FreeBSD to subversion (as some other
projects did - samba, mono etc.)? and subversion solves this...
Yes, a few people have looked at it from time to time (raises hand as
one of the guilty parties).
The last I heard, subversion did not scale well to the massive amount of
files that are in the FreeBSD repository. IIRC it's been a while since
this was tested, so it may or may not be true anymore. SVK may
partially address this by bypassing libwc.
Well, someone's part-way there with a Subversion mirror of src/. From
http://www.freebsd.org/support.html:
A public Subversion mirror of the FreeBSD src/ CVS repository is
provided at svn://svn.clkao.org/freebsd/. A web interface is also
available. This is intended for people who would like to try the svk
distributed version control system.
This of course doesn't include ports/ or doc/, so it doesn't really
answer the scalability question.
Also, repository size is a big issue (no pun intended). If adding a few
hundred megs for repo-copies is prohibitively expensive, I don't think
increasing the repo size by many gigabytes would go over very well.
Subversion repositories can easily be several times the size of a CVS
repository containing the same data.
This is dependent (among other things) on the nature of the files in the
repository and which repository back-end is used. I did a conversion at
${REALJOB} in December where I converted 1.3GB of CVS repository to
about 1.5GB in Subversion. For the curious, the back-end was FSFS, and
an earlier test conversion using the BDB back-end took about 2.1GB. I
know this is smaller than the FreeBSD repository.
I have this vague, handwavy feeling (colored no doubt by positive
experiences using it at ${REALJOB}) that Subversion, as well as the
conversion tool (cvs2svn) have matured a bit since the last time this
topic came up. But I'm not necessarily advocating a switch either.
Cheers,
Bruce.
signature.asc
Description: This is a digitally signed message part
Re: A few thoughts..
On Tue, Mar 29, 2005 at 03:12:25PM -0600, H. S. wrote: This could be compared to what was done in FreeBSD lately, I remember in 4.7 (and probably later, up to 4.10 I think) a user could see the full connection lists (even connections from other users), only later the kern.ps_showallprocs/security.bsd.see_other_uids took effect for these matters too. It needs time to implement and actually process such checks. Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but you can achieve similar results. Systrace is much more complex than mac. That's a good one! It's actually quite the reverse, MAC is much more powerful than systrace, simply because it operates on a different level. You can do all this kind of checks with a MAC policy, if something does not have the necessary hooks, complain to Robert Watson :) Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
On Tue, Mar 29, 2005 at 11:22:19AM -0600, Craig Boston wrote: The last I heard, subversion did not scale well to the massive amount of files that are in the FreeBSD repository. IIRC it's been a while since this was tested, so it may or may not be true anymore. SVK may partially address this by bypassing libwc. That's not true. There are two major problems with subversion, compared to CVS: - the size of the working copy is doubled (because of the local cache) - annotation is linear in the number of revisions (of a file?) The first can be work-arounded by using SVK, but often is also an advantage, because e.g. diff is a pure local operation which doesn't have to contact the server. The second is related to how subversion stores the data. There are some persons working on speeding it up by using a cache, but I'm not sure how far the work is. On the other hand, CVS definitely doesn't scale to large repositories too, just think about the time a cvs up or cvs tag needs. You can't make everything fast, it is a compromise between speed, disk space and not to forget atomarity. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
On Tue, Mar 29, 2005 at 01:25:19PM -0800, Bruce A. Mah wrote:
Well, someone's part-way there with a Subversion mirror of src/. From
http://www.freebsd.org/support.html:
A public Subversion mirror of the FreeBSD src/ CVS repository is
provided at svn://svn.clkao.org/freebsd/.
Ah, yes, I do remember Chia-liang Kao was working on a CVS -
Subversion bridge for use with svk. The ability to do incremental
updates, even if it's only one-way, is a big win on both sides of the
fence.
This of course doesn't include ports/ or doc/, so it doesn't really
answer the scalability question.
Most of what I ran into was just in src/. I hesitate to say anything
since it's been a long time and my memory is vague. ISTR a few simple
operations on a file at the top level were causing the entire tree to be
traversed. Unfortunately I don't remember exactly -- maybe it's time to
test it again...
One issue I do remember had to more do with apache and davsvn rather
than subversion itself. Attempting to cancel a long running operation
(say an accidental svn diff of the whole tree) would kill the frontend
but leave the backend churning away on the server, which would bog down
further requests (locking?), causing them to hang for a while, build up
requests, and make the situation worse.
I use subversion exclusively for my personal projects but none are big
enough that I've run into that problem again. It may well have been
fixed by now -- the version number has been creeping up while I wasn't
looking :)
This is dependent (among other things) on the nature of the files in
the repository and which repository back-end is used. I did a
conversion at ${REALJOB} in December where I converted 1.3GB of CVS
repository to about 1.5GB in Subversion. For the curious, the
back-end was FSFS, and an earlier test conversion using the BDB
back-end took about 2.1GB. I know this is smaller than the FreeBSD
repository.
Ah, I haven't played with FSFS yet. All my repositories are BDB that
have been upgraded and migrated from version 0.something.
Craig
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
On Tue, Mar 29, 2005 at 11:34:11PM +0200, Joerg Sonnenberger wrote: That's not true. There are two major problems with subversion, compared to CVS: - the size of the working copy is doubled (because of the local cache) - annotation is linear in the number of revisions (of a file?) Not trying to spread false information about Subversion -- I like it very much and use it for all my personal projects :) Just stating my opinion based on observations made while using it. The first can be work-arounded by using SVK, but often is also an advantage, because e.g. diff is a pure local operation which doesn't have to contact the server. Well, you don't have the extra working copy files, but you usually end up eating up at least as much space for your local repository mirror; unless you have a lot of working copies checked out. On the other hand, CVS definitely doesn't scale to large repositories too, just think about the time a cvs up or cvs tag needs. You can't make everything fast, it is a compromise between speed, disk space and not to forget atomarity. Keeping in mind that the tests I ran were back in the pre-1.0 days (right before 1.0 IIRC), Subversion was much faster on update, but significantly slower for checkout and diffs. Those operations scaled worse than O(n) as the repository grew. It would be interesting to run some more benchmarks (clkao's mirror eliminates much of the import hassle) and see how the latest subversion compares. Also, as Bruce reminded me, the new fsfs storage backend may have different characteristics that need to be taken into account. Of course Subversion fares much better on the atomicity issue, that's a given :) svk may be able to help too. I tried it for a while but eventually gave up because getting the perl bindings installed and working was a bit of a black art. Probably time to try the port again. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
If memory serves me right, Craig Boston wrote:
On Tue, Mar 29, 2005 at 01:25:19PM -0800, Bruce A. Mah wrote:
This of course doesn't include ports/ or doc/, so it doesn't really
answer the scalability question.
Most of what I ran into was just in src/. I hesitate to say anything
since it's been a long time and my memory is vague. ISTR a few simple
operations on a file at the top level were causing the entire tree to be
traversed. Unfortunately I don't remember exactly -- maybe it's time to
test it again...
I know what you mean...I was looking through my notes for more details
about our repository conversion and they were a little lacking. :-p
One issue I do remember had to more do with apache and davsvn rather
than subversion itself. Attempting to cancel a long running operation
(say an accidental svn diff of the whole tree) would kill the frontend
but leave the backend churning away on the server, which would bog down
further requests (locking?), causing them to hang for a while, build up
requests, and make the situation worse.
Sounds like a bad situation there. On our server we use svn+ssh, except
for a few Windows clients that use https. (BTW our server is running
4-STABLE and it's wonderful.)
I use subversion exclusively for my personal projects but none are big
enough that I've run into that problem again. It may well have been
fixed by now -- the version number has been creeping up while I wasn't
looking :)
Heh. :-) 1.1.3 is current now, but one can find mentions of a 1.1.4
bugfix release being planned, as well as the (farther out) 1.2 release
with locking.
This is dependent (among other things) on the nature of the files in
the repository and which repository back-end is used. I did a
conversion at ${REALJOB} in December where I converted 1.3GB of CVS
repository to about 1.5GB in Subversion. For the curious, the
back-end was FSFS, and an earlier test conversion using the BDB
back-end took about 2.1GB. I know this is smaller than the FreeBSD
repository.
Ah, I haven't played with FSFS yet. All my repositories are BDB that
have been upgraded and migrated from version 0.something.
While BDB worked well for us in testing, FSFS gave us the ability to do
incremental backups of the repository, which was important for getting
buy-in from my IT support group. I was a little nervous at using new
code for the backend but it's had nary a hiccup. (Knock on wood.)
As you probably know, a number of people have reported lockups with the
BDB backend...it turns out to be more problems with the way that
Subversion uses BDB, as well as people just not setting it up correctly.
Bruce.
signature.asc
Description: This is a digitally signed message part
Re: A few thoughts..
On Tue, Mar 29, 2005 at 03:12:25PM -0600, H. S. wrote: This could be compared to what was done in FreeBSD lately, I remember in 4.7 (and probably later, up to 4.10 I think) a user could see the full connection lists (even connections from other users), only later the kern.ps_showallprocs/security.bsd.see_other_uids took effect for these matters too. It needs time to implement and actually process such checks. I understand, and can only congratulate the freebsd developers for the nice programming you've all gotten us used to. I can't code C enough to be able to do anything really complex, however I do have a noction of how much effort is put into stuff like this. Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but you can achieve similar results. Systrace is much more complex than mac. That's a good one! It's actually quite the reverse, MAC is much more powerful than systrace, simply because it operates on a different level. You can do all this kind of checks with a MAC policy, if something does not have the necessary hooks, complain to Robert Watson :) Joerg Hmm, I'll furthen my MAC knowledge then :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [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: organization
At the risk of going further and further off-topic from freebsd-hackers... On Tue, Mar 29, 2005 at 02:29:13PM -0800, Bruce A. Mah wrote: Sounds like a bad situation there. On our server we use svn+ssh, except for a few Windows clients that use https. (BTW our server is running 4-STABLE and it's wonderful.) Hmmm, I initially didn't want to use that because I read that it suffers from the same security issues as CVS. The appeal of being able to fine-tune permissions and grant subversion access without shell access is quite luring. HTTP timeouts during long operations, on the other hand, suck. ( my server is woefully underpowered :-D ). Note to davsvn users with slow servers: http-timeout = 3600 is your friend. Heh. :-) 1.1.3 is current now, but one can find mentions of a 1.1.4 bugfix release being planned, as well as the (farther out) 1.2 release with locking. Oh, I've been running 1.1.3 on both client and server since it went into ports (many dump/loads later). Just haven't taken the time to see what's new and compare to older versions. :) Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Possible problems with mmap/munmap on FreeBSD ...
Hi,
I am having some problems with the tdb package on FreeBSD 4.6.2 and 4.10.
One of the things the above package does is:
mmap the tdb file to a region of memory
store stuff in the region (memmov etc).
when it needs to extend the size of the region {
munmap the region
write data at the end of the file
mmap the region again with a larger size
}
What I am seeing is that after the munmap the data written to the region
is gone.
However, if I insert an msync before the munmap, everything is nicely
coherent. This seems odd (in the sense that it works without the msync
under Linux).
The region is mmapped with:
mmap(NULL, tdb-map_size,
PROT_READ|(tdb-read_only? 0:PROT_WRITE),
MAP_SHARED|MAP_FILE, tdb-fd, 0);
What I notice is that all the calls to mmap return the same address.
A careful reading of the man pages for mmap and munmap does not suggest
that I am doing anything wrong.
Is it possible that FreeBSD is deferring flushing the dirty data, and then
forgets to do it when the same starting address is used etc?
Regards
-
Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few thoughts..
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 29 Mar 2005, H. S. wrote: If you don't want users to run random binaries put /home and /tmp on their own partitions and mount them noexec. Also note that users can still read that info by accessing /var/log/messages and /var/run/ dmesg.boot I do want them to run random binaries, such as psybncs, eggdrops, shoutcast servers, etc. Mounting /home noexec isn't an option, /tmp is noexec tho. On another hand, you could provide safe and secure system provided binaries that they would have to use instead of compiling their own. which would solve the case and ultimately when upgrading the package provided to them would upgrade all the users at once without you having to worry about insecurities being scattered throughout your system. Now I could see if this was a development server then you obviously would want to allow your users to do such a thing but since you mentioned things like psybnc, shoutcast, etc... the thought to me doesnt resemble a development server. So my suggestion would be provide the software they need on a as-is-basis and take requests and mount the user partition with the [noexec] option and tune sysctl and operate in a secure level + chmod/chflag the proper files and make 1 jail for the whole user based part of the system for all that to run out of. Best of luck, --c0ldbyte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSfZKsmFQuvffl58RAsw0AJkB6cLDGL4dsY9FAGrKZatn8+MotQCfeEX3 5R8zcR7nyVJQL1dgub0/nj0= =h8hs -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ABV.BG автоматичен отговор
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 30 Mar 2005 freebsd-hackers@freebsd.org wrote: blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! Can you guys at (Headquarters) turn the above auto reply off. By god it is not even readable. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F iD8DBQFCSfiSsmFQuvffl58RAiXnAJ4sGmLJGYFY26qED+wFtQqPFg124gCghCiQ 1phAaGNZACBRy4hkJ2aY1DI= =V5zw -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible problems with mmap/munmap on FreeBSD ...
On Tue, Mar 29, 2005, Richard Sharpe wrote:
Hi,
I am having some problems with the tdb package on FreeBSD 4.6.2 and 4.10.
One of the things the above package does is:
mmap the tdb file to a region of memory
store stuff in the region (memmov etc).
when it needs to extend the size of the region {
munmap the region
write data at the end of the file
mmap the region again with a larger size
}
What I am seeing is that after the munmap the data written to the region
is gone.
However, if I insert an msync before the munmap, everything is nicely
coherent. This seems odd (in the sense that it works without the msync
under Linux).
The region is mmapped with:
mmap(NULL, tdb-map_size,
PROT_READ|(tdb-read_only? 0:PROT_WRITE),
MAP_SHARED|MAP_FILE, tdb-fd, 0);
What I notice is that all the calls to mmap return the same address.
A careful reading of the man pages for mmap and munmap does not suggest
that I am doing anything wrong.
Is it possible that FreeBSD is deferring flushing the dirty data, and then
forgets to do it when the same starting address is used etc?
It looks like all of the underlying pages are getting invalidated
in vm_object_page_remove(). This is clearly the right thing to do
for private mappings, but it seems wrong for shared mappings.
Perhaps Alan has some insight.
___
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: ABV.BG автоматичен отговор
On Tue, Mar 29, 2005 at 07:53:34PM -0500, c0ldbyte wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 30 Mar 2005 freebsd-hackers@freebsd.org wrote: blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! Can you guys at (Headquarters) turn the above auto reply off. By god it is not even readable. There's pretty much nothing the guys at FreeBSD.org can do, except maybe find out which of the @abv.bg addresses subscribed to the lists generates this autoreply and unsubscribe it. ABV.BG is a widely-used Bulgarian free webmail service; apparently they have misconfigured their autoresponse setup very badly recently (including the faking of a sender address for no apparent reason at all), since I've seen similar complaints on several lists totally unrelated to FreeBSD.org. As to the response itself, it says 'thank you for the letter you sent; I'll respond as soon as possible'. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. pgpj4NUQOkBIG.pgp Description: PGP signature
