Re: [gentoo-amd64] eth3 - how to set up?
S, Paul Stear piše: Hi, I have just changed my motherboard and processor and am having trouble with my network connection. I am having to enter in a root terminal the following each time I boot the system:- ifconfig eth3 192.168.1.6 broadcast 192.168.1.255 netmask 255.255.255.0 up After this everything works as it should. Where is this setting help? I have read the guide but nothing seems to make a difference. I'm sure this is a lack of understanding on my part so please help. Paul I'm not sure I am teh one to be answering this, but since I had similar problem many times and no one else seems to be answering, here it is. Your problem is compounded. Forst part of the problem is that system remembers seeing your former cards and has now reserved for each card its ethX number. Even if cards are not there any more ( and onboard NIC is different) system keeps hoping that one day you might plug them back and keeps those names reserved. udev is userland helper that is responsible for crating logical devices on the base of kernel messages it receives about present, plugged or unpluugged devices. How and which exactly devices it creates is described in its config files in /etc/udev.d. File that should inteset you is named XX-persistent-net.rules ( XX in front are two decimals ). udev writes and updates it itself with each new card it finds, so that it knows that card with tg3 driver and MAC address XX:YY:ZZ:WW:TT.BB should be created as device eth4, for example. If you don't care how new cards are numbered or if you have only one card, simply delete it and restart the system. If you do care, edit it by hand- format is obvious. Second part of the problem is that you card is not initialized, since it is not named eth0, as system expects. If you did erase aforementioned file, after restart new card will be shown as eth0, starttup scripts will find it and everything should fall in its place again...
Re: [gentoo-amd64] What happened to sun-jdk?
Mark Knecht wrote: SNIP As far as I can tell so far: ACCEPT_LICENSE=* will accept all licenses. ACCEPT_LICENSE=dlj-1.1 will accept just this license in case someone doesn't want to use licensed software without knowing that they've added it. HTH, Mark ACCEPT_LICENSE is mentioned in make.conf manpage. I have set it to * -...@eula dlj-1.1 sun-bcla-java-vm Branko
Re: [gentoo-amd64] Self created initramfs cannot work
David Shen wrote: SNIP But when I try to boot my system, I got kernel panic, and it says it cannot find the init script. If I remove the 'initrd' instruction from the grub.conf file, the error message does different, which means the system WAS trying to process the initramfs. But I do not know why it cannot find the init script. I modified the initramfs that the genkernel generated before, and the system works fine after that. But I never created a initramfs from scratch before I think kernel by default searches for /sbin/init. Have you tried with init=/init within kernel command line ?
Re: [gentoo-amd64] Managing CPU usage when doing emerges
Alex Alexander wrote: most packages build fine with a 768M tmpfs :) if you plan on compiling big stuff like gcc you'll need to make it larger or unmount it though. With ext4 useable, is it still practicall to fiddle with thmfs for building ? Ext4 can be configured so that it defers writing for significant amounts of time, which means that it should perform closer to tmpfs performance, without headaches, associated with it. Using aggressive settings might increase risk of data loss, but notebook is by its nature battery backed and so prone to most of the issues...
Re: [gentoo-amd64] Managing CPU usage when doing emerges
Branko Badrljica wrote: With ext4 useable, is it still practicall to fiddle with thmfs for building ? EDIT: Typo- thms --tmpfs
Re: [gentoo-amd64] Managing CPU usage when doing emerges
Alex Alexander wrote: you would need a separate partition for /var/tmp/portage with special settings to be safe... even then, if you can afford the ram, tmpfs is probably a better solution. I use such settings on my machine all the time, with no problems whatsoever until now. It just requeires a little attention when rebooting ( have to wait about a minute for machine to start booting at the end of the shutdown) and even then only files that have been modified or written are ones at risk. With notebook, power failure is much less of concern, so risks are much lower. disk io is one of the worst bottlenecks in today's systems... no disk io * =] Which is more or less ext4 performance if files remain in RAM. When memory pressure increases, ext4 wil just start writing to the files, which can actually be faster than tmpfs -- swap transfers...
Re: [gentoo-amd64] Re: Managing CPU usage when doing emerges
Nikos Chantziaras wrote: I'm on ext4 with delayed allocation enabled, but I still see GUI lock-ups when emerging without tmpfs (and I do have nice 19 and ionice idle). There are a few lock-ups even with tmpfs, but not as severe as without it. But I do have 6GB RAM. Not sure if 2GB will be enough since if you're running X and have apps open (Firefox, etc), RAM might get pretty tight and tmpfs will swap out to disk. I have /var/tmp on ext4 with delayed allocation on ext4 and 8GB RAM. For me tmpfs wasn't worth the hassle, so i dropped it. I couldn't tell the difference. I am using that setup on notebook also ( Dell Inspiron 1720 with 4GB RAM and 2x250GB disks in RAID-0), where it works very well...
Re: [gentoo-amd64] Re: I can use only 3GB aout of install 6GB
Duncan wrote: Then, look at memory model. Here, with current kernels, I have only one option, Sparse, evidently limited by my choice of hardware (Processor family and/or Supported processor vendor options, higher on the page, I'd guess or perhaps probed from the BIOS). However with older kernels, and presumably now if I were to choose hardware other than AMD Opteron/K8 (or choose a different BIOS option), there are Flat and Discontiguous options as well. Unfortunately, I can't tell you which options are correct for your (Intel) hardware. If you have multiple memory model choices, you may just have to try them and see. I thought those extra options were just for NUMA systems and were about how the memory from several NUMA nodes fits together ie whether it has to form one continuos memory range or not. WRT to original question, I'd update BIOS and kernel to the latest version available and if that fails to rectifyy the problem, I'd try to toy with kernel memory option parameters
Re: [gentoo-amd64] Re: I can use only 3GB aout of install 6GB
Volker Armin Hemmann wrote: well, duncan has some old hardware and likes to turn on a lot of superfluos options. Don't touch the numa stuff. Don't even enable it if you have 2cores or intel system. True. NUMA is for Non Uniform Memory Access systems or roughly the systems with several nodes, each with at least one core and some local memory with lowest access times for that particular core. Dual and quadcore like i7 or Phenom is simple SMP where all nodes see memory through the same interface. Modern multisocket i7-based or Opteron is NUMA...
Re: [gentoo-amd64] mount ext3 with ext4 driver
Martin Herrman wrote: All, After reading this: http://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4 do you have any experience with mounting your ext3 filesystems using the ext4 module? Is the performance improvement noticeable? I haven't tried it directly, but I remember forgetting to compile-in ext2 support and then being unable to mount /boot (ext2) despite having ext4 support And how about using the extra options: |# tune2fs -O extents,uninit_bg,dir_index /dev//DEV /| I use all those, except uninit_bg without a problem. In fact, I use dir_index,filetypes,sparse_super,acl,user_xattr without a problem. But I have noticed that sometimes some mount options in /etc/fstab can prevent mounting or cause an error and mount / in ro mode, not always the same. I have noticed that I can mount ordinary partition with one option combination but fail when mounting /dev/md2 in precisely same way. Basic noatime works always,though. |/ /|? How stable do you think that the ext4 module actually is? (using recent kernels, e.g. 2.6.29) I had many problems ( files dissapearing after reboot, other files getting strange content etc), but after ext4 problems were published about and corresponding pathes in kernel everything works fine for me. I haven't had a single issue after that, and I'm using it on two lightly loaded servers and my workstation.
Re: [gentoo-amd64] ebuild for gcc-4.4.0 ?
Volker Armin Hemmann wrote: install the gcc-porting and toolchain overlays. Have fun. Or feel the pain. look at this first: http://bugs.gentoo.org/show_bug.cgi?id=249226 Thanks for the answer. I emerged it and it seems to be working, even though I am using pretty aggressive flags: CFLAGS=-march=native -O3 -pipe -fgcse-sm -fgcse-las -fivopts -ftree-loop-linear -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -ftracer -funroll-loops -fprefetch-loop-arrays -freorder-blocks-and-partition -funswitch-loops -fsee -ftree-loop-im -ftree-loop-ivcanon -fvariable-expansion-in-unroller I tried also using -ftree-parallelize-loops=4, but with it compiler fails when I try to compile practically anything. BTW: How much of a performance gain would be if one could compile everything with -profile-generate, run resulting program on some representative test data and then use profile files to generate final binary with -fprofile-use ?
Re: [gentoo-amd64] Re: mount ext3 with ext4 driver
Duncan wrote: If you're interested in more, check the last three weeks' or so LWN (lwn.net) kernel pages. There's links to the LKML threads, as well as to the Ubuntu bug that kicked it all off. (Some proprietaryware NVidia driver folks were crashing frequently, and those who had chosen the new Ubuntu ext4 option noticed their gnome settings files were zeroed out after they rebooted. That particular bug is papered over for 2.6.29 and generally fixed for 2.6.30, but there's still a smaller risk as long as you use the default data=writeback, the 2.6.30 ext3 default as well. So as far as is known, with .30, ext4 SHOULD be as stable as ext3 in the same data= mode, but the fact that such things are still coming up means nobody's sure there aren't more such things to come up, thus, people who value their data will want to wait to at least 2.6.31 before trying ext4, and will want to be sure they specifically set data=ordered for ext3 before switching to 2.6.30.) Those issues alone shouldn't cost you valuable data or cause filesystem loss, especially since they were patched. Even when I was loosong files, I never lost any really important archive, just bits and pieces of files that machine has modified, created or overwritten in some way, which means config files, libraries and binaries ( after emerge for example). I have applied patches to gentoo-sources manually just after a have grep-ed them from 2.6.28 patch on www.kernel.org, and from then I never had an issue. And BTW I do have journal=writeback all the time. Here are my mount options from /etc/fstab: 1. My machine: /dev/sda5 /ext4 rw,noatime,user_xattr,acl,journal_checksum,journal_async_commit,data=ordered,barrier=0,commit=120,errors=remount-ro,max_batch_time=6,min_batch_time=5000 0 1 2. One server: /dev/md1/ext4 rw,noatime,user_xattr,acl,journal_checksum,journal_async_commit,data=ordered,barrier=0,commit=120,errors=remount-ro 0 1 3. Another server: /dev/md2/ext4 rw,noatime,user_xattr,acl,journal_checksum,journal_async_commit,data=ordered,barrier=0,commit=120,errors=continue 0 1 All this time I had 0 problems with it on any of the machines.
Re: [gentoo-amd64] Re: mount ext3 with ext4 driver
Branko Badrljica wrote: And BTW I do have journal=writeback all the time. Oops. My bad. I had data=writeback on servers, but it appears I have changed it to ordered last week, when I updated my initrd/initramfs amongst other things... Sorry
Re: [gentoo-amd64] Re: Change Install Prefix
Duncan wrote: I hadn't thought of that use of binpkgs, but yes, it should work. =:^) If you're advanced enough at scripting to be thinking about it, then great, and the overlay thing above shouldn't be too bad of a challenge, either. Question that comes to my mind is why isn't this implemented in portage as it is as it's very useful tool. With it, one could take a disk from machine with hopelessly broken system, connect it to good machine and reemerge broken packages, for example. Or, say, emerge packages on fast machine and install them to slow machine etc etc.
[gentoo-amd64] ebuild for gcc-4.4.0 ?
I have noticed that gcc-4.4.0 is out for some days now and went to see if anyone has noticed it on gentoo.org. As it turns out, bug is opened by some avid user, but no one came up with ebuilds so far. Given the fact that the new gcc has two new dependencies, which also need theirs ebuilds and that I'm not well versed with all that ebuild stuff, I'd rather wait for someone to come up with ebuilds before I go into pain journey with results that some ebuild jock could have in half an hour flat. So, what is with 4.4.0 ? Are new dependencies too much trouble for ebuild quickie or is it just that noone cared for it so far ? If former, then I better not loose time trying, if later, it would be nice to know if we can expect it soon or not... Branko
Re: [gentoo-amd64] Unable to read PDF on amd64
Steven Lembark wrote: Works fine on x86, both with acroread-9.1; other files work here with 9.1 on AMD, so it may be this file... Q: Would anyone else be willing to try opening the file to see if the problem is local to my systems? I had Acroread 8.1.something and have just emerged 9.1. It works for me. it takes 24 MB of RAM when document is open. Maybe doing memtest is in order ? My system: Phenom 9950 8GB RAM Board Foxconn A7DA-S (AMD 790GX + SB750 chipset) Nvidia 8800GT 1GB graphic card Card driver is configured for 512MB IOMMU window and kernel ( gentoo-sources-2.6.29-r1 with aufs2 patch has amd_iommu_size=1G in command line gcc=4.3.3 I can post emerge --info, if you need it...
Re: [gentoo-amd64] Re: grub and maximum kernel file size
Duncan wrote: Duncan wrote: Did you try md-mod,start_dirty_degraded=1 (AFAIK this applies to RAID-4/5/6 only)? No Hmm, and you said RAID-5, right? Yes. I tried now to boot without initramfs and it works- with and without that md-mod,start_dirty_degraded=1 option. But this is now. Will it continue to do so, remains to be seen. But no matter what, initramfs remains a keeper for me. BTW: Where is this mod-module name way of setting inbuilt module variables documented ? I have uvesafb built-in as part of kernel and had to check the sources ( documentation was out of date at some point ) to coem up with command line setting, like uvesafb.mode_option=1280x1024...@60 uvesafb.mtrr=3. Could I also write md.start_dirty_degraded=1 ? I think one of the reasons I may have never had to use that option on RAID-6 is that it has two-way parity, so chances are either one or the other will still be valid -- even if it crashes in the middle of a write, one stripe-write might be invalid, but as long as I wasn't already running degraded, the state on the others should be clean, either clean- state from before the write, or clean-state from after the write, thus ensuring data integrity. Naturally, due to hardware cache buffers, etc, this isn't entirely guaranteed (unless the write buffers are disabled), but the chances are far higher of a clean state than they are with RAID-5 with its single-way parity. Yes, but RAID-6 isn't simple expansion of RAID-5 concept. It has two parity chunks-P and Q. While P is simple XOR parity from RAID-5, Q is substantially compute intensive. Further, while Q generation is expensive, CPU can utilise its SSE artillery and soften the perceived extra load. But when CPU has to actually use Q parity for data regeneration, things come to a crawl. That part is quite intensive and SSE is useless there, so best CPU can do is use tabelaric approach and regenerate data byte-by-byte. So SW RAID-6 has come to be a bad idea, at least for me and my applications. HW RAID-6 with good HW is another story altogether, though. With SW, you pay extra drive, small extra power consumption, some extra cycles for Q generation ( not quite inconsequiential) and BIG penalty for regeneration - so big that usually doing bussines as usual while in such degraded mode is out of the question. So after some experience with SW and HW RAID-6 i opted for RAID-5 with cold spare and regular backups for pretty much everything. (FWIW I do run without UPS. Unfortunately the reality is that a proper UPS for this level of machine, at least back when I was running CRTs, would cost near what the machine itself did, and given that I was already buying near the top of my budget range that put a UPS out of consideration. Since I switched to LCD I've been considering it again and would likely have one by now had the economy and therefore my budget not tanked.) I did run for some time all of my machines through UPS only to find this costs too much. So I switched to DC. I rectified all three 220VAC phases to 260-300V DC and backed this up by 20x 100Ah-12V lead-acid akus in series. Even without akus it feels pretty much close to having UPS. When interruption happens, 90% of the time it affects only one phase, so remaining ones take over and I don't feel a thing... For my remote location I can't have 20 akus there, so I am working on PSU modification which would allow me to work on two... That's what my rootbak partition is for. =:^) Yes. And I use same thing on my workstation. Still, that doesn't quite match robustness of initrd. With initrd, if you can get to the phase where grub takes over, you can pretty much boot. Even if your kernel can't work with root drive for whatever reason ( missing driver for SATA,AHCI, ext4 ...) Well, you /could/ burn a CD with a kernel built with the proper options, but you are correct, booting from a CD is indeed a hassle. On Gentoo, how to do this is far from obvious. Actually, I've seen mods for *-WRT class routers and software (OpenWRT, DD-WRT, Tomato, etc) that do pretty much the same thing, solder a USB based flash module to the thing and expand their storage and flexibility by an order or two of magnitude! Run a server, etc, directly off your router! They can be made detachable, or not, as desired. Cool. If you have a link to such a thing, it would be apppreciated ;o) But if I were doing it over, as I said earlier, I'd definitely create separate RAID-6s instead of the single partitioned RAID-6, and use two rootbaks so three root filesystem images total, one on each of three separate RAID-6s, so if one failed to come up, I'd just change the command line as necessary to bring up the second, and if it failed, the third. Not every application has plenty of storage space. I'd also split the RAID-1, either creating two single-disk RAID-1s or more likely, four separate /boot images
Re: [gentoo-amd64] Re: grub and maximum kernel file size
Branko Badrljica wrote: Yes. I tried now to boot without initramfs and it works- with and without that md-mod,start_dirty_degraded=1 option. Update: it doesn't work really. System boots, but I can't write anything to filesystem. mount reports everything as fine. rootfs is mounted rw, acoording to mount. cat proc/mounts says that all RAIDs are up and running. dmesg|grep also shows nothing much out of the ordinary. Anyway, initramfs is back on for me...
Re: [gentoo-amd64] Re: grub and maximum kernel file size
flockm...@gmx.at wrote: SNIP thanks for the answer, i'm already running grub-0.97-r9. perhaps it is time to switch back to good old lilo, or to play with grub2 ;) Or perhaps not. I have 12+ MB kernels ( with internal initramfs for v86d and modules ) and external initramfs loaded with grub without any problem. And I use grub-0.97-r6. This machine is Dell Notebook Inspiron 1720 ( Intel C2D), but similar setup works on several workstations and server, too ( all AMD X2 and Phenom based)...
Re: [gentoo-amd64] Re: grub and maximum kernel file size
Duncan wrote: Yes, for LVM, no, for RAID, at least md/mdp kernel RAID. In theory, yes. In practice, it is unpredictable and flakey. I lost more than a day with a system that used to be able to autoassemble the RAID in kernel and boot it and then simply changed its mind and no matter what I did, it wouldn't boot from RAID. No available diagnostics is another hamper, since dmesg can tell you little about what exactly went wrong. In all those cases starting RAID manually went fine. It is nice to be able to use initramfs as some sort for backpack/first-aid-kit/MCGuyver's_toolshed when all else fails. It isn't always simple to boot from another media, especially if you need that particular kernel etc. That's why initramfs is cool. If the system is in good enough shape for grub to grab kernel and initrd, it can run diagnostics and maybe offer some fundamental services ( like named,dhcpd, routing, firewalling etc). user-vesa-framebuffer, I take it? FWIW, I'm running radeonfb here. But before it, I was running a very small font on vgacon. It worked reasonably well, tho radeonfb is certainly more flexible. Well, I have nVidia and have _never_ seen any card on which rivafb works. vesafb did work on some older cards, but not on 8800GT ( which is getting into age also). So uvesafb is only thing that works for me, at least until nvidia unifies linux driver or something like it...
Re: [gentoo-amd64] Re: grub and maximum kernel file size
Duncan wrote: Did you try md-mod,start_dirty_degraded=1 (AFAIK this applies to RAID-4/5/6 only)? No What about listing the appropriate component devices, as so: md=d1,/dev/sda1,/dev/sdb1,/dev/sdc1... ? Yes. I had it by default. Without it never seemed to work. With it, it worked _sometimes_. Initramfs seem to be superior solution. With it there is more stuff I can do, like trying to rebuild array, fsck filesystems thoroughly etc. In fact, this is what it does now. Amongst other things, it checks /etc/fstab, gets filesystem types for /boot and / and e2fscks them, if needed. Being early adopter of ext4 I was many times in situation when boot-time e2fsck found some serious errors but demanded to be rerun on unmounted media to be able to finish. Without initramfs, only way to do this is through CD, but kernel there doesn't recognise disks on my Dell. Besides that it is tedious. This way, machine can do it by itself in MacGyver style ;o) That's true, but my point is, by the time you setup all that complexity, you're almost setting up AND CONFIGURING a whole little mini-distribution inside your initramfs/initrd. That thingie is _definitely_ very useful and I plan to make it permanent. I had completed the script that does the packing in maybe two hours ( I don't remeber anymore ) and it needs maybe a few minutes to make initrd, copy it to /boot/initrd and old one to /boot/initrd_old. Also, if I need one more package in the initrd ( say new version of gcc or python etc), it is only matter of adding package name in one line... But I will do something much more compact in C. With maybe an option to do DefCon 4 style boot from USB key toolshed. I found USB keys to be useful for that role, when opened and with soldered in-line conenctor. With it it becomes small dongle that is plugged directly into motherboard and so practically part of the machine. Tha way, you get Terminator style sturdy machine that is capable of reboot no matter what just as motherboard, CPU and PSU stay functional. ;o) What I mean is that periodically, I snapshot/copy off my root (which includes everything that portage installs and its database so most of / usr and some of /var, all installed system binaries, scripts, and config) to an identically sized rootbak partition. (In this case it's another partition on the mdp/RAID, thus the weakness implied above if it should not be bootable by any available kernel, even with the appropriate options.) I can then continue updating the working root partition as I normally would. Yeah, but what do you do if your raid becomes non-functional for some reason ? I have four disks and two RAIDs. First is boot bartition RAID-1, which ebncompasess firs 1GB of each disk, second is RAID-5, which has the rest of the capacity. All partitions are typed as fd- self-detect RAID. On boot it doesn't matter. BIOS and GRUB see first partitions as if they were ordinary partitions with ext2 that happen to have exactly the same content. So, if one or more of the disks failed, I could boot with initrd from whatever disk is left... While in initramfs, I check and assemble both arrays and exec make-init ( or whatever its name it is- that util in klibc- it is effectively thingie that erases everything in /rootfs, remounts new root to / and starts init ) I won't be doing nVidia any time soon. Not until they come around to properly cooperating with the FLOSS community. YMMV and I know a lot of gamers especially value their games above their freedom. That's not my life and not my systems and therefore not my call, but what I run here IS, and if I wanted to be stuck with proprietaryware, I'd have not bothered dumping a decade's worth of experience on MS to start over with Linux! Well, at least every fresh version of their driver is available on Gentoo at the same instant it gets out. Even without it, nvidia's own installer can figure things out. Not so with Radeon. I needed 9.1 version of driver when latest in gentoo tree was 8.1. I downloaded the thing and died wrestling with damn scripts halfway through. I don't get what kind of machine did they write that thing for- it sure as hell wasn't anything like mine. Also, when it comes to OpenGL performance, nVidia is still the king as I understand. But for 2D stuff AMD seems to work fine. I managed to install ATI Catalyst controll center for GPU in my Foxconn A7DA-S ( chipset AMD 790GX + SB750 - HD3300 inbuilt GPU with 128MB cache RAM) it seems very good, even on on-board GPU. I have upgraded my dual setup to three-monitor setup ( 3x Samsung 204B, 3x1600x1200) and have had to add elcheapo 9400 card to existing dual-DVI 8800GT. Do you know about AMD/ATI Linux drivers- do they do such kind of stuff without extra wizardry ? Plus, I can blame you and those like you for holding up progress on xorg and the desktop environments, among other things, since there's a
Re: [gentoo-amd64] cant boot off sata disk
Daiajo Tibdixious wrote: When I boot without the CD, I don't think control is going to grub. There are no messages, it just sits there after 'boot from CD' comes up. I had the same problem with Asus M3N78 with Phenom 9850. I solved it by updating BIOS to latest version, reseting CMOS and unplugging and re-powering the system.
Re: [gentoo-amd64] Re: CFLAGS question from a AMD64 newbie
Duncan wrote: -combine is the one that causes the most problems, handled per trouble- package as mentioned in the other thread using /etc/portage/env/* files. The -fredorder-blocks-and-partition can in some cases as well, but if you don't have either of those in CXXFLAGS, you'll avoid a lot of the problem right there. Those are the only C(XX)FLAGS I have had issues with lately. The others have worked just fine. Do you have link to info on that per-package environment mechanism ? I couldn't find anything...
Re: [gentoo-amd64] hardware choice
Given your CPU choices, it is obvious that you are ignoring i7, I suspect beacise the price. In that case, I think you should reconsider AMD. I have a couple of Phenoms, which work really fine with Gentoo. However, if its lower frequency and smaller cache of 9850 and 9950 is what bothers you, you should consider Deneb, which is to come out any day now. 3GHz model should be quite cheap, it has 6MB of L3 which is not far from Intel's 8Mb and it also allegedly overclocks very well. People are getting to 4.4GHz on aircooling, which means machine should behave rock stable at 3.5GHz+ with really good cooler, like Thermalright IFX-14. Boards are relatively good and inexpensive, as well as DDR-II RAM is these days. I have stuffed 8GB in my box for something like €150. I have Foxcon A7DA-S, but Biostar models seem to be cheaper and record OC was done on such board ( 6.3 GHz on LN2), so it should perform well. Also, having a true QC can mean something with optimised multithread code. Intel's i7 is fine, but quite expensive and its smaller i5 won't be on the market for some time, and getting old C2D or Q2D seems a bit of waste these days... Daniel Iliev wrote: Hi, guys! I've decided to get an Intel based box, but I've not been following closely the hardware development for more than 5 years. Another trouble is that most of the people I can ask don't use Gentoo and they miss the point of much compiling. So, I need your help. 1) CPU: model,CPU Freq,FSB Freq,cache,technology E8400, 3.00GHz, 1333MHz, 6MB, 45nm Q8200, 2.33GHz, 1333MHz, 4MB, 45nm Q6600, 2.40GHz, 1066MHz, 8MB, 65nm Which one? (please, consider overclocking). On the local market those are in the same price range and I'm going to take Q6600 for the bigger cache (8MB). Is that the correct choice? 2) Main board. I was advised to get Asus P5K Premium (P35, ICH9) for Q6600. The thing is there are models from the P5Q series (like P5Q3) which have a newer chipset (P45, ICH10) but the same price. I can't understand why should I choose the premium mobo even it's an older model. Please, advise. 3) DDR2 600,800 or 1066? The thing confusing me is that the newer CPUs run at 1333MHz and the older (Q6600) at 1066. So, which DDR2? 4) Overclock I intend to overclock the system but not extremely. I've been told Q6600 would go up to 3GHz w/o any trouble. Is that true? How high would the other two CPUs go w/o additional cooling and compromising the stability? Thanks in advance! -- Best regards, Daniel
Re: [gentoo-amd64] hardware choice
Branko Badrljica wrote: SNIP Ooops. Sorry for top-post ;o/
Re: [gentoo-amd64] ASUS M2A-VM and kernel 2.6.27
David Relson wrote: Hi, Anybody using an ASUS M2A-VM mobo with a 2.6.27 kernel? SNIP I have had somewhat similar problems on Phenom. Do you have nvidia card on the machine ? If so, there is some parameter for the module that limits its use of IOMMU space. Also, I thint the problem was rectified in later revisions of the driver. Regards, Branko
Re: [gentoo-amd64] Re: Curious thing- linking against .so libs...
Nikos Chantziaras wrote: Branko Badrljica wrote: gcc -O2 -m32 -march=barcelona -pipe -L/usr/lib64 -lgdgeda -o tt tt.c (libgdgeda has just .so ) -m32 generates 32-bit code. /usr/lib64 is only for 64-bit binaries. Don't use -m32. Sorry, I forgot to remove -m32 from my example- it was remnant from previous tries. Everything is the same without it. But it seems something else is broken on my system, so I'll recompile everything and report later...
Re: [gentoo-amd64] CFLAGS question from a AMD64 newbie
Martin Herrman wrote: On Tue, Dec 9, 2008 at 1:23 PM, Sami Näätänen [EMAIL PROTECTED] wrote: to /etc/portage/package.keywords. With 4.3.2 I use: CFLAGS=-march=native -O2 -pipe With only a small effort, you get most of the benefits. So fine-tuning to the edge will give you issues to solve with only a very small percentage of performance increase in return. My 2 cents.. Martin My vote goes for this one, too. In general, anything higher than -O2 will bring you next to nothing in best case, on averagy you'll end with longer code that executes about the same and in some cases, result will be slower. BY far most important thing, at least in general seems to be to nail your march right, in oreder for compiler to be able to utilize all that cpu has to offer. For my Phenom -march=barcelona is optimal, but then I have problems with =gcc-4.2*, which has no separate K-10 backend, so -march=native is optimal - which means that gcc checks the CPU it is running on and makes the best available choice. If all your gcc compilers are of version 4* upwards, then also -combine might be useful. In short, CFLAGS=-march=native -O2 -pipe -combine is optimal for me... Regards, Branko
Re: [gentoo-amd64] Re: CFLAGS question from a AMD64 newbie
Duncan wrote: Well, you say you want stable, but then say you use ~arch, so I see you're not too stick in the mud. =:^) Here's mine, for a dual Opteron 290: CFLAGS=-march=opteron-sse3 -pipe -O2 -frename-registers -fweb -fmerge- all-constants -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize - fdirectives-only -freorder-blocks-and-partition -combine CXXFLAGS=-march=opteron-sse3 -pipe -O2 -frename-registers -fweb -fmerge- all-constants -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize - fdirectives-only You can look them up in the gcc manpage, or look back a year or so when I explained most of them, altho that was a couple gcc versions ago and they weren't quite the same. SNIP Been there, done praactically that, but it didn't make one quark of difference overall, except throwing gcc in a coma now and then, lenghtening compile problems and causing odd ( but rare ) bugs. I tried to time several C programs of mine and found that plain -O1 worked substantially better than plain -O2. After that, I said sod all and used plain vanilla CLFAGS on new gcc and with right march. Works fine, with same speed, faster compiles and much less headaches on average. In my experience, exotic CFLAGS can make a difference, but this varies wildldy from program part to program part, so unless one knows exactly what he is doing, he might be better of trusting compiler to use sane path with -O2. Besides that, portage doesn't have an option to compile just some part of the code with another, non_default CFLAGS... But my basic strategy is this: Because memory is so much slower than cache on a modern processor, in general it should pay to optimize for size even if it costs a few CPU cycles once in awhile. True, but he is asking for P4, which was notorious for having long pipelina and a neadache after cache miss, so for him -O2 or even -03 might be better in _some_ cases. But even so, IMVHO it is simply not worth the time and effort to fiddle with this, I'd use golden default with right march here also and be done with it.
Re: [gentoo-amd64] CFLAGS question from a AMD64 newbie
Sami Näätänen wrote: SNIP about -ftree-vectorize For example: float a[4]; float b[4]; SNIPped the rest of example Nice one. And probably with stellar speedup, since bunch of code gets replaced with one or two SSE instructions. But how relevant is it in real life examples ?
[gentoo-amd64] Curious thing- linking against .so libs...
I was trying to install nVidia's CUDA SDK for toying with GPU as
computing tool, but I soon found out that I can't compile anything.
I always get error's like can't find -lGL etc from compiler. So I took
a look where LIBPATHetc were set and everything seemed fine.
After that, I tried with trivial Hello world test source. I tried to
compile it, linking it with libGL.so. Compile failed with familiar
can't find
Then I tried to link it to another libraries I found in /usr/lib64. It
turns out that gcc wants to link to .a/.la files and completely seems to
ignore .so.
What gives ?
I have standard Gentoo config on Phenom system with typical desktop
setup. gcc is v-4.3.2.
Test case program:
#include stdio.h
void main ( int argc , char ** argv ) {
printf(Argc is %d, arg zero is %s and arg one is %s\n , argc,
argv[0] , argv[1] );
};
Compile attempts that work fine:
gcc -O2 -m32 -march=barcelona -pipe -o tt tt.c
gcc -O2 -m32 -march=barcelona -pipe -L/usr/lib64 -lresolv -o tt tt.c (
resolv lib has .la and .so version )
One that fails:
gcc -O2 -m32 -march=barcelona -pipe -L/usr/lib64 -lgdgeda -o tt tt.c
(libgdgeda has just .so )
Any ideas ?
Re: [gentoo-amd64] Completely remove BIND
Mark Haney wrote: Volker Armin Hemmann wrote: On Dienstag 02 Dezember 2008, Mark Haney wrote: I've done something really stupid and FUBAR'd my BIND install on what will be my new slave DNS server. The problem is that no matter what I do, when I try to start BIND the system claims 'named is already started'. What I want to do now is start over, tabula rasa, and rebuild BIND. I've tried emerge -C bind bind-tools but when I emerge it back, I still get the same problem. So, any decent, non-system-destructive ways to wipe BIND off the system. that is probably just a remnant of the init script. try /etc/init.d/named zap if that file still exists Nah, I've got bigger problems on this box. Somehow, GCC has been completely hosed. I'll need to rebuild gcc from a liveCD. I have a feeling the HDD on this box is failing. What system do you have ( x86, x86_64, normal or hardened kernel, selinux or not, which profile etc) ? If it's similar to any of mine, I could leave you binpkg of mine gcc on http server for download...
Re: [gentoo-amd64] quadcore
Eduardo Schoedler wrote: SNIP Hi Beso. http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options native This selects the CPU to tune for at compilation time by determining the processor type of the compiling machine. Using -mtune=native will produce code optimized for the local machine under the constraints of the selected instruction set. Using -march=native will enable all instruction subsets supported by the local machine (hence the result might not run on different machines). Best Regards, Eduardo. I have Phenom 9950 and use gcc-4.3.2 with CFLAGS=-march=barcelona -combine -O2 -pipe I tried to compile some small test code with -v -march=native and -v -march=barcelona, just to see if there is any difference. Compiled code seems to be the same, but that means nothing, since the example used was trivia But there is one difference in gcc's coments. With -march=native it says: .. COLLECT_GCC_OPTIONS='-v' '-O3' '-pipe' '-o' 'tt2' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/cc1 -quiet -v test.c -march=amdfam10 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 -mtune=amdfam10 -quiet -dumpbase test.c -auxbase test -O3 -version -o - | ... ...and with -march=barcelona: ... COLLECT_GCC_OPTIONS='-v' '-march=barcelona' '-O3' '-pipe' '-o' 'tt1' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/cc1 -quiet -v test.c -quiet -dumpbase test.c -march=barcelona -auxbase test -O3 -version -o - | .. whereas with -march=amdfam10: ... COLLECT_GCC_OPTIONS='-v' '-march=amdfam10' '-O3' '-pipe' '-o' 'tt1' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/cc1 -quiet -v test.c -quiet -dumpbase test.c -march=amdfam10 -auxbase test -O3 -version -o - | ... It seems that barcelona,amdfam10 and native are not exactly synonymous on my machine. amdfam10 seems to offer broadest description to which barcelona adds some extra details, but native seems to be most detailed,a s it adds details about cache size and cache line size, CMPXCHNG16B and LAHF/SAHF instructions. I also tried to compile unrar with those variations, but was unable to make difference in final binary- which admittedly doesn't prove anything...
[gentoo-amd64] Optimal AMD64 CFLAGS ?
ONe fo my machines still has K8 - AMD64 X2 6000+ in it. cat /proc/cpuinfo doesn't list SSE3 capabilities of the CPU, whereas AMD states that newer AMD64 (2005 and after that) are SSE3 capable and gcc-4.3.2 has -march=k8-sse3 Wikipedia states that AMD K8 is SSE3 capable, except for a few Intel-specific instructions. Maybe that is the reason why it isn't listed in /proc/cpuinfo ? Until now I have always used -march=k8, but now I wonder whether it would be safe to use k8-sse3. Has anyone tried this yet ?
Re: [gentoo-amd64] Can not compile gcc
Justin wrote: Barry Schwartz schrieb: Mansour Al Akeel [EMAIL PROTECTED] skribis: Any idea ? If you use ccache, try emptying it. I think there is something else wrong, because it fails in the configure phase. Send us an emerge --info output, please. I'm not an expert, but it seems that it was trying to compile 64-bit test code with -m32 flag: The log file: checking for x86_64-pc-linux-gnu-gcc... /var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -m32 Perhaps he should check his make.conf for CHOST and CLAGS ?
Re: [gentoo-amd64] Can not compile gcc
Mansour Al Akeel wrote: Just out of curiosity, how did you know that IA32_EMULATION is not enabled? Which message told you this ? He probably just suspected. Kernel's inability to run 32-bit code could be one of the reasons why the test code run failed. Other reason might be some linking error or somesuch...
Re: [gentoo-amd64] boot Gentoo from USB key
Branko Badrljica wrote: Be it as it may, on linux at least for traditional /dev/sdX links it doesn't work, but it should work for addressing the drive through /dev/disk/by-uuid or /dev/disk/by-path or /dev/disk/by-id. Self-correction is in order here; I forgot that I have tried that and it didn't work for me - I couldn't adress the boot disk as by-uuid/by-path/by-id parameter, only as a conventional /dev/sdX|hdX etc device. Branko -- gentoo-amd64@lists.gentoo.org mailing list
Re: [gentoo-amd64] boot Gentoo from USB key
I had the same two problems. WRT to grub, I don't remember anymore exactly what I have done, but I think I have copied sectors 1-62 from one conventional grub-bootable HDD to USB, Or maybe used some old HDD and formated it, parittioned it like the USB disk, copied /boot partition on it and set up grub on it, then copied sectors 1-62 back to USB disk. Sector 0 is for MBR codeand last few tens of bytes contain headers for first 4 partitions, so it shouldn't be touched and first partition begins with sector 63. Something like that. WRT to boot panics, kernel can't find USB key at boot since USB initialisation code needs more time for key to stabilise. Use kernel parameter rootdelay=10 for 10 second wait period for USB Hope this helps. BTW: You will in all likelyhood be dissapointed with USB key performance. Its R/W throughput is comparable to HDD only on paper. In reality it seems that USB can't cope efficiently with small sector-sized writes but also scattered reads seem to be far from optimal.Either that or USB driver really sucks on Linux. It is very useable as fallback though. Like having one USB key soldered directly on the MoBO and using it for boot if/when your HDD croaks or if something eats your main boot option... Regards, Branko Raffaele BELARDI wrote: In the process of building an amd64 diskless box, I am trying to make a bootable USB key with no success up to now. The first problem I encountered was related to ext2/vfat. I initially tried to format the key as ext2, but grub refuses to install on it. Even though I copied the /boot/grub/* directory into the key, and I see it is there, grub does not see it. The problem does not happen with vfat. So I worked around that and created two partitions in the key, a small vfat for the /boot and a 2Gb ext2 for the /. I copied the stage3 into the / with no problem. In the /boot I put the kernel image which I am already using on the same box, for now with discs still connected. All the modules are compiled in. When I boot from the key, grub enters the shell (although I did create the grub.conf and menu.1st, so I don't understand why it doesn't show the menu). I manually specify the kernel file location and root parameter: kernel /linux-2.6.24-gentoo-r4 root=/dev/sdg1 boot The kernel starts to load, but panics because it is unable to find the root partition. When it stops it shows the available partitions, these include all the hard disk partitions but no USB key partition. In fact, if I omit the 'root' parameter from the grub shell the boot works fine but it uses the hard disk root partition instead of the USB one. From the log on the screen the USB controller seems correctly detected, so I don't understand why it is not finding the root. While writing this one idea comes to my mind, maybe it is failing because I attach the key to a SDC/MMC/USB card reader? This evening I'll try to plug it into a different USB slot. Any other ideas welcome. raffaele -- gentoo-amd64@lists.gentoo.org mailing list
Re: [gentoo-amd64] boot Gentoo from USB key
Jason wrote: You may want to look at specifying root by it's UUID. This will prevent issues like the USB drive being /dev/sdg on one machine, /dev/sdb on another, and on reboot it all changing because the drives were detected in a different order. I have tried that and booting by UUID never worked for me except once in past on some particular kernel. I can put an UUID in /etc/fstab, but not as kernel boot parameter. I did some googling about that and found soemthing about that UUID as kernel parameter was a hack which was thrown out and that they don't intend to support it in the future. It's aong the lines of if you don't like anything about booting procedure, boot from initramfs, do what you have to do and then do pivot_root ... In the past, instead of 'rootdelay=', I add a wait to the init script, eg: while [ ! -e /dev/disk/by-uuid/1234-abcd-45gf-0659 ] do sleep 0.1 done And how do you do that when you are trying to get to root partition after kernel initialisation ? At that moment you can't run a script, since you don't have an access to any partition. You could use initrd/initramfs, but seems like a lot of complications for little gain... Branko -- gentoo-amd64@lists.gentoo.org mailing list
Re: [gentoo-amd64] boot Gentoo from USB key
Jason wrote: initrd is exactly how you do it. In the case of booting off of USB, there are too many variables (drive detection order, different hardware, etc) to handle on the kernel command line. An initrd gives you the flexibility to solve these problems. You could use initrd/initramfs, but seems like a lot of complications for little gain... I wouldn't call a portable, writable, boot from anywhere Linux OS on a thumbdrive a trivial gain. ;-) Jason. But you have the headache of interface at the old and new root across the pivot root. What happens if you execute something that was dynamically linked from intramfs and it decides to load and link another module with dlopen() from new root ? If you have that module and it belongs to the same version, then probably everything is fine. Otherwise it might not be. Also, opened files and extra nodes in /dev during intiramfs phase tend to cause a headache or two... Branko -- gentoo-amd64@lists.gentoo.org mailing list
Re: [gentoo-amd64] boot Gentoo from USB key
Hernan Lopez wrote: Hello, I´m did install UtutoXS2007 (based on Gentoo 2007), FreeBsd, and I don´t have this problem. Generally the USB key when exec the post the same is (sd0) and boot, then of boot the usb key, (sd0) is the principal Hard Disk, NOT THE USB KEY, this pass of (sd0) to (sd1). Partitions: Kingston 512Mb /boot=ext2 /=ext3 copy grub to /boot/grub and exec grub root (sd0,0) =where is the boot partition en USB setup (sd1) = then that change de sdx number to sd1. quit This is what OP has been trying to do withut success, since grub refused to do install to USB key since it can't find it as a disk to which you could install stage 1/1.5/2 and make it bootable. And going to FreeBSD is not the solution, useable for all of us. Also, it is not clear to me whether your is always at (sd0) even if you plug some SATA disks in your system and boot it and also if it goes for all other disks also. Be it as it may, on linux at least for traditional /dev/sdX links it doesn't work, but it should work for addressing the drive through /dev/disk/by-uuid or /dev/disk/by-path or /dev/disk/by-id. Regards, Branko This mode I have not any problem. Sorry by my english ;) BYe. Hernán López Pardo http://otrodiaparaser.blogspot.com Yo soy argentino, por eso uso Ututo en mi PC. www.ututo.org - Cara no es la ciencia; cara es la ignorancia. BERNARDO A. HOUSSAY - (1887-1971) No sigas mis pasos, no seas sombra de nadie; aprende de mis pasos y sigue tu camino DANIEL O. FERREYRA - (1967-2???) --- El mié 30-abr-08, Raffaele BELARDI [EMAIL PROTECTED] escribió: De: Raffaele BELARDI [EMAIL PROTECTED] Asunto: [gentoo-amd64] boot Gentoo from USB key Para: gentoo-amd64 gentoo-amd64@lists.gentoo.org Fecha: miércoles, 30 de abril de 2008, 3:43 am In the process of building an amd64 diskless box, I am trying to make a bootable USB key with no success up to now. The first problem I encountered was related to ext2/vfat. I initially tried to format the key as ext2, but grub refuses to install on it. Even though I copied the /boot/grub/* directory into the key, and I see it is there, grub does not see it. The problem does not happen with vfat. So I worked around that and created two partitions in the key, a small vfat for the /boot and a 2Gb ext2 for the /. I copied the stage3 into the / with no problem. In the /boot I put the kernel image which I am already using on the same box, for now with discs still connected. All the modules are compiled in. When I boot from the key, grub enters the shell (although I did create the grub.conf and menu.1st, so I don't understand why it doesn't show the menu). I manually specify the kernel file location and root parameter: kernel /linux-2.6.24-gentoo-r4 root=/dev/sdg1 boot The kernel starts to load, but panics because it is unable to find the root partition. When it stops it shows the available partitions, these include all the hard disk partitions but no USB key partition. In fact, if I omit the 'root' parameter from the grub shell the boot works fine but it uses the hard disk root partition instead of the USB one. From the log on the screen the USB controller seems correctly detected, so I don't understand why it is not finding the root. While writing this one idea comes to my mind, maybe it is failing because I attach the key to a SDC/MMC/USB card reader? This evening I'll try to plug it into a different USB slot. Any other ideas welcome. raffaele -- gentoo-amd64@lists.gentoo.org mailing list Tarjeta de crédito Yahoo! de Banco Supervielle. Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. www.tuprimeratarjeta.com.ar -- gentoo-amd64@lists.gentoo.org mailing list
