Re: suprising mount root behavior
> Some new root mount behavior in 4.0 just saved my bacon, but I'm curious > as to how it's implemented. 8) > My custom installer accidentally created fstab entries for IDE disks on a > SCSI-only system. Thus, fstab point to /dev/ad0s1a for / and /dev/ad0s1b > for swap. > > I rebooted the system to try and fix it, and lo and behold it booted up > correctly! I had no swap but root was mounted RW so I could fix the > fstab. > > Now my question is: How did it know? I'm not setting vfs.root.mountfrom > in the loader. > > Also, how did mount know to not override the / mountpoint to the one from > fstab (and subsequently fail)? There's a complex order of battle associated with mounting /. 8) You can read /sys/kern/vfs_conf.c:vfs_mountroot() and associated stuff to get the gory details, but the bottom line is that there are several layers of fallback, and you were saved by the one that looks at the major and minor numbers passed in by the bootloader and tries them if the fstab entry fails. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
suprising mount root behavior
Hello all, Some new root mount behavior in 4.0 just saved my bacon, but I'm curious as to how it's implemented. My custom installer accidentally created fstab entries for IDE disks on a SCSI-only system. Thus, fstab point to /dev/ad0s1a for / and /dev/ad0s1b for swap. I rebooted the system to try and fix it, and lo and behold it booted up correctly! I had no swap but root was mounted RW so I could fix the fstab. Now my question is: How did it know? I'm not setting vfs.root.mountfrom in the loader. Also, how did mount know to not override the / mountpoint to the one from fstab (and subsequently fail)? Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Specific video hardware support with the advent of the Linux A|W Maya port.
Recently, Alias|Wavefront announced they would port Maya to Linux. Assuming FreeBSD can emulate the linux binary's (and I have no reason to think that it won't) then what about support for video hardware (high, mid and consumer -end) which requires more than just a suitable X server? Take the case of Nvidia's linux drivers which are comprised of a kernel module which interfaces with the XFree86 4.0/4.0.1 driver also provided. I havn't looked into the drivers as I lack the knowledge and experience to even fathom porting to a freebsd kernel module. I understand there is an element of closed source with these drivers but i'm unsure whether this is at the module, or the XFree driver.. to cut to the chase, my question is whether the porting of a driver such as these is the onus of a FreeBSD contributer, or is it at Nvidia's discretion? Assuming the element of closed source works under FreeBSD, then how easy would a port like this be? Or is somebody working on this case [nvidia's 5.xx linux drivers for Xfree86 4.*] as I comment? On a wider scale, if a vendor provides a driver, or server for X and their hardware (lets say a particularly high end piece of equipment such as an Intergraph Wildcat) perhaps specifically with the intention for a Linux distrubtion which is to be packaged along with this Intergraph system, would it be reasonable to assume this would also work under FreeBSD or would the vendor be required to specifically write a version of their driver or server for FreeBSD? The reason I ask is that I see no reason why the growing field of animators using tools such as A|W Maya shouldn't opt to use FreeBSD over Linux (red hat at that) while they're on their way migrating from NT -- OR kicking off their endevours. What are (if any) the road blocks which could stop this from happening? -mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sysutils/memtest and FreeBSD
Hi, I just added sysutils/memtest to the FreeBSD ports tree a couple of days ago. It is a utility to test for faulty memory subsystem. However, I've been having some problems with it. They are not fatal, but really annoying. I am in contact with the author to try working them out. Nonetheless, I would like to see if ppl on the -hackers forum could help me out with the following problem: I noticed that using 'memtest all' would produce core dump on my -stable as of 18/07/2000. Backtracing showed that the problem was due to the malloc function inside the get_mem function. get_mem() is used to find out the largest possible memory segment. It incrementaly reduces the segment passed to malloc to alloc. It is the malloc function allright. It core dumps on the 1st pass on get_mem(), there is no time to do_reduce. Very weird. ;( #0 0x280dda41 in isatty () from /usr/lib/libc.so.4 #1 0x280ddd91 in isatty () from /usr/lib/libc.so.4 #2 0x280de4c5 in malloc () from /usr/lib/libc.so.4 #3 0x8049427 in get_mem () at memtest.c:338 #4 0x8048bc5 in main (argc=2, argv=0xbfbff62c) at memtest.c:175 #5 0x80488e1 in _start () Instead of just returning a null pointer, it core dumps. I am not using any /etc/malloc.conf options at all. I know that 'A' could produce this. Following some instructions from the author, I tried an odd change ... since that is his baby not mine. However, it did not work. On Thu, Jul 20, 2000 at 08:12:12PM -0600, Charles Cazabon wrote: > Mario Sergio Fujikawa Ferreira <[EMAIL PROTECTED]> wrote: > > Try changing line 103 to allocate a buffer of 256 bytes instead of 100 bytes. > I haven't looked at that line in a long time. The output messages may be > longer than that now. > > If that's not it, it's crashing during the memory allocation phase. I twould > take some additional debugging to figure out where. It did not work. 'memtest all' still core dumps. By the way, one bug that is not FreeBSD related though, whenever I try 'memtest 4G': --- ./memtest 4G memtest v. 2.93.1 (C) 2000 Charles Cazabon <[EMAIL PROTECTED]> Original v.1 (C) 1999 Simon Kirby <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ./memtest: amount of memory to allocate too small. --- Nonetheless, using 1G, 2G, 3G and 5G work. Just to mention. Don't worry about it. I am not touching the bit wise code now. I am leaving that to the author. I am worried about the core dump amongst other projects now. Regards, Mario Ferreira To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fwd: /etc/defaults/make.conf:LEAPSECONDS= true?
>Please remove To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Please Remove
Please remove [EMAIL PROTECTED], or [EMAIL PROTECTED] from you list.. Thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
/etc/defaults/make.conf:LEAPSECONDS= true?
Hi, I was wondering if this should go inside /etc/defaults/make.conf. --- /usr/src/etc/defaults/make.conf Sun Jul 16 05:30:30 2000 +++ /tmp/make.conf Fri Jul 21 18:42:35 2000 @@ -41,6 +41,9 @@ # To build perl with thread support #PERL_THREADED=true # +# Compile zoneinfo with correct leap second handling +#LEAPSECONDS= true +# # To avoid building various parts of the base system: #NO_CVS= true# do not build CVS #NO_BIND= true# do not build BIND If it does not, where in the handbook should I drop a note about it, besides FAQ (of course). Regards, Mario Ferreira To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel 840 Chipset Discontinue
> I was told by several of my distributors that all motherboards based off > of the Intel 840 chipset are being discontinued. That means the Supermicro > PIIDM3 and PIIIDME, and any other 840 board. I have mixed feelings about this, but on the whole I think it's probably for the best. I've had really patchy results with the i840, and performance hasn't been impressive. > Supermicro has two new boards, 370DL3 and 370DLE. Identical in specs to > the 840 boards, but using some kind of "ServerWork LE" chipset. However, I > have also been hearing bad news about these boards as well. We've had some issues with the RCC chipsets in Dell systems, yes. > Has anyone worked with these boards? Supermicro SAYS that they work fine > under Linux and Solaris. However, one of my distributors says thay they > are extremely touchy when it comes to memory. Only Registered PC133 ECC > memory will work. > > If someone at freebsd.org wants to seriously test these boards, let me > know, and I'll donate one. Without the 840 boards, server configs are now > back to the 440GX days! FreeBSD Test Labs would very much appreciate the opportunity to beat one of these boards up in the name of science. If you don't have a better taker, you can send us one at: FreeBSD Test Labs BSDi Open Source Solutions 4041 Pike Lane #F Concord, CA 94520 Thanks for the offer! -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Maybe OT, maybe not
On Tue, Jul 18, 2000 at 03:20:44PM -0700, Ulf Zimmermann wrote: > Hello, > > I got a problem I need to get "solved" as fast as possible. I have here > a firewall box (FreeBSD based, yeah!) and need to test this in conjunction > with web crawling. Our current FW1 based Sun firewalls die very fast. > > I need to emulate about 9,000 or more concurrent open tcp sessions. Each > session should be random sized from 500 to maybe 20,000 bytes data transferred. > In addition to these I need x amount of initiated tcp sessions which never > get answered. FW1 with its tcp connection table will create an entry for > these "failed" sessions and hold it up to its time out. Our crawlers do not. > > So I am basicly looking for a load generator and a "server". Anyone got > something laying around like that ? Ok, I got some suggestions, but let me the whole thing. What do I have to test ? I need to test the ability of the firewall, which keeps a session table, to handle several ten thousand entries. Why so many ? Our current crawlers will create 300 tcp session max. It will try to start a tcp session for a destination (tcp proctocol syn packet). The firewall will now create an entry in the session table. If the remote site never answers (not reachable, down, etc) the crawler will time out the tcp session after like 1 minute, but the firewall (because it never sees another packet) will not time it out before like 5 minutes (by default its even 30 minutes). So depending on how many dead sites we hit, we are having about 9,000 active tcp sessions (30 crawlers at 300 sessions a machine) plus several thousand to tenthousands of dead entries on the firewall. My current test scenario seems to run out to this: http servers (something light weight, serving files from memory, no logging) [firewall] load generator. The direction I am kinda thinking about the load generator is something like a main thread which spawns off maybe 2,000 threads (if I can do so many or maybe more), each thread using maybe libfetch to generate a http request to either a real server on the other side or by sending a request to a non existing ip to simulate dead sites. It then needs to timeout after lets say 30 seconds to leave the dead entry on the firewall. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD, kernel threads, zone allocator
On Mon, 17 Jul 2000, Zhihui Zhang wrote: > > I am writing a KLD that gives me kernel fault each time I run 'ps' command > after 'make unload'. The KLD has a system call to create several kernel > threads by calling kthread_create(). During unload, I set flags to each > threads so that they will call exit1() upon wakeup (sleep on a timeout). > Before the last thread calls exit1(), it wakeup the kld unload process so > that make 'unload' can finish. Is there anything wrong or better > solutions? > > I also use vm_zone to allocate some data structes within the KLD. When > unloading, I can use zfree() to free them except the zone header that I > can not free(some_zone, M_ZONE). This is because M_ZONE is defined as > *static* in vm_zone.c I wonder if this will cause memory leak after > several loading and unloading the KLD. > > Finally, I want to know how to save the panic screen without hand writing > it down. Any info on debugging under db> after fault? > > Any help is appreciated. Thanks to those who have helped me privately. It is not a good idea to use zone allocator with KLD. You must clear everything before unloading the KLD. Any kernel threads can be reparented to initproc to avoid 'ps' panic. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: memory type and its size
On Thu, 20 Jul 2000, Zhihui Zhang wrote: > > Does kernel memory of the same type (e.g., M_TEMP) must be allocated > (using malloc()) with the same (range of) size? BTW, how to display mbuf > cluster usages info. Thanks. A memory type can have memory blocks with different sizes. Use netstat -m to display mbuf cluster usages. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
Matt Dillon wrote: > > :Alan Cox wrote: > :> Last year, I tried to reproduce some of the claims/results > :> in this paper on FreeBSD/x86 and couldn't. I also tried > :> limiting the idle loop to clearing pages of one particular > :... > : > :> Finally, it's possible that having these pre-zeroed pages > :> in your L2 cache might be beneficial if they get allocated > :> and used right away. FreeBSD's idle loop zeroes the pages > :> that are next in line for allocation. > : > :That makes sense. Other factors that may have an impact: > : > : * if you always have enough zeroed pages remaining over your > :benchmark (> ~1/2 free pages), FreeBSD will never do the > :idle-time zeroing > : > : * it looks to me as if Cort's Linux code will always zero whole > :pages, while the FreeBSD code is a little smarter and only zeroes > :used regions of a page (less impact on caches?) > : > Since the only effect of a cache miss is less efficient use of > the cpu, and since the page zeroing only occurs when the cpu is idle, > I would not expect to see much improvement from attempts to refine > the page-zeroing operation (beyond the simple hysteresis that FreeBSD > uses now and perhaps being able to bypass the cache). The reason why I'm interested in Cort's results is that I'd like to extend processing in the idle loop to other things (see my other mail). Cort measured a performance decrease of foreground processing, due to polluted caches after idle-time processing. We're discussing if disabling caches during the idle loop may prevent that. > The real benefit occurs on a medium-to-heavily loaded machine which is > NOT cpu bound. Since nearly all page allocations require zero'd pages, > having a pool of pre-zero'd pages significantly reduces allocation > latency at just the time the process doing the allocation can best > benefit from it. In a cpu-bound system, the idle loop does not run > as often (or at all) and no pre-zeroing occurs anyway. I agree. However, on a medium-to-heavily loaded CPU, you'd probably see the largest decrease of foreground performance, as the idle times are short and bursty, and so your caches may get polluted more frequently. (Assuming cache pollution is in fact a problem; Allan seems to not think so.) If Allan still has his patches, I'll run some experiments, so we have some numbers to talk about. Maybe it doesn't matter. > In regards to just zeroing the pieces of a page that need zeroing - this > is NOT an optimization designed for the idle-loop page-zeroing code. I made a mistake tracing through the code. Sorry. But it may be interesting to speculate if this would speed things up. Would probably require MMU support though. Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel 840 Chipset Discontinue
:Apparently it affects all boards that the Intel 840 chipset. : :Yeah, it does suck that the 370DLx boards dont have AGP, but for a server :you can still find old PCI video cards. Voodoo 3 2000's (available for PCI or AGP) make great workstation video cards. About $100 and you get all the speed, resolution, and color depth you'll ever need for X short of playing hardcore games. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
:Alan Cox wrote: :> Last year, I tried to reproduce some of the claims/results :> in this paper on FreeBSD/x86 and couldn't. I also tried :> limiting the idle loop to clearing pages of one particular :... : :> Finally, it's possible that having these pre-zeroed pages :> in your L2 cache might be beneficial if they get allocated :> and used right away. FreeBSD's idle loop zeroes the pages :> that are next in line for allocation. : :That makes sense. Other factors that may have an impact: : : * if you always have enough zeroed pages remaining over your :benchmark (> ~1/2 free pages), FreeBSD will never do the :idle-time zeroing : : * it looks to me as if Cort's Linux code will always zero whole :pages, while the FreeBSD code is a little smarter and only zeroes :used regions of a page (less impact on caches?) : : * cache size differences between PPC and i386? : :I'm looking at Cort's code (arch/ppc/kernel/idle.c), and while he turns off :the caching for pages he zeroes, I don't see him disabling the L1/2 caches :... :Lars :-- :Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute Since the only effect of a cache miss is less efficient use of the cpu, and since the page zeroing only occurs when the cpu is idle, I would not expect to see much improvement from attempts to refine the page-zeroing operation (beyond the simple hysteresis that FreeBSD uses now and perhaps being able to bypass the cache). The hysteresis in the idle loop's page-zeroing effectively decouples the page-zeroing operation (and any loss of cache) from the processes benefiting from the availability of pre-zero'd pages. The real benefit occurs on a medium-to-heavily loaded machine which is NOT cpu bound. Since nearly all page allocations require zero'd pages, having a pool of pre-zero'd pages significantly reduces allocation latency at just the time the process doing the allocation can best benefit from it. In a cpu-bound system, the idle loop does not run as often (or at all) and no pre-zeroing occurs anyway. In regards to just zeroing the pieces of a page that need zeroing - this is NOT an optimization designed for the idle-loop page-zeroing code. I would not expect such an optimization to have any effect on idle-loop page zeroing performance. The partial-zeroing code is actually designed to handle filling in missing spots when a device-backed block (devices use a 512 byte base blocking factor) is mapped into memory (which requires a page-sized blocking factor). For example, when you map the end of a file and the file size is not page-aligned. The block device underlying the filesystem has a 512-byte native blocking factor and the filesystem itself (UFS) will typically have a 1K fragment blocking factor at the end of the file, which means that the physical disk I/O via the filesystem device may not cover an entire MMU page (4K for i386). The filesystem code doesn't give a damn whether the filesystem buffer it is reading the data into is zero'd beyond the EOF of the file. In fact, we don't even bother to zero that area... UNTIL that particular page is mapped by some user process. That is the point where the partial page-zeroing code comes into play. It has nothing to do with the idle loop pre-zeroing but since its a generic routine (part of the VM core), the idle loops happens to call it generically. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
Darn. I was hoping you had some mechanism for tracking that. Have you seen how quicklists work on Linux? They setup page directories after they've been freed so the whole things don't need to be cleared when allocated. I thought you could do something like that with page clearing instead if you had such a mechanism. } My mistake. FreeBSD zeroes the whole page as well. I traced through the } code incorrectly. Great, I'll take a look. Keep me up-to-date if you can, please. } I'm running FreeBSD-stable right now, though I may switch to -current if I } get promising results, to make it easier to merge. (There is a web } interface to the FreeBSD CVS tree at } http://www.freebsd.org/support.html#cvs). } } FYI, I'm interest in this for my thesis, which consists of two parts: (1) } utilizing idle resources (cpu, memory, disk/network I/O, disk/memory space) } for non-interfering background processing (i.e. run processes/threads using } *only* idle capacities); and (2) to use that mechanism for speculative } techniques. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
[EMAIL PROTECTED] wrote: > We started losing performance with the idle page clearing so > I've disabled it and haven't done much with it in quite a while. The code > has fallen into disrepair and some has been removed in the latest > versions. I'd suggest looking at the early 2.3.x and 2.2.1[23] series of > Linux kernels. That's where it was doing its best. Thanks. I'll get that version. > How do you keep track of what parts of a page are used? In Linux I was > just pulling pages off the free-list and zero-ing them. Do you have a > bitmap of used regions within pages on BSD? My mistake. FreeBSD zeroes the whole page as well. I traced through the code incorrectly. > I wanted a few bits for each page to describe its state: zero'd, > non-zero'd, busy being zero'd. It would have taken some changes to the > non-arch Linux code to do that and at the time we were moving to a more > stable tree so I didn't continue with it. It sounds as though you have a > framework for doing that sort of thing (and more) with BSD. Can you send > me a pointer to the sources you're using? I'd like to look into it. I'm running FreeBSD-stable right now, though I may switch to -current if I get promising results, to make it easier to merge. (There is a web interface to the FreeBSD CVS tree at http://www.freebsd.org/support.html#cvs). FYI, I'm interest in this for my thesis, which consists of two parts: (1) utilizing idle resources (cpu, memory, disk/network I/O, disk/memory space) for non-interfering background processing (i.e. run processes/threads using *only* idle capacities); and (2) to use that mechanism for speculative techniques. Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Intel 815E
I was wondering if anyone is using a motherboard with the Intel 815E chipset. If so did you get the onboard video and sound to work?(not that is overly important, I would popin an ATI xpert 98 8MB if need be). And if so, which frebsd 3.4S, 5.0C or somewhere in between? I was thinking of the ABIT SE-6, in particular. To my knowlegde Intel, Asus and Abit are considered good manufacturers. What are some others? and which are the manufacturers to avoid? In particular, I was wondering about DFI they cost less but are their products stable or problematic? Thanks, David Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
We started losing performance with the idle page clearing so I've disabled it and haven't done much with it in quite a while. The code has fallen into disrepair and some has been removed in the latest versions. I'd suggest looking at the early 2.3.x and 2.2.1[23] series of Linux kernels. That's where it was doing its best. We've also found that using dcbz, which zeros cache lines directly, actually improves performance. That is contradictory to one of the conclusions I drew in that paper. My conjecture was that the zero'd pages would not be used often since a process given a fresh page wouldn't read from it before a write. I still do think the idle page zero-ing can be useful, though. If you do some work with BSD on this please let me know. I'd like to follow along since I've been playing with BSD lately. } Do you still have those FreeBSD patches, Alan? I'd be interested in doing } some more experiments with that code. } } That makes sense. Other factors that may have an impact: } } * if you always have enough zeroed pages remaining over your } benchmark (> ~1/2 free pages), FreeBSD will never do the } idle-time zeroing How do you keep track of what parts of a page are used? In Linux I was just pulling pages off the free-list and zero-ing them. Do you have a bitmap of used regions within pages on BSD? } * it looks to me as if Cort's Linux code will always zero whole } pages, while the FreeBSD code is a little smarter and only zeroes } used regions of a page (less impact on caches?) } } * cache size differences between PPC and i386? Right, those won't be cached if the page is marked non-cacheable. } I'm looking at Cort's code (arch/ppc/kernel/idle.c), and while he turns off } the caching for pages he zeroes, I don't see him disabling the L1/2 caches } explicitly. Is this implicit with setting the non-cacheable flag on the } PPC? Also, idle-time zeroing is commented out in the version I'm looking at } (1.68, 1999/10/15), where problems found after the paper was published? I wanted a few bits for each page to describe its state: zero'd, non-zero'd, busy being zero'd. It would have taken some changes to the non-arch Linux code to do that and at the time we were moving to a more stable tree so I didn't continue with it. It sounds as though you have a framework for doing that sort of thing (and more) with BSD. Can you send me a pointer to the sources you're using? I'd like to look into it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
(Cort, the reason I'm CCing you is that I'm interested in using some of the mechanism described in your OSDI'99 paper for FreeBSD, and I've some questions about your Linux implementation, see below.) Alan Cox wrote: > Last year, I tried to reproduce some of the claims/results > in this paper on FreeBSD/x86 and couldn't. I also tried > limiting the idle loop to clearing pages of one particular > color at a time. That way, the cache lines replaced by > the second page you clear are the cache lines holding > the first page you cleared, and so on for the third, > fourth, ... pages cleared. Again, I saw no measurable > effect on tests like "buildworld", which is a similar > workload to the paper's if I recall correctly. Do you still have those FreeBSD patches, Alan? I'd be interested in doing some more experiments with that code. > Finally, it's possible that having these pre-zeroed pages > in your L2 cache might be beneficial if they get allocated > and used right away. FreeBSD's idle loop zeroes the pages > that are next in line for allocation. That makes sense. Other factors that may have an impact: * if you always have enough zeroed pages remaining over your benchmark (> ~1/2 free pages), FreeBSD will never do the idle-time zeroing * it looks to me as if Cort's Linux code will always zero whole pages, while the FreeBSD code is a little smarter and only zeroes used regions of a page (less impact on caches?) * cache size differences between PPC and i386? I'm looking at Cort's code (arch/ppc/kernel/idle.c), and while he turns off the caching for pages he zeroes, I don't see him disabling the L1/2 caches explicitly. Is this implicit with setting the non-cacheable flag on the PPC? Also, idle-time zeroing is commented out in the version I'm looking at (1.68, 1999/10/15), where problems found after the paper was published? Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel 840 Chipset Discontinue
> Supermicro has two new boards, 370DL3 and 370DLE. Identical in specs to > the 840 boards, but using some kind of "ServerWork LE" chipset. However, I > have also been hearing bad news about these boards as well. The IBM Netfinity 3500 servers (possibly other Netfinity models also) use the Serverworks LE chipset, and work well with FreeBSD 4.0-STABLE. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel 840 Chipset Discontinue
Apparently it affects all boards that the Intel 840 chipset. Yeah, it does suck that the 370DLx boards dont have AGP, but for a server you can still find old PCI video cards. On Fri, 21 Jul 2000, Kenneth D. Merry wrote: > On Fri, Jul 21, 2000 at 12:31:58 -0400, Essenz Consulting wrote: > > I was told by several of my distributors that all motherboards based off > > of the Intel 840 chipset are being discontinued. That means the Supermicro > > PIIDM3 and PIIIDME, and any other 840 board. > > Are you sure they don't just mean any 840 board that uses SDRAM? > > It looks like Supermicro has a RAMBUS 840 board on their web page now: > > http://www.supermicro.com/PRODUCT/MotherBoards/840/PIIIDR3a.htm > > > Supermicro has two new boards, 370DL3 and 370DLE. Identical in specs to > > the 840 boards, but using some kind of "ServerWork LE" chipset. However, I > > have also been hearing bad news about these boards as well. > > Not quite identical. They don't have AGP, which makes it difficult to > get graphics boards. (If you want to use it for a workstation. Most > graphics boards don't come in plain PCI anymore.) > > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hardware" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel 840 Chipset Discontinue
On Fri, Jul 21, 2000 at 12:31:58 -0400, Essenz Consulting wrote: > I was told by several of my distributors that all motherboards based off > of the Intel 840 chipset are being discontinued. That means the Supermicro > PIIDM3 and PIIIDME, and any other 840 board. Are you sure they don't just mean any 840 board that uses SDRAM? It looks like Supermicro has a RAMBUS 840 board on their web page now: http://www.supermicro.com/PRODUCT/MotherBoards/840/PIIIDR3a.htm > Supermicro has two new boards, 370DL3 and 370DLE. Identical in specs to > the 840 boards, but using some kind of "ServerWork LE" chipset. However, I > have also been hearing bad news about these boards as well. Not quite identical. They don't have AGP, which makes it difficult to get graphics boards. (If you want to use it for a workstation. Most graphics boards don't come in plain PCI anymore.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Intel 840 Chipset Discontinue
I was told by several of my distributors that all motherboards based off of the Intel 840 chipset are being discontinued. That means the Supermicro PIIDM3 and PIIIDME, and any other 840 board. Supermicro has two new boards, 370DL3 and 370DLE. Identical in specs to the 840 boards, but using some kind of "ServerWork LE" chipset. However, I have also been hearing bad news about these boards as well. Has anyone worked with these boards? Supermicro SAYS that they work fine under Linux and Solaris. However, one of my distributors says thay they are extremely touchy when it comes to memory. Only Registered PC133 ECC memory will work. If someone at freebsd.org wants to seriously test these boards, let me know, and I'll donate one. Without the 840 boards, server configs are now back to the 440GX days! -john v.e. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: dlopen() and friends from a statically-linked binary?
On 20-Jul-00 Raymond Wiker wrote: > Is it possible, at all, to use dlopen etc from a > statically-linked executable? My experiments with FreeBSD-4.0 (see > below) indicate that it's not possible. You can't do it from a statically linked binary, however you can create a dynamic executable with no external unresolved references.. I forget how though :-/ > The reason that I'd like this to work is that SBCL (a Common > Lisp implementation, see http://sbcl.sourceforge.net) needs the > addresses of certain library symbols (e.g, errno) when building the > initial lisp image. This seems to require static linking. On the other > hand, SBCL is severely handicapped if it cannot subsequently use > dlopen() to load foreign code into the running lisp system. Well, I don't see why it would need static linking for that.. When the binary runs the libraries it uses will get loaded, and then it can use dlsym() to get the addresses it needs.. (ie what I am saying is I don't understand your explanation :) > raw : ~ $ gcc -static dltest.c -o dltest > raw : ~ $ ./dltest > dlopen returned 0: Service unavailable > Handle: 0x0, main: 0x0 > > raw : ~ $ gcc dltest.c -o dltest > raw : ~ $ ./dltest > Handle: 0x2805e000, main: 0x0 > Handle: 0x0, main: 0x0 > > [ Note: this seems wrong; according to the manpage for dlsym, the > second call should give the same output as the first. ] Agreed. --- 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen() and friends from a statically-linked binary?
> "Raymond" == Raymond Wiker <[EMAIL PROTECTED]> writes:
Raymond> raw : ~ $ cat dltest.c
Raymond> #include
Raymond> #include
Raymond> main()
Raymond> {
Raymond> void *handle;
Raymond> void *sym;
Raymond> handle = dlopen(0, RTLD_LAZY);
Raymond> if (handle == 0)
Raymond> {
Raymond> fprintf(stderr, "dlopen returned 0: %s\n", dlerror());
Raymond> }
Raymond> else
Raymond> {
Raymond> fprintf(stderr, "Handle: %p, main: %p\n", handle, dlsym(handle,
"main"));
Raymond> }
Raymond> fprintf(stderr, "Handle: %p, main: %p\n", 0, dlsym(0, "main"));
Raymond> return 0;
Raymond> }
Raymond> raw : ~ $ gcc -static dltest.c -o dltest
Raymond> raw : ~ $ ./dltest
Raymond> dlopen returned 0: Service unavailable
Raymond> Handle: 0x0, main: 0x0
Raymond> raw : ~ $ gcc dltest.c -o dltest
Raymond> raw : ~ $ ./dltest
Raymond> Handle: 0x2805e000, main: 0x0
Raymond> Handle: 0x0, main: 0x0
Raymond> [ Note: this seems wrong; according to the manpage for dlsym, the
Raymond> second call should give the same output as the first. ]
It does, it returns NULL. I'm not sure what your issues with SBCL are
(I'll try to take a look later if I get time). I believe to get your
sample code above to work you want...
gcc dltest.c -Xlinker -export-dynamic -o dltest
This then gives me
Handle: 0x2805d000, main: 0x8048508
Handle: 0x0, main: 0x8048508
Hope this helps,
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen() and friends from a statically-linked binary?
> raw : ~ $ gcc dltest.c -o dltest > raw : ~ $ ./dltest > Handle: 0x2805e000, main: 0x0 > Handle: 0x0, main: 0x0 > > [ Note: this seems wrong; according to the manpage for dlsym, the > second call should give the same output as the first. ] Sorry about the confusion... the "main" symbol does not appear to work for this illustration (possibly because it doesn't come from a dynamic library?). If I try with "errno" instead, I get raw : ~ $ ./dltest Handle: 0x2805e000, errno: 0x280f5cd4 Handle: 0x0, errno: 0x0 raw : ~ $ --- according to the manpage for dlsym(), passing 0 for handle should have the same effect as passing 0 as the path to dlopen; i.e, to access the symbol table for the running program. -- Raymond Wiker To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
open() error
Hello. I've noticed a strange error in open() syscall: when system booted with a CD as root (boot -C) the following code fails with EINVAL: fd = open(c, O_RDONLY | O_NONBLOCK | O_EXLOCK, 0) When root is hdd with UFS (mounted read-only), this works fine. Is it a bug or i missed something? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
dlopen() and friends from a statically-linked binary?
[ Re-sent, as it seemed to get lost on my first try. ]
Is it possible, at all, to use dlopen etc from a
statically-linked executable? My experiments with FreeBSD-4.0 (see
below) indicate that it's not possible.
The reason that I'd like this to work is that SBCL (a Common
Lisp implementation, see http://sbcl.sourceforge.net) needs the
addresses of certain library symbols (e.g, errno) when building the
initial lisp image. This seems to require static linking. On the other
hand, SBCL is severely handicapped if it cannot subsequently use
dlopen() to load foreign code into the running lisp system.
raw : ~ $ cat dltest.c
#include
#include
main()
{
void *handle;
void *sym;
handle = dlopen(0, RTLD_LAZY);
if (handle == 0)
{
fprintf(stderr, "dlopen returned 0: %s\n", dlerror());
}
else
{
fprintf(stderr, "Handle: %p, main: %p\n", handle, dlsym(handle, "main"));
}
fprintf(stderr, "Handle: %p, main: %p\n", 0, dlsym(0, "main"));
return 0;
}
raw : ~ $ gcc -static dltest.c -o dltest
raw : ~ $ ./dltest
dlopen returned 0: Service unavailable
Handle: 0x0, main: 0x0
raw : ~ $ gcc dltest.c -o dltest
raw : ~ $ ./dltest
Handle: 0x2805e000, main: 0x0
Handle: 0x0, main: 0x0
[ Note: this seems wrong; according to the manpage for dlsym, the
second call should give the same output as the first. ]
--
Raymond Wiker
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
