Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
Tom Samplonius wrote: - Alfred Perlstein [EMAIL PROTECTED] wrote: Does anyone have any alternative solutions that would provide a more reliable environment other than PAE? Besideds PAE some people have mentioned running an amd64 system. One thing to consider is that PAE in 6-stable (6.3 and beyond) is considered very stable, so if you can't make the jump to amd64 system because you'd have to recompile too much, you might have luck updating sources to 6-stable and trying that kernel, then installing 6.3 userland. Is PAE really that stable? I thought it was fairly unpolished, mainly because PAE is seen as a weak kludge implemented by Intel because they all thought we would all be using Itanium's by now. Intel reversed their folly pretty quickly, adopted the x86-64 extensions as-is from AMD, and pushed them onto every piece of silicon they make. Enough people run PAE without issue that there's a pretty good chance it will run for you too. Some drivers were never adapted to work with PAE so hardware support is a smaller subset than regular i386. I also really don't know how anyone would properly use 16GB of RAM under PAE anyways? Each process is going to limited to just under 4GB. The kernel memory space can't be bigger than 4GB either, so forget about a huge disk cache. If you have many moderate-sized processes then PAE can be a reasonable fit. And is there some really stability fear about FreeBSD on x86-64? Seems just the same as i386. No stability issues in general. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
Does anyone have any alternative solutions that would provide a more reliable environment other than PAE? I was faced with a similar problem last autmumn - we had been running 6.2 on a set of servers with 4 gig or RAM, but purchased new servers with 16 gig in them. I experimented with various things - PAE being my initial try, and ended up opting for 7.0 (prerelease) usin amd64. It worked like a charm. Note that I only shifted the OS to amd64 - I still ran my application code as the existing 6.2/i386 binaries. Didn't want to make a drastic shift in the application at the same time. It all ran fine - but our application is staticly linked, so that did make things simpler. Since then I;ve migrated almost everything we have over to amd64 and 7.0 and we are very happy with it - the only machines that havent been moved are those which cannot run in 64 bit mode (two desktops and two older servers). So, I would recommend going with amd64 if you can. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
On Feb 20, 2008, at 1:56 AM, Tom Samplonius wrote: And is there some really stability fear about FreeBSD on x86-64? Seems just the same as i386. Some poorly written software fails to run properly in 64-bit environment. I have one such package, and my solution was to compile it on a 32-bit box, and copy the binaries over. Works just fine with 32-bit compat enabled on the amd64 kernel. Other than that, the FreeBSD/amd64 has been 100% rock solid for me since 6.0 when I started getting 64-bit boxes. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
Kevin K [EMAIL PROTECTED] wrote: I have a box that we recently installed 16GB of RAM on. The box is i386 FreeBSD 6.2. It only recognizes 4gb. Several people have already pointed out that you can either run FreeBSD/i386+PAE or FreeBSD/amd64 (64bit). However, there's an important piece of information missing: _Why_ did you install 16 GB of RAM? The answer to that question might give an indication which of the two ways would be best for you. For example, if you need to run a single large application that needs much RAM, then i386+PAE won't help you at all, because you still have a 4 GB address space limit and a 4 GB process size limit. Actually much less than 4 GB because the 32bit address space is shared between kernel and userland. To get rid of the 4 GB limit completely, you must install FreeBSD/amd64. Also, amd64 code is often (but not always) faster than i386 code. My recommendation is that you use amd64, unless there is a specific reason you can't do that, e.g. you depend on a driver or third-party software that won't run on amd64. Then i386+PAE is your only choice, unfortunately. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly. -- RFC 2549 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
Tom Samplonius wrote: Is PAE really that stable? I thought it was fairly unpolished, mainly because PAE is seen as a weak kludge implemented by Intel because they all thought we would all be using Itanium's by now. Intel reversed their folly pretty quickly, adopted the x86-64 extensions as-is from AMD, and pushed them onto every piece of silicon they make. Architecturally, it's a nasty kludge. As far as stability on FreeBSD is concerned, my only machine under PAE with 4 GB RAM (without PAE it would use a bit over 3 GB) is very solid on 6-STABLE. I also really don't know how anyone would properly use 16GB of RAM under PAE anyways? Each process is going to limited to just under 4GB. The kernel memory space can't be bigger than 4GB either, so forget about a huge disk cache. As I understand it, one possible benefit could be to use the memory for disk / file cache. AFAIK the pages are just pages, without distinction where they are mapped, and for example, if you run PostgreSQL, it couldn't use more than 4 GB for its own data (actually closer to 2 GB because of some sysvshm issues) but it will indirectly use the cache. And is there some really stability fear about FreeBSD on x86-64? Seems just the same as i386. I agree, FreeBSD on amd64 is very stable. signature.asc Description: OpenPGP digital signature
Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
Architecturally, it's a nasty kludge. As far as stability on FreeBSD is concerned, my only machine under PAE with 4 GB RAM (without PAE it would use a bit over 3 GB) is very solid on 6-STABLE. To the original poster - does a PAE kernel actually boot on your 16 gig machines ? My problem was that I had tested PAE of 4 gig machines (to avoid the bit over 3 problem) but when it came down to 16 gig on the Xeons then it wouldnt actually boot :-( -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Dual Core Xeon / i386 install w/ more than 4gb of RAM
Thank you all for your suggestions. I have been trying to push to move to amd64 architecture for all the reasons you all stated. For the record, we tested PAE on one machine, booted the kernel w/ nextboot and it crashed about 15 minutes later. I will consider configuring a dump device to analyze the kernel dumps, but for now we reverted to the original i386 kernel and are likely going to scrap the PAE idea and move to amd64. This was a management decision (obviously) and the people who originally built this box (long before I was there), did not have enough experience or foresight. i was hoping for alternative suggestions to reduce downtime of these boxes, such as recompiling amd64 manually instead of a fresh install. These boxes are just Apache, Mysql, PHP type boxes. Nothing exotic or fancy. Thanks again for your suggestions. I am trying my best to relay the reasoning and rock-solid logic ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ivan Voras Sent: Wednesday, February 20, 2008 11:35 AM To: freebsd-stable@freebsd.org Subject: Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM Tom Samplonius wrote: Is PAE really that stable? I thought it was fairly unpolished, mainly because PAE is seen as a weak kludge implemented by Intel because they all thought we would all be using Itanium's by now. Intel reversed their folly pretty quickly, adopted the x86-64 extensions as-is from AMD, and pushed them onto every piece of silicon they make. Architecturally, it's a nasty kludge. As far as stability on FreeBSD is concerned, my only machine under PAE with 4 GB RAM (without PAE it would use a bit over 3 GB) is very solid on 6-STABLE. I also really don't know how anyone would properly use 16GB of RAM under PAE anyways? Each process is going to limited to just under 4GB. The kernel memory space can't be bigger than 4GB either, so forget about a huge disk cache. As I understand it, one possible benefit could be to use the memory for disk / file cache. AFAIK the pages are just pages, without distinction where they are mapped, and for example, if you run PostgreSQL, it couldn't use more than 4 GB for its own data (actually closer to 2 GB because of some sysvshm issues) but it will indirectly use the cache. And is there some really stability fear about FreeBSD on x86-64? Seems just the same as i386. I agree, FreeBSD on amd64 is very stable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tmpfs: strange behaviour
David Naylor wrote: Oliver Fromme wrote: What is the exact CFLAGS setting that you use? Do you use -O2 (or -Os) without -fno-strict-aliasing? I have managed to isolate the problem and it is definitely tmpfs related. If the directory that I'm installing into is tmpfs then it will fail, if it is ufs then it works. I recompiled tmpfs module (and reloaded) with CFLAGS='' with the same result. As an aside I have found that the default CFLAGS for src are: -O2 -fno-strict-aliasing -pipe. For most parts of src, but some override it. Would -fstrict-aliasing break anything in base/sys? I think src/sys is clean with regards to aliasing, but I'm not 100% sure. Someone please correct me if I'm wrong. I recommend not to put a CFLAGS line in /etc/make.conf at all. So far I haven't seen an example of a really useful CFLAGS line in this thread, but several examples that could possibly cause damage. It's best not to override the default (which is there for a reason). If you want better optimization, a appropriate CPUTYPE=... line is probably a better idea. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing. -- Mother Teresa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dmesg : no output on 1 of 2 7-stable boxes
Julian H. Stacey wrote: Oliver Fromme wrote: The dmesg buffer is a circular buffer containing both kernel output and console output. However, dmesg displays only the kernel output. If there was lots of console output, it filled all of the dmesg buffer, so dmesg displays nothing (all of the kernel output was overwritten by console output). dmesg -a will display everything, i.e. kernel + console output. Some of that description could usefuly be added to `man dmesg` ? I agree. Might some commiter wnat to hack a few words in ? Or do we neeed a formal send-pr (that a commiter would rephrase likely anyway, so best skip the send-pr ? ). If you have the time, please submit a PR (docs category). I'll take care of it. You're a native English speaker. I am not. So chances are that I won't rephrase it, except for technical reasons. And even if I did rephrase it, it's still a good thing to have a PR, so the issue doesn't get lost and forgotten. - I tried loader.confkern.msgbuf=64000 I think it must be a multiple of the pages size, i,e, 4K = 4096 on FreeBSD/i386. I usually set it to 65536 or 131072. [...] Puzzled on syntax to set size in loader.conf ? Unfortunately it's a kernel constant, not a tunable. The only way to change it is via options MSGBUF_SIZE=... in your kernel config file, and rebuild the kernel. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Whatever happened to the days when hacking started at the cerebral cortex, and not at the keyboard? -- Sid on userfriendly.org by Illiad, 2007-06-20 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re:more than 4gb of RAM (configurations)
On Feb 19, 2008 5:10 PM, Kevin K [EMAIL PROTECTED] wrote: I have a box that we recently installed 16GB of RAM on. The box is i386 FreeBSD 6.2. It only recognizes 4gb. Siding with most of the group (go amd64), I'll add my own comment: Using PAE to access 4G of RAM (because 4G shows up as 2.5 to 3.5 gig, depending on the motherboard) under i386 is a reasonable solution, IMHO. Maybe even 6 gig or 8 gig... if you're trying to extend the life of an ia32 server. But with amd64 supporting ia32 binaries well, it seems the only reason left might be drivers --- except ... are there _any_ drivers that support PAE and _not_ amd64? I'm using amd64 on my laptop (which has 4gig) because the only driver I care about (the nvidia binary driver) doesn't work under either PAE or amd64 (and ... it also doesn't support 8xxx series mobile chipsets ... so I'm screwed anyways) . I'd be curious to know if anyone's still hedging their bets by making their machine dual-boot i386/amd64 --- and how they configure it. Have you thought about sharing /usr or parts of it? Installed ports can seemingly mess things up. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall: weird ui problem
On Fri, 2008-01-25 at 17:29 +0200, Andriy Gapon wrote: FreeBSD 6.3-RELEASE amd64 Running sysinstall for post-installation configuration of sorts in xterm/konsole/gnome-terminal. Hmm your $TERM environmental variable is set to vt100? vt200? wscons? ~BAS Very strange issue: arrow keys work quite well throughout sysinstall menus but in Fdisk and Label screens both up and down arrow keys are interpreted as down key. This is not fatal in Label screen because navigation cycles, but in Fdisk menu you can not reach up from the bottom entry (slice). In system console everything is OK, though. -- Brian A. Seklecki [EMAIL PROTECTED] Collaborative Fusion, Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
* Tom Samplonius [EMAIL PROTECTED] [080219 23:00] wrote: - Alfred Perlstein [EMAIL PROTECTED] wrote: Does anyone have any alternative solutions that would provide a more reliable environment other than PAE? Besideds PAE some people have mentioned running an amd64 system. One thing to consider is that PAE in 6-stable (6.3 and beyond) is considered very stable, so if you can't make the jump to amd64 system because you'd have to recompile too much, you might have luck updating sources to 6-stable and trying that kernel, then installing 6.3 userland. Is PAE really that stable? I thought it was fairly unpolished, mainly because PAE is seen as a weak kludge implemented by Intel because they all thought we would all be using Itanium's by now. Intel reversed their folly pretty quickly, adopted the x86-64 extensions as-is from AMD, and pushed them onto every piece of silicon they make. The 6-stable (6.3 and beyond) has been in use at Yahoo and other sites for quite some time. I also really don't know how anyone would properly use 16GB of RAM under PAE anyways? Each process is going to limited to just under 4GB. The kernel memory space can't be bigger than 4GB either, so forget about a huge disk cache. Actually this is incorrect, the kernel can use physical memory outside of its address space as cache, so you can get more than 4GB of cache. And is there some really stability fear about FreeBSD on x86-64? Seems just the same as i386. It's fine, people are just suggesting that the person upgrade to -stable (not stay at 6.2) and are concerned that reinstalling the machine as amd64 might be too much of a move. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall: weird ui problem
on 20/02/2008 20:45 Brian A. Seklecki said the following: On Fri, 2008-01-25 at 17:29 +0200, Andriy Gapon wrote: FreeBSD 6.3-RELEASE amd64 Running sysinstall for post-installation configuration of sorts in xterm/konsole/gnome-terminal. Hmm your $TERM environmental variable is set to vt100? vt200? wscons? $ echo $TERM xterm ~BAS Very strange issue: arrow keys work quite well throughout sysinstall menus but in Fdisk and Label screens both up and down arrow keys are interpreted as down key. This is not fatal in Label screen because navigation cycles, but in Fdisk menu you can not reach up from the bottom entry (slice). In system console everything is OK, though. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.3 update and process freeze
Hi, Since i've updated my machine to FreeBSD 6.3 some process randomly start using 100% CPU or are locked to STOP state (in top). Is there a known solution / patch ? Except the rollback :) Regards, Gil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.3 update and process freeze
Gil Bidon wrote: Hi, Since i've updated my machine to FreeBSD 6.3 some process randomly start using 100% CPU or are locked to STOP state (in top). Is there a known solution / patch ? Except the rollback :) You need to tell us more information. What processes are they? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.3 update and process freeze
Gil Bidon wrote: Hi, Since i've updated my machine to FreeBSD 6.3 some process randomly start using 100% CPU or are locked to STOP state (in top). Is there a known solution / patch ? Except the rollback :) Regards, Gil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Gil, You'll need to provide significantly more information before anyone will be able to help you. Some of which might be, a list of the offending processes, output from top, dmesg, what patchlevel you're running, any errors from syslog. Aaron ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall: weird ui problem
On Wed, 2008-02-20 at 23:11 +0200, Andriy Gapon wrote: on 20/02/2008 20:45 Brian A. Seklecki said the following: On Fri, 2008-01-25 at 17:29 +0200, Andriy Gapon wrote: FreeBSD 6.3-RELEASE amd64 Running sysinstall for post-installation configuration of sorts in xterm/konsole/gnome-terminal. Hmm your $TERM environmental variable is set to vt100? vt200? wscons? I would experiment here. It is really meant to be used on wscons/pcons. Try a different terminal emulator and/or a real VTY on your control. Try vt100, vt220, vt420, pccons, etc... $ echo $TERM xterm ~BAS IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
