Re: [gentoo-user] Near freezes during large emerges
Apparently, though unproven, at 03:21 on Monday 17 January 2011, William Kenworthy did opine thusly: > > A > > modern desktop that swaps is unusable - enormous amounts of data has to > > be pulled back in from the drive. A web server that swaps is already > > thrashing so you always want to avoid that. > > > > Besides, RAM is cheap and a server with 24G is common place. So is 4G on > > a notebook. So your viewpoint is completely correct. > > > > The kernel does need some swap though - it needs wiggle room for when you > > DO run out of RAM, and a little bit of swap gives that. It also staves > > off that bastard demon spawn progeny of satan called the dreaded oom > > killer > > There is one case where ~2xram is still a good idea - when hibernating > to swap using (in my case) tuxonice - 2xram gives a reasonable safety > margin for hibernation plus existing swap contents. Yes, that's true. But modern notebooks often have 4G of RAM so that's a big partition for hibernating. Swap files probably function better for that case. I stopped hibernating a long time ago for that reason and now just suspend. Besides, the machine is seldom off for more than 4 hours -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Near freezes during large emerges
Apparently, though unproven, at 03:39 on Monday 17 January 2011, William Kenworthy did opine thusly: > On Sun, 2011-01-16 at 17:26 -0800, Mark Knecht wrote: > > On Sun, Jan 16, 2011 at 5:13 PM, William Kenworthy wrote: > > > On Sun, 2011-01-16 at 14:41 -0800, Grant wrote: > ... > > > I think that's well worded. He has insufficient memory when emerging. > > > > If he's really running short of DRAM Then he might also do well to > > boot to a console and do his emerges there. No memory given over to > > other things like KDE or browsers, etc. > > > > I am a bit surprised though that a -j1 type emerge would be running > > out of memory on a 3GB machine. I just finished emerge updates on a > > desktop with 4GB and only used 2.5GB which includes KDE, FIrefox and a > > > number of other things: > I have a diskless 3GB ram atom system (mythtv frontend) and I have to > arrange swap over nbd for gcc and glibc emerges - others just get very > slow when getting to limits, or get flaky unless -j1 is used. Havent > tried OO on it yet :) I'M flabbergasted. 3G is really a gigantic amount of memory and yet the machine still runs out of the stuff? Something is seriously wrong somewhere when code does this. I know memory is cheap and all, but still ... that's just excessive -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Near freezes during large emerges
On Mon, 2011-01-17 at 10:07 +0200, Alan McKinnon wrote: > Apparently, though unproven, at 03:39 on Monday 17 January 2011, William > Kenworthy did opine thusly: > > > On Sun, 2011-01-16 at 17:26 -0800, Mark Knecht wrote: > > > On Sun, Jan 16, 2011 at 5:13 PM, William Kenworthy > wrote: > > > > On Sun, 2011-01-16 at 14:41 -0800, Grant wrote: > > ... > > > > > I think that's well worded. He has insufficient memory when emerging. > > > > > > If he's really running short of DRAM Then he might also do well to > > > boot to a console and do his emerges there. No memory given over to > > > other things like KDE or browsers, etc. > > > > > > I am a bit surprised though that a -j1 type emerge would be running > > > out of memory on a 3GB machine. I just finished emerge updates on a > > > desktop with 4GB and only used 2.5GB which includes KDE, FIrefox and a > > > > > number of other things: > > I have a diskless 3GB ram atom system (mythtv frontend) and I have to > > arrange swap over nbd for gcc and glibc emerges - others just get very > > slow when getting to limits, or get flaky unless -j1 is used. Havent > > tried OO on it yet :) > > I'M flabbergasted. 3G is really a gigantic amount of memory and yet the > machine still runs out of the stuff? > > Something is seriously wrong somewhere when code does this. I know memory is > cheap and all, but still ... that's just excessive Your behind the times Alan - 3G was a huge amount 10 years ago ... Ahh, progress ... BillK
[gentoo-user] dynamic libraries - tree view ?
Hi, on one of my machines, googleearth crashes. An ldd /opt/googleearth/googleearth.bin | grep crypto shows that it tries to load both /usr/lib32/libcrypto.so.0.9.8 and /usr/lib32/libcrypto.so.1.0.0 On a different machine it only loads /usr/lib32/libcrypto.so.1.0.0 and does not crash. So, how can I find out the tree of dynamic libraries. Probably these dynamic libraries are not loaded directly but indirectly by some other dynamic library. Is there anything better than invoking ldd for each dynamic library which is loaded by an application to see how it got loaded? Many thanks for a hint, Helmut.
Re: [gentoo-user] Near freezes during large emerges
Apparently, though unproven, at 10:18 on Monday 17 January 2011, William Kenworthy did opine thusly: > On Mon, 2011-01-17 at 10:07 +0200, Alan McKinnon wrote: > > Apparently, though unproven, at 03:39 on Monday 17 January 2011, William > > > > Kenworthy did opine thusly: > > > On Sun, 2011-01-16 at 17:26 -0800, Mark Knecht wrote: > > > > On Sun, Jan 16, 2011 at 5:13 PM, William Kenworthy > > > > > > > > wrote: > > > > > On Sun, 2011-01-16 at 14:41 -0800, Grant wrote: > > > ... > > > > > > > I think that's well worded. He has insufficient memory when emerging. > > > > > > > > If he's really running short of DRAM Then he might also do well to > > > > boot to a console and do his emerges there. No memory given over to > > > > other things like KDE or browsers, etc. > > > > > > > > I am a bit surprised though that a -j1 type emerge would be running > > > > out of memory on a 3GB machine. I just finished emerge updates on a > > > > desktop with 4GB and only used 2.5GB which includes KDE, FIrefox and > > > > a > > > > > > > number of other things: > > > I have a diskless 3GB ram atom system (mythtv frontend) and I have to > > > arrange swap over nbd for gcc and glibc emerges - others just get very > > > slow when getting to limits, or get flaky unless -j1 is used. Havent > > > tried OO on it yet :) > > > > I'M flabbergasted. 3G is really a gigantic amount of memory and yet the > > machine still runs out of the stuff? > > > > Something is seriously wrong somewhere when code does this. I know memory > > is cheap and all, but still ... that's just excessive > > Your behind the times Alan - 3G was a huge amount 10 years ago ... Not so much :-) I too have db servers with 96G of ram. 5 of them, so I'm current. I'm just gobsmacked that a desktop needs 3G to build a compiler and system libs. It's consuming 2G to do that, I'll bet that 1.75G of that is pure wastage. Much like authors who proudly declare that they spent 7 years writing some magnum opus. It's a sure bet they were drunk of 6.5 of them :-) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Near freezes during large emerges
On Mon, 17 Jan 2011 10:07:45 +0200, Alan McKinnon wrote: > > I have a diskless 3GB ram atom system (mythtv frontend) and I have to > > arrange swap over nbd for gcc and glibc emerges - others just get very > > slow when getting to limits, or get flaky unless -j1 is used. Havent > > tried OO on it yet :) > > I'M flabbergasted. 3G is really a gigantic amount of memory and yet the > machine still runs out of the stuff? > If it's diskless, where are /tmp and /var/tmp mounted? If they use tmpfs the "memory" usage is understandable. If they use NFS the emerges must be unbearably slow. -- Neil Bothwick "When you play a Microsoft CD backwards you can hear demonic Voices... that's nothinng - when you play it forward it installs Windows" signature.asc Description: PGP signature
Re: [gentoo-user] Near freezes during large emerges
On 17/1/2011, at 8:07am, Alan McKinnon wrote: > ... > I'M flabbergasted. 3G is really a gigantic amount of memory and yet the > machine still runs out of the stuff? > > Something is seriously wrong somewhere when code does this. I know memory is > cheap and all, but still ... that's just excessive On my Mac, Safari alone can use close to 3gig.;) Stroller.
Re: [gentoo-user] invalid argument when trying to modprobe nvidia module
On Monday 17 January 2011 02:28:57 Dale wrote: > Peter, you got something weird going on with your system? Maybe I have, or did have at one time. I'll try it again at the next update. Thanks for the info. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] invalid argument when trying to modprobe nvidia module
On Sunday 16 January 2011 15:32:03 Alan McKinnon wrote: > Logic tells me you likely have something dodgy local to your machine > as you are the only one so this would be a good point to post the > error output you get. As I said to Dale, I'll check at the next upgrade. Thanks anyway. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Near freezes during large emerges
On Mon, 2011-01-17 at 09:22 +, Neil Bothwick wrote: > On Mon, 17 Jan 2011 10:07:45 +0200, Alan McKinnon wrote: > > > > I have a diskless 3GB ram atom system (mythtv frontend) and I have to > > > arrange swap over nbd for gcc and glibc emerges - others just get very > > > slow when getting to limits, or get flaky unless -j1 is used. Havent > > > tried OO on it yet :) > > > > I'M flabbergasted. 3G is really a gigantic amount of memory and yet the > > machine still runs out of the stuff? > > > > If it's diskless, where are /tmp and /var/tmp mounted? If they use tmpfs > the "memory" usage is understandable. If they use NFS the emerges must be > unbearably slow. > For normal usage, they are in tmpfs along with portage but I mount them over nfs for larger packages as memory is too constrained (just comment out the lines in fstab) - most packages take much less than a hundred mb or so for the storage unless its glibc or the like. After a reboot they are using no space (of course) and it just takes a sync to replace portage and I use http-replicator on the network so distfiles are not a problem. Lightning fast for smaller packages, but yes, much slower over nfs. That being said, its still faster (over nfs) for some packages than my old athlon desktop. However, swap over nbd is slwww, but works :) BillK
Re: [gentoo-user] Near freezes during large emerges
On Mon, 17 Jan 2011 19:40:15 +0800, William Kenworthy wrote: > > If it's diskless, where are /tmp and /var/tmp mounted? If they use > > tmpfs the "memory" usage is understandable. If they use NFS the > > emerges must be unbearably slow. > For normal usage, they are in tmpfs along with portage but I mount them > over nfs for larger packages as memory is too constrained (just comment > out the lines in fstab) - most packages take much less than a hundred mb > or so for the storage unless its glibc or the like. After a reboot they > are using no space (of course) and it just takes a sync to replace > portage and I use http-replicator on the network so distfiles are not a > problem. So root is on another (more powerful?) machine and mounted over NFS? Why not chroot into the root on the host machine and run the emerge there? -- Neil Bothwick Last words of a Windows user: = Why does that work now? signature.asc Description: PGP signature
Re: [gentoo-user] Near freezes during large emerges
On Mon, 2011-01-17 at 12:38 +, Neil Bothwick wrote: > On Mon, 17 Jan 2011 19:40:15 +0800, William Kenworthy wrote: > > > > If it's diskless, where are /tmp and /var/tmp mounted? If they use > > > tmpfs the "memory" usage is understandable. If they use NFS the > > > emerges must be unbearably slow. > > > For normal usage, they are in tmpfs along with portage but I mount them > > over nfs for larger packages as memory is too constrained (just comment > > out the lines in fstab) - most packages take much less than a hundred mb > > or so for the storage unless its glibc or the like. After a reboot they > > are using no space (of course) and it just takes a sync to replace > > portage and I use http-replicator on the network so distfiles are not a > > problem. > > So root is on another (more powerful?) machine and mounted over NFS? Why > not chroot into the root on the host machine and run the emerge there? > > The root is on a core2 duo, while the mythbackend and myth NFS mounts are on an old athlon. I did try and build the system there in a chroot but its a 32 bit install and I went with 64bit for the atom. Result was it didnt work - cant remember the details (was nearly a year ago :) but some packages were ok, others not - I was expecting it to work and had planned on managing upgrades via chroot. 64 bit was an experiment to see if it was worth migrating the rest of the systems over and this has been the only 32/64 hiccup so far but a mythtv frontend is not overly complex. The initial install was then done using gentoo on an 8G usb stick plugged into the machine and everything nfs mounted or on the usb stick. Worked a treat! For the new 4G machine I just copied it to a new directory and set it to PXE boot the new copy. The 3G machine is a Zotac ION N330 atom, while the 4G one is a Jetway ION-TOP N330 "bare bones" system - very similar hardware except for the 3G/4G memory difference. Only grief is getting the odd-ball CIR working on the ION-TOP. BillK
Re: [gentoo-user] Firmware loading problem
Hi Daniel,
Daniel Pielmeier [11-01-17 17:03]:
> 2011/1/17 :
> > I am running a vanilla linux kernel version 2.6.37 .
> >
> > Furthermore in
> >
> > /lib/firmware
> >
> > there is a folder called
> >
> > av7110
> >
> > which I think contains the firmware for that card.
>
> I don't think this card needs a firmware. You just enabled to much dvb
> related stuff in your kernel configuration which results in the
> creation of this folder. I need the av7110 stuff here for my FF DVB-S
> card.
>
> What problem do you have with this card, normally dmesg should spit
> something out if there is firmware missing.
The problem is, that the channel selection does not work in a proper
way:
Suppose you have the channels:
A B C D E F G
*
* => currently selected channel
Now (in vlc) you press N for "next". "B" gets selected. "N"...nothing
happens. "N" "D" gets selected. "P" (previous) ... "C" gets
selected. Sometimes you have to go even three steps forward and two
backward to get a certain channel selected.
A few channel sometime are not selectable at all
Same with mplayer...so it is not the player itsself...
What can I do?
Any help is very appreciated !:)
Best regards,
mcc
>
> > I read, that I need "hotplug" to load this firmware while booting.
> >
> > I did a
> >
> > emerge hotplug
> >
> > which runs fine but gave me warning that I should emerge coldplug.
> >
> > Ok, so I did an additional
> >
> > emerge coldplug
> >
> > which fails with
> >
> > solfire:/home/mccramer>sudo emerge coldplug
> > Calculating dependencies... done!
> > [ebuild N ] sys-apps/coldplug-20040920-r1
> > [blocks B ] sys-apps/coldplug ("sys-apps/coldplug" is blocking
> > sys-fs/udev-151-r4)
> > [blocks B ] >=sys-fs/udev-089 (">=sys-fs/udev-089" is blocking
> > sys-apps/coldplug-20040920-r1)
> >
> > * Error: The above package list contains packages which cannot be
> > * installed at the same time on the same system.
> >
> > (sys-apps/coldplug-20040920-r1, ebuild scheduled for merge) pulled in by
> > coldplug
> >
> >
> > If I understand this correctly, I have to downgrade udev from udev-151
> > down to udev-089 to be able to install coldplug.
> >
> > Is this really needed? How can I install the firmware?
>
> I think the functionality from hot- and coldplug is now provided by
> udev thus the blocker.
>
> --
> Daniel Pielmeier
>
Re: [gentoo-user] modprobe warnings
On Sat, Jan 15, 2011 at 8:48 PM, David Relson wrote: > My /etc/modprobe.d directory is under configuration management using > subversion. Whenever modprobe runs, it reads the files in the .svn > directory and complains about all the stuff it doesn't understand, for > example: > > Jan 15 08:57:22 osage modprobe: WARNING: /etc/modprobe.d/.svn/entries > line 266: ignoring bad line starting with ' > > How can I turn off these warnings? > > > Regards, > > David > > Hi, Give a try to mercurial. # emerge mercurial # vim /root/.hgrc [ui] Name Surname # cd /etc # hg init # hg add # hg status # hg commit -m "Start!" And You are ready to go :) Good luck. -- mv
[gentoo-user] Microcode update AMD
Hi, I have two questions: 1) Do I have to enable microcode updates in the BIOS of my Crosshair IV Formula to activate microcodes push in the CPU by the module "microcode" ? (AMD Phenom X6 1090T) 2) Does anyone know, what these microcodes do? They are fixes for... ...what? Thank you very much in advance for any help! Best regards, mcc
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
On 16 January 2011 22:30, Nikos Chantziaras wrote: > On 01/16/2011 05:18 PM, Daniel Tihelka wrote: >> >> Hallo, >> >> after update to 2.6.36-r5 kernel, xorg 1.9.2, mesa-7.9 and xf86-video- >> ati-6.13.2 (all from gentoo portage), the hw graphics acceleration stopped >> working. The problem seems to be in drm kernel module, as it is claimed by >> X.org (the part of X.org log): >> >> [...] >> >> And the kernel seems to use them (when started with boot options >> 'video=vesafb:ywrap,mtrr:3 vga=792') > > Remove the above and try this: > > video=vesafb:off radeon.modeset=1 radeon.dynpm=1 Building KMS related drivers in the kernel as opposed to selecting them as modules and removing framebuffer modules may also address the OP's problem (which I suspect is caused because KMS has not loaded *before* xorg starts). > Then, try deleting your xorg.conf (if you have one) and do: > > eselect mesa set r300 gallium > > Also make sure that mesa is emerged with the "video_cards_r300" USE flag > enabled. "video_cards_radeon" is *not* enough. Your make.conf should > probably contain this: > > VIDEO_CARDS="fbdev vesa radeon r300" Hmm ... unless this USE flag shows up in later versions or overlays, only radeon is available for mesa-7.9 # emerge -1aDv mesa These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/mesa-7.9 USE="classic gallium nptl -debug -gles -llvm -motif -pic (-selinux)" VIDEO_CARDS="radeon -intel -mach64 -mga -nouveau -r128 -savage -sis -tdfx -via -vmware" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] No Quitting. -- Regards, Mick
Re: [gentoo-user] Microcode update AMD
- Original Message > I have two questions: > > 1) Do I have to enable microcode updates in the BIOS of my Crosshair > IV Formula to activate microcodes push in the CPU by the module > "microcode" ? (AMD Phenom X6 1090T) Not sure about BIOS, but the Linux Kernel you are running will certainly need support enabled too. > 2) Does anyone know, what these microcodes do? They are fixes for... > ...what? The Intel and AMD processors are more abstract than physical now. With i486 and earlier the processors were typically hard wired; hardware "bug" fixes could not be pushed out. Intel's Pentium (and I don't know which AMD) started using micro-code to program the processor. This enabled them to push out "hardware" bug fixes for the processors. So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to micro-code first, then it gets processed, and the result translated back to the expected instruction result - essentially, emulating the x86 instruction set in the processor. That's the simple version. So now when they discover a bug in the hardware they can push out a micro-code update to either fix the "hardware" (microcode) bug or work around a hardware (physical hardware) bug. Ben
[gentoo-user] Re: dynamic libraries - tree view ?
On 01/17/2011 12:22 AM, Helmut Jarausch wrote: Hi, on one of my machines, googleearth crashes. An ldd /opt/googleearth/googleearth.bin | grep crypto shows that it tries to load both /usr/lib32/libcrypto.so.0.9.8 and /usr/lib32/libcrypto.so.1.0.0 On a different machine it only loads /usr/lib32/libcrypto.so.1.0.0 and does not crash. So, how can I find out the tree of dynamic libraries. Probably these dynamic libraries are not loaded directly but indirectly by some other dynamic library. Is there anything better than invoking ldd for each dynamic library which is loaded by an application to see how it got loaded? Good question, and maybe someone has a better idea than mine, but I just grep through the entire library directory until I find the name of the old library: # grep -r libcrypto.so.0 /usr/lib32/* Binary file /usr/lib32/libcrypto.so.0.9.8 matches Binary file /usr/lib32/libssl.so.0.9.8 matches You may find at least one other library that matches. I'd do the same grep through /usr/bin and /usr/lib64 also.
Re: [gentoo-user] Microcode update AMD
BRM [11-01-17 19:16]: > - Original Message > > > I have two questions: > > > > 1) Do I have to enable microcode updates in the BIOS of my Crosshair > > IV Formula to activate microcodes push in the CPU by the module > > "microcode" ? (AMD Phenom X6 1090T) > > Not sure about BIOS, but the Linux Kernel you are running will certainly need > support enabled too. > > > 2) Does anyone know, what these microcodes do? They are fixes for... > > ...what? > > The Intel and AMD processors are more abstract than physical now. With i486 > and > earlier the processors were typically hard wired; hardware "bug" fixes could > not > be pushed out. > Intel's Pentium (and I don't know which AMD) started using micro-code to > program > the processor. This enabled them to push out "hardware" bug fixes for the > processors. > > So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to > micro-code first, then it gets processed, and the result translated back to > the > expected instruction result - essentially, emulating the x86 instruction set > in > the processor. That's the simple version. > > So now when they discover a bug in the hardware they can push out a > micro-code > update to either fix the "hardware" (microcode) bug or work around a > hardware > (physical hardware) bug. > > Ben > > Hi Ben, thanks for your explanation... I meant: What is fixed the uc-patches? Does "mov" only except "17" as argument...or... I searched AMD for a changelog or something like but I ound nothing... Best regards, mcc
Re: [gentoo-user] Microcode update AMD
On Mon, Jan 17, 2011 at 10:10 AM, BRM wrote: > - Original Message > >> I have two questions: >> >> 1) Do I have to enable microcode updates in the BIOS of my Crosshair >> IV Formula to activate microcodes push in the CPU by the module >> "microcode" ? (AMD Phenom X6 1090T) > > Not sure about BIOS, but the Linux Kernel you are running will certainly need > support enabled too. > >> 2) Does anyone know, what these microcodes do? They are fixes for... >> ...what? > > The Intel and AMD processors are more abstract than physical now. With i486 > and > earlier the processors were typically hard wired; hardware "bug" fixes could > not > be pushed out. > Intel's Pentium (and I don't know which AMD) started using micro-code to > program > the processor. This enabled them to push out "hardware" bug fixes for the > processors. > > So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to > micro-code first, then it gets processed, and the result translated back to > the > expected instruction result - essentially, emulating the x86 instruction set > in > the processor. That's the simple version. > > So now when they discover a bug in the hardware they can push out a micro-code > update to either fix the "hardware" (microcode) bug or work around a hardware > (physical hardware) bug. > > Ben Ben, Do you know how security on these updates is handled? Seems to me this is an area rife for exploitation so I've been very hesitant to use them until I understood more. Cheers, Mark
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: > Hi, > > I have two questions: > > 1) Do I have to enable microcode updates in the BIOS of my Crosshair > IV Formula to activate microcodes push in the CPU by the module > "microcode" ? (AMD Phenom X6 1090T) > you ALWAYS have to activate that! This way the bios updates the microcode with the latest version it is carrying around. Not activating that option is really, really stupid. For many reasons. It is also (almost) completely unrelated to that blob. That blob is for the OS so you can upload an even more recent version of microcode. In case your bios sucks. For example. > 2) Does anyone know, what these microcodes do? They are fixes for... > ...what? the CPU. All CPUs use microcode. For decades. Google, or go straight to wikipedia. http://en.wikipedia.org/wiki/Microcode
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 10:48:36 Mark Knecht wrote: > On Mon, Jan 17, 2011 at 10:10 AM, BRM wrote: > > - Original Message > > > >> I have two questions: > >> > >> 1) Do I have to enable microcode updates in the BIOS of my Crosshair > >> IV Formula to activate microcodes push in the CPU by the module > >> "microcode" ? (AMD Phenom X6 1090T) > > > > Not sure about BIOS, but the Linux Kernel you are running will certainly > > need support enabled too. > > > >> 2) Does anyone know, what these microcodes do? They are fixes for... > >> ...what? > > > > The Intel and AMD processors are more abstract than physical now. With > > i486 and earlier the processors were typically hard wired; hardware > > "bug" fixes could not be pushed out. > > Intel's Pentium (and I don't know which AMD) started using micro-code to > > program the processor. This enabled them to push out "hardware" bug > > fixes for the processors. > > > > So what happens is the x86 instruction (e.g. mov ax, bx) gets translated > > to micro-code first, then it gets processed, and the result translated > > back to the expected instruction result - essentially, emulating the > > x86 instruction set in the processor. That's the simple version. > > > > So now when they discover a bug in the hardware they can push out a > > micro-code update to either fix the "hardware" (microcode) bug or work > > around a hardware (physical hardware) bug. > > > > Ben > > Ben, >Do you know how security on these updates is handled? Seems to me > this is an area rife for exploitation so I've been very hesitant to > use them until I understood more. you can not not use them because alsmost all bios load the microcode automatically.
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 19:34:08 meino.cra...@gmx.de wrote: > BRM [11-01-17 19:16]: > > - Original Message > > > > > I have two questions: > > > 1) Do I have to enable microcode updates in the BIOS of my > > > Crosshair > > > > > > IV Formula to activate microcodes push in the CPU by the > > > module > > > "microcode" ? (AMD Phenom X6 1090T) > > > > Not sure about BIOS, but the Linux Kernel you are running will certainly > > need support enabled too. > > > > > 2) Does anyone know, what these microcodes do? They are fixes > > > for... > > > > > > ...what? > > > > The Intel and AMD processors are more abstract than physical now. With > > i486 and earlier the processors were typically hard wired; hardware > > "bug" fixes could not be pushed out. even the 68000 used microcode... > > Intel's Pentium (and I don't know which AMD) started using micro-code to > > program the processor. This enabled them to push out "hardware" bug > > fixes for the processors sure that microcode was not introduced to x86 a lot earlier? > > > > So what happens is the x86 instruction (e.g. mov ax, bx) gets translated > > to micro-code first, then it gets processed, and the result translated > > back to the expected instruction result - essentially, emulating the > > x86 instruction set in the processor. That's the simple version. > > > > So now when they discover a bug in the hardware they can push out a > > micro-code update to either fix the "hardware" (microcode) bug or work > > around a hardware (physical hardware) bug. > > > > Ben > > Hi Ben, > > thanks for your explanation... > I meant: What is fixed the uc-patches? Does "mov" only except "17" as > argument...or... > I searched AMD for a changelog or something like but I ound nothing... they never publish changelogs for microcode.
Re: [gentoo-user] disk error, where?
Stefan G. Weichinger [11-01-17 20:04]: > > Would someone help me out on this issue? > > I have a flaky disk in a server, and dmesg says: > > end_request: I/O error, dev sdb, sector 1835240116 > > Now i have this layout: > > # fdisk -l /dev/sdb > > Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes > 255 heads, 63 sectors/track, 121601 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x > >Device Boot Start End Blocks Id System > /dev/sdb1 1 13 104391 fd Linux raid > autodetect > /dev/sdb2 14 50 297202+ 82 Linux swap / Solaris > /dev/sdb3 51248319543072+ fd Linux raid > autodetect > /dev/sdb42484 121601 9568153355 Extended > /dev/sdb52484 106917 838866073+ 8e Linux LVM > /dev/sdb6 106918 121601 117949198+ fd Linux raid > autodetect > > > My question (apart from the fact that I evacuate all on that > non-raid-LVM-partition right now!): > > In which partition is that "sector 1835240116" ? > > Sorry for this maybe stupid question ... > > Thanks, Stefan > Hi Stefan, small shot into the deep dark : :) As far as I know, you can switch fdisk to display either to diplay units in cylinders or in sectors. Usage: fdisk [options] change partition table fdisk [options] -l list partition table(s) fdisk -s give partition size(s) in blocks Options: -b sector size (512, 1024, 2048 or 4096) -c[=] compatible mode: 'dos' or 'nondos' (default) -hprint this help text -u[=] display units: 'cylinders' or 'sectors' (default) -vprint program version -Cspecify the number of cylinders -Hspecify the number of heads -Sspecify the number of sectors per track When switched to display sector units it is only a matter of counting to find the partition in question I would guess... Good luck! Best regards, mcc
Re: [gentoo-user] Microcode update AMD
Volker Armin Hemmann [11-01-17 20:16]: > On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: > > Hi, > > > > I have two questions: > > > > 1) Do I have to enable microcode updates in the BIOS of my Crosshair > > IV Formula to activate microcodes push in the CPU by the module > > "microcode" ? (AMD Phenom X6 1090T) > > > > you ALWAYS have to activate that! This way the bios updates the microcode > with > the latest version it is carrying around. Not activating that option is > really, really stupid. For many reasons. It is also (almost) completely > unrelated to that blob. > > That blob is for the OS so you can upload an even more recent version of > microcode. In case your bios sucks. For example. > > > 2) Does anyone know, what these microcodes do? They are fixes for... > > ...what? > > the CPU. All CPUs use microcode. For decades. Google, or go straight to > wikipedia. > http://en.wikipedia.org/wiki/Microcode > Cool down. I know for waht microcodes are good for. My question means: What specific bugs/features of my CPU get fixed, when I use the microcde included in the recent microcode update???
Re: [gentoo-user] disk error, where?
Am 17.01.2011 20:15, schrieb meino.cra...@gmx.de: > When switched to display sector units it is only a matter of counting > to find the partition in question I would guess... Errm, yes, I thought of this as well, as always *after* posting to the ML. # fdisk -l -u /dev/sdb [..] /dev/sdb439889395 1953520064 9568153355 Extended /dev/sdb539889458 1717621604 838866073+ 8e Linux LVM /dev/sdb6 1717621668 1953520064 117949198+ fd Linux raid autodetect So sector 1835240116 should be part of sdb6, right? So my hopes are high to be able to cp all the sdb5-content while the hdd is still alive (yes, I have backups, but not up to the latest ...) Thanks, Stefan
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 20:19:04 meino.cra...@gmx.de wrote: > Volker Armin Hemmann [11-01-17 20:16]: > > On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: > > > Hi, > > > > > > I have two questions: > > > 1) Do I have to enable microcode updates in the BIOS of my > > > Crosshair > > > > > > IV Formula to activate microcodes push in the CPU by the > > > module > > > "microcode" ? (AMD Phenom X6 1090T) > > > > you ALWAYS have to activate that! This way the bios updates the > > microcode with the latest version it is carrying around. Not activating > > that option is really, really stupid. For many reasons. It is also > > (almost) completely unrelated to that blob. > > > > That blob is for the OS so you can upload an even more recent version of > > microcode. In case your bios sucks. For example. > > > > > 2) Does anyone know, what these microcodes do? They are fixes > > > for... > > > > > > ...what? > > > > the CPU. All CPUs use microcode. For decades. Google, or go straight to > > wikipedia. > > http://en.wikipedia.org/wiki/Microcode > > Cool down. I know for waht microcodes are good for. > > My question means: What specific bugs/features of my CPU get fixed, > when I use the microcde included in the recent microcode update??? nobody knows.
Re: [gentoo-user] disk error, where?
Stefan G. Weichinger [11-01-17 20:44]:
> Am 17.01.2011 20:15, schrieb meino.cra...@gmx.de:
> > When switched to display sector units it is only a matter of counting
> > to find the partition in question I would guess...
>
> Errm, yes, I thought of this as well, as always *after* posting to the ML.
>
>
> # fdisk -l -u /dev/sdb
>
> [..]
>
> /dev/sdb439889395 1953520064 9568153355 Extended
> /dev/sdb539889458 1717621604 838866073+ 8e Linux LVM
> /dev/sdb6 1717621668 1953520064 117949198+ fd Linux raid
> autodetect
>
> So sector 1835240116 should be part of sdb6, right?
>
> So my hopes are high to be able to cp all the sdb5-content while the hdd
> is still alive (yes, I have backups, but not up to the latest ...)
>
> Thanks, Stefan
>
Hi Stefan,
The chances are high, that only one file is "killed" by this, since
most of the data on a hd is not of organisational matter.
Simply try the following on sdb6
cd "sdb6"
sudo find . -type f exec cat\{\} > /dev/null \;
Regardless of the time it will cost to cat ALL files, it will
fail on that file with the bad sector...
Good luck!
mcc
Re: [gentoo-user] Microcode update AMD
Volker Armin Hemmann [11-01-17 20:52]: > On Monday 17 January 2011 20:19:04 meino.cra...@gmx.de wrote: > > Volker Armin Hemmann [11-01-17 20:16]: > > > On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: > > > > Hi, > > > > > > > > I have two questions: > > > > 1) Do I have to enable microcode updates in the BIOS of my > > > > Crosshair > > > > > > > > IV Formula to activate microcodes push in the CPU by the > > > > module > > > > "microcode" ? (AMD Phenom X6 1090T) > > > > > > you ALWAYS have to activate that! This way the bios updates the > > > microcode with the latest version it is carrying around. Not activating > > > that option is really, really stupid. For many reasons. It is also > > > (almost) completely unrelated to that blob. > > > > > > That blob is for the OS so you can upload an even more recent version of > > > microcode. In case your bios sucks. For example. > > > > > > > 2) Does anyone know, what these microcodes do? They are fixes > > > > for... > > > > > > > > ...what? > > > > > > the CPU. All CPUs use microcode. For decades. Google, or go straight to > > > wikipedia. > > > http://en.wikipedia.org/wiki/Microcode > > > > Cool down. I know for waht microcodes are good for. > > > > My question means: What specific bugs/features of my CPU get fixed, > > when I use the microcde included in the recent microcode update??? > > nobody knows. > So...why should I try unknown code patched into my CPU. It looks like "install this virus" from the security point of view, doesn't ist?
Re: [gentoo-user] disk error, where?
Stefan G. Weichinger writes: > Would someone help me out on this issue? > > I have a flaky disk in a server, and dmesg says: > > end_request: I/O error, dev sdb, sector 1835240116 Uh-oh. I suggest emerging badblocks, and then do a 'badblocks /dev/sdb' to see which and how many blocks are defective. You can also replace sdb by sdb6 or whatever partition you are specifically interested in. You also might want to use the -n option (non-destructive write mode), but only on partitions that are not mounted / used. smartmontools also offer some diagnostic features. Including a full surface check, but it stops at the first error. At least you know then until which sectory the drivs is still okay: smartctl -tlong /dev/sdb wait... smartctl -l selftest /dev/sda smartctl -a /dev/sdb also shows lots of info, including the number of bad and reallocated sectors. If cou can, make a copy of the partiton(s) drive with ddrescue (or dd- rescue, don't know which one is better, but both are more tolerable to errors than dd is). I had drives with single errors that seems to work fine for years after this, but I do nto put important data on them. And it is also possible that you had a head crash and more and more sectors become defective. So do the backup fast, or do not use the drive until you do. Good luck! > Now i have this layout: > > # fdisk -l /dev/sdb > > Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes > 255 heads, 63 sectors/track, 121601 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x > >Device Boot Start End Blocks Id System > /dev/sdb1 1 13 104391 fd Linux raid > autodetect > /dev/sdb2 14 50 297202+ 82 Linux swap / > Solaris /dev/sdb3 51248319543072+ fd Linux > raid autodetect > /dev/sdb42484 121601 9568153355 Extended > /dev/sdb52484 106917 838866073+ 8e Linux LVM > /dev/sdb6 106918 121601 117949198+ fd Linux raid > autodetect > > > My question (apart from the fact that I evacuate all on that > non-raid-LVM-partition right now!): > > In which partition is that "sector 1835240116" ? sdb6 I think. Your fdisk uses units of 16065 * 512 bytes, while a sector has 512 bytes. 1835240116 / 16065 = 114238, this gives sdb6. Or change fdisk's units to sectors: fdisk /dev/sdb u u p Wonko
Re: [gentoo-user] Microcode update AMD
As he said in the previous message, there are almost never changelogs for microcode updates. I do, however, have to disagree with *never* disabling microcode updates. If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4 cores via a misconfiguration that enabled it with ACC. AMD later corrected this issue with a microcode update. True, some motherboards worked around that fix a different way, but if you had a first gen board with ACC support you *had* to have the old microcode for it to work. The update killed your free core :) On Jan 17, 2011 3:06 PM, wrote: > Volker Armin Hemmann [11-01-17 20:16]: >> On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: >> > Hi, >> > >> > I have two questions: >> > >> > 1) Do I have to enable microcode updates in the BIOS of my Crosshair >> > IV Formula to activate microcodes push in the CPU by the module >> > "microcode" ? (AMD Phenom X6 1090T) >> > >> >> you ALWAYS have to activate that! This way the bios updates the microcode with >> the latest version it is carrying around. Not activating that option is >> really, really stupid. For many reasons. It is also (almost) completely >> unrelated to that blob. >> >> That blob is for the OS so you can upload an even more recent version of >> microcode. In case your bios sucks. For example. >> >> > 2) Does anyone know, what these microcodes do? They are fixes for... >> > ...what? >> >> the CPU. All CPUs use microcode. For decades. Google, or go straight to >> wikipedia. >> http://en.wikipedia.org/wiki/Microcode >> > > Cool down. I know for waht microcodes are good for. > > My question means: What specific bugs/features of my CPU get fixed, > when I use the microcde included in the recent microcode update??? > > > >
Re: [gentoo-user] Microcode update AMD
On Mon, Jan 17, 2011 at 11:57 AM, wrote: > So...why should I try unknown code patched into my CPU. > > It looks like "install this virus" from the security point > of view, doesn't ist? That was my point. I think the idea Volker is suggesting is the micro-code updates go from AMD (who understands what the issue is with their processor) to the BIOS manufacturer (Phoenix or whoever did yous) and get incorporated in a secure way. They are 'known good' in the BIOS update we receive and write into a Flash drive. It's just a choice whether you want to use that part of BOIS or now. After all, _any_ BIOS update represents an opportunity for someone to really mess you machine up. Doesn't matter if it's micro-code or something else. That's my reading of this so far - Mark
Re: [gentoo-user] disk error, where?
On Mon, Jan 17, 2011 at 11:38 AM, Stefan G. Weichinger wrote: > Am 17.01.2011 20:15, schrieb meino.cra...@gmx.de: >> When switched to display sector units it is only a matter of counting >> to find the partition in question I would guess... > > Errm, yes, I thought of this as well, as always *after* posting to the ML. > > > # fdisk -l -u /dev/sdb > > [..] > > /dev/sdb4 39889395 1953520064 956815335 5 Extended > /dev/sdb5 39889458 1717621604 838866073+ 8e Linux LVM > /dev/sdb6 1717621668 1953520064 117949198+ fd Linux raid > autodetect > > So sector 1835240116 should be part of sdb6, right? > > So my hopes are high to be able to cp all the sdb5-content while the hdd > is still alive (yes, I have backups, but not up to the latest ...) > > Thanks, Stefan > > It appears that the partition is part of a RAID? Has the RAID itself protected you? Can you fail the drive, remove it, from the RAID, buy a new drive and get going again? I think any RAID other than RAID0 will withstand a single drive failure. right? Once you had the RAID fixed you could deal with the other partitions on what appears to be a failing drive. No fun... - Mark
Re: [gentoo-user] disk error, where?
Am 2011-01-17 21:15, schrieb Mark Knecht: > > It appears that the partition is part of a RAID? Has the RAID itself > protected you? Can you fail the drive, remove it, from the RAID, buy a > new drive and get going again? I think any RAID other than RAID0 will > withstand a single drive failure. right? sdb6 is part of a mirror, yes. No loss of data so far, no failed arrays, nothing. Just that smartd-test failing last night and now I have to act. The 3 arrays are OK and also fully on tape, that's not the problem. My concern is about /dev/sdb5, which is the one and only PV inside the lvm2-VG VG01 (oh my, I fear Volker right now telling me about that LVM-stuff ;-) ). And VG01 hosts a few LVs, most of them easy to restore or rebuild, one of them containing around 700GBs of mythtv-recordings. Most of those are also on tape, but not all of them (because I run out of space with tapes etc). Nothing really important, sure, it's "just TV", but nice-to-have anyway. So I am moving stuff from that LV to another new RAID-array, just to save that data before sdb maybe crashes completely. In general I am rebuilding that whole box lately, adding drives etc. but I am not yet where I want to get because I hit one obstacle after the other. I suspect the power-supply to be faulty ( I also get chksum-errors in a zfs-fuse-pool, before and after using new disks ... so ...) RAM is good, at least as far memtest86+ is able to tell. *sigh* Thanks, Stefan
Re: [gentoo-user] disk error, where?
Am 2011-01-17 21:13, schrieb Alex Schuster: > Uh-oh. I suggest emerging badblocks, and then do a 'badblocks /dev/sdb' to > see which and how many blocks are defective. You can also replace sdb by > sdb6 or whatever partition you are specifically interested in. > You also might want to use the -n option (non-destructive write mode), but > only on partitions that are not mounted / used. > > smartmontools also offer some diagnostic features. Including a full surface > check, but it stops at the first error. At least you know then until which > sectory the drivs is still okay: > smartctl -tlong /dev/sdb > wait... > smartctl -l selftest /dev/sda > > smartctl -a /dev/sdb also shows lots of info, including the number of bad > and reallocated sectors. > > If cou can, make a copy of the partiton(s) drive with ddrescue (or dd- > rescue, don't know which one is better, but both are more tolerable to > errors than dd is). > > I had drives with single errors that seems to work fine for years after > this, but I do nto put important data on them. And it is also possible that > you had a head crash and more and more sectors become defective. So do the > backup fast, or do not use the drive until you do. Good luck! Thanks, Alex ... I will use badblocks and smartctl in more detail after having the data off the drive (as mentioned in my reply to Mark's posting right now).
Re: [gentoo-user] disk error, where?
On Monday 17 January 2011 19:59:57 Stefan G. Weichinger wrote: > Would someone help me out on this issue? > > I have a flaky disk in a server, and dmesg says: > > end_request: I/O error, dev sdb, sector 1835240116 > > Now i have this layout: > > # fdisk -l /dev/sdb > > Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes > 255 heads, 63 sectors/track, 121601 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x > >Device Boot Start End Blocks Id System > /dev/sdb1 1 13 104391 fd Linux raid > autodetect > /dev/sdb2 14 50 297202+ 82 Linux swap / Solaris > /dev/sdb3 51248319543072+ fd Linux raid > autodetect > /dev/sdb42484 121601 9568153355 Extended > /dev/sdb52484 106917 838866073+ 8e Linux LVM > /dev/sdb6 106918 121601 117949198+ fd Linux raid > autodetect > > > My question (apart from the fact that I evacuate all on that > non-raid-LVM-partition right now!): > > In which partition is that "sector 1835240116" ? > > Sorry for this maybe stupid question ... > > Thanks, Stefan man debugfs: bmap filespec logical_block Print the physical block number corresponding to the logical block number logical_block in the inode filespec. icheck block ... Print a listing of the inodes which use the one or more blocks specified on the command line. ncheck inode_num ... Take the requested list of inode numbers, and print a listing of pathnames to those inodes. if you are using extX-
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 15:13:54 Jason Weisberger wrote: > As he said in the previous message, there are almost never changelogs for > microcode updates. > > I do, however, have to disagree with *never* disabling microcode updates. > If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4 > cores via a misconfiguration that enabled it with ACC. AMD later corrected > this issue with a microcode update. True, some motherboards worked around > that fix a different way, but if you had a first gen board with ACC support > you *had* to have the old microcode for it to work. The update killed your > free core :) a 'free core' that is probably broken in mysterious and hard to find but nonetheless very dangerous ways. Thanks.
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 12:12:08 Mark Knecht wrote: > On Mon, Jan 17, 2011 at 11:57 AM, wrote: > > > > So...why should I try unknown code patched into my CPU. > > > > It looks like "install this virus" from the security point > > of view, doesn't ist? > > That was my point. > > I think the idea Volker is suggesting is the micro-code updates go > from AMD (who understands what the issue is with their processor) to > the BIOS manufacturer (Phoenix or whoever did yous) and get > incorporated in a secure way. They are 'known good' in the BIOS update > we receive and write into a Flash drive. It's just a choice whether > you want to use that part of BOIS or now. > > After all, _any_ BIOS update represents an opportunity for someone to > really mess you machine up. Doesn't matter if it's micro-code or > something else. > > That's my reading of this so far > > - Mark also the microcode you download is from amd's servers. If you don't that stuff - you can't use CPUs because they might be loaded with 'hacked' microcode from the start. Or motherboards, because the bios might be hacked. Or the linux kernel because maybe somebody incorporated code into linux. gcc and binutils that looks innocent but combined will kill your machine. On the other hand, CPU bugs can result in miscalculations. Very, very expensive miscalculations. So what is worse - an instable, incorrect CPU or paranoia?
Re: [gentoo-user] disk error, where?
On Monday 17 January 2011 21:46:39 Stefan G. Weichinger wrote: > Am 2011-01-17 21:13, schrieb Alex Schuster: > > Uh-oh. I suggest emerging badblocks, and then do a 'badblocks /dev/sdb' > > to see which and how many blocks are defective. You can also replace > > sdb by sdb6 or whatever partition you are specifically interested in. > > You also might want to use the -n option (non-destructive write mode), > > but only on partitions that are not mounted / used. > > > > smartmontools also offer some diagnostic features. Including a full > > surface check, but it stops at the first error. At least you know then > > until which sectory the drivs is still okay: > > smartctl -tlong /dev/sdb > > wait... > > smartctl -l selftest /dev/sda > > > > smartctl -a /dev/sdb also shows lots of info, including the number of > > bad > > and reallocated sectors. > > > > If cou can, make a copy of the partiton(s) drive with ddrescue (or dd- > > rescue, don't know which one is better, but both are more tolerable to > > errors than dd is). > > > > I had drives with single errors that seems to work fine for years after > > this, but I do nto put important data on them. And it is also possible > > that you had a head crash and more and more sectors become defective. > > So do the backup fast, or do not use the drive until you do. Good luck! > > Thanks, Alex ... I will use badblocks and smartctl in more detail after > having the data off the drive (as mentioned in my reply to Mark's > posting right now). if the disk has spare sectors, it will map out the sector the next time there is a write to it. So.. no need to offline it.
Re: [gentoo-user] Firmware loading problem
meino.cra...@gmx.de schrieb am 17.01.2011 17:12: > > The problem is, that the channel selection does not work in a proper > way: > > Suppose you have the channels: > A B C D E F G > * > > * => currently selected channel > > Now (in vlc) you press N for "next". "B" gets selected. "N"...nothing > happens. "N" "D" gets selected. "P" (previous) ... "C" gets > selected. Sometimes you have to go even three steps forward and two > backward to get a certain channel selected. > A few channel sometime are not selectable at all > > Same with mplayer...so it is not the player itsself... Do you have all needed modules loaded? According to [1] you need bttv, bt878, mt352, dvb_bt8xx and dst (this one is probably responsible for the remote control). If the problem is not about missing modules I am out here as I do not have any experience with this type of card. http://www.vdr-wiki.de/wiki/index.php/Diskussion:DVB-T_Budget-PCI-Karten -- Daniel Pielmeier signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
On Monday 17 January 2011 18:30:02 Mick wrote: > On 16 January 2011 22:30, Nikos Chantziaras wrote: > > > Then, try deleting your xorg.conf (if you have one) and do: > > > > eselect mesa set r300 gallium > > > > Also make sure that mesa is emerged with the "video_cards_r300" USE flag > > enabled. "video_cards_radeon" is *not* enough. Your make.conf should > > probably contain this: > > > > VIDEO_CARDS="fbdev vesa radeon r300" > > Hmm ... unless this USE flag shows up in later versions or overlays, > only radeon is available for mesa-7.9 > > # emerge -1aDv mesa > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R ] media-libs/mesa-7.9 USE="classic gallium nptl -debug > -gles -llvm -motif -pic (-selinux)" VIDEO_CARDS="radeon -intel -mach64 > -mga -nouveau -r128 -savage -sis -tdfx -via -vmware" 0 kB > Agree with Mick. I also did not find r300 USE flag. But see my previous answer, the issue seems to be solved now (mainly by removing framebuffer drivers from the kernel config). The correct (gallium) driver is built and used when mesa-7.9 is compiled with +radeon +gallium USE flags. Best regards, Dan T.
Re: [gentoo-user] Microcode update AMD
The word "probably" implies that you have no idea what the statistics were on getting a perfectly good core were or why they disabled entire batches of cores based on an error from one. You are just overdriving your point. If he doesn't want to enable updation of microcode, it won't hurt anything. If it was functioning fine before, it will also be fine without an update. There is nothing wrong with keeping the version of code that is stable for you. It isn't stupid, its a good rule of thumb. If it isn't broken, don't fix it. On Jan 17, 2011 4:15 PM, "Volker Armin Hemmann" wrote: > On Monday 17 January 2011 15:13:54 Jason Weisberger wrote: >> As he said in the previous message, there are almost never changelogs for >> microcode updates. >> >> I do, however, have to disagree with *never* disabling microcode updates. >> If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4 >> cores via a misconfiguration that enabled it with ACC. AMD later corrected >> this issue with a microcode update. True, some motherboards worked around >> that fix a different way, but if you had a first gen board with ACC support >> you *had* to have the old microcode for it to work. The update killed your >> free core :) > > a 'free core' that is probably broken in mysterious and hard to find but > nonetheless very dangerous ways. Thanks. > >
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
Hallo Mick. Thank you very much - it helped. Removing 'video=vesafb:ywrap,mtrr:3 vga=792' from kernel boot options, and framebuffer-related stuff in kernel config, especially: # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set # CONFIG_FB_BACKLIGHT is not set # CONFIG_FB_MODE_HELPERS is not set # CONFIG_FB_TILEBLITTING is not set # CONFIG_FB_VESA is not set # CONFIG_FB_RADEON is not set # CONFIG_DISPLAY_SUPPORT is not set # CONFIG_VGACON_SOFT_SCROLLBACK is not set # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set (not all the options were removed by hand, it is just diff of the configs, and maybe, some of them could be enabled without causing problems). Now, there are much more 'drm'-related messages in 'dmesg', and also X.org uses the drm correctly. The 'glxinfo' returns: ... OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on RV370 OpenGL version string: 2.1 Mesa 7.9 OpenGL shading language version string: 1.20 ... It looks good now. Thank you very much for your advice again. Dan T. On Sunday 16 January 2011 16:52:30 Mick wrote: > On Sunday 16 January 2011 15:18:50 Daniel Tihelka wrote: > > And the kernel seems to use them (when started with boot options > > > 'video=vesafb:ywrap,mtrr:3 vga=792'): > Dan, try removing uvesa/vesa/radeon/etc. framebuffer modules from your > kernel and the above line too from grub when you boot and see if your KMS > radeon driver can now work on its own.
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
On Monday 17 January 2011 18:30:02 Mick wrote: > On 16 January 2011 22:30, Nikos Chantziaras wrote: > > > Then, try deleting your xorg.conf (if you have one) and do: > > > > eselect mesa set r300 gallium > > > > Also make sure that mesa is emerged with the "video_cards_r300" USE flag > > enabled. "video_cards_radeon" is not enough. Your make.conf should > > probably contain this: > > > > VIDEO_CARDS="fbdev vesa radeon r300" > > Hmm ... unless this USE flag shows up in later versions or overlays, > only radeon is available for mesa-7.9 > > # emerge -1aDv mesa > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R ] media-libs/mesa-7.9 USE="classic gallium nptl -debug > -gles -llvm -motif -pic (-selinux)" VIDEO_CARDS="radeon -intel -mach64 > -mga -nouveau -r128 -savage -sis -tdfx -via -vmware" 0 kB > Agree with Mick. I also did not find r300 USE flag. But see my previous answer, the issue seems to be solved now (mainly by removing framebuffer drivers from the kernel config). The correct (gallium) driver is built and used when mesa-7.9 is compiled with +radeon +gallium USE flags. Best regards, Dan T.
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
Hallo Mick. Thank you very much - it helped. Removing 'video=vesafb:ywrap,mtrr:3 vga=792' from kernel boot options, and framebuffer-related stuff in kernel config, especially: # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set # CONFIG_FB_BACKLIGHT is not set # CONFIG_FB_MODE_HELPERS is not set # CONFIG_FB_TILEBLITTING is not set # CONFIG_FB_VESA is not set # CONFIG_FB_RADEON is not set # CONFIG_DISPLAY_SUPPORT is not set # CONFIG_VGACON_SOFT_SCROLLBACK is not set # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set (not all the options were removed by hand, it is just diff of the configs, and maybe, some of them could be enabled without causing problems). Now, there are much more 'drm'-related messages in 'dmesg', and also X.org uses the drm correctly. The 'glxinfo' returns: ... OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on RV370 OpenGL version string: 2.1 Mesa 7.9 OpenGL shading language version string: 1.20 ... It looks good now. Thank you very much for your advice again. Dan On Sunday 16 January 2011 16:52:30 Mick wrote: > On Sunday 16 January 2011 15:18:50 Daniel Tihelka wrote: > > And the kernel seems to use them (when started with boot options > > > 'video=vesafb:ywrap,mtrr:3 vga=792'): > Dan, try removing uvesa/vesa/radeon/etc. framebuffer modules from your > kernel and the above line too from grub when you boot and see if your KMS > radeon driver can now work on its own.
Re: [gentoo-user] Near freezes during large emerges
On 1/17/2011 12:29 AM, Alan McKinnon wrote: Not so much :-) I too have db servers with 96G of ram. 5 of them, so I'm current. I'm just gobsmacked that a desktop needs 3G to build a compiler and system libs. It's consuming 2G to do that, I'll bet that 1.75G of that is pure wastage. Much like authors who proudly declare that they spent 7 years writing some magnum opus. It's a sure bet they were drunk of 6.5 of them :-) Not a compiler or system libs. "whenever I undertake a large emerge such as chromium or openoffice" OpenOffice. Nuff said. kashani
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
On Monday 17 January 2011 22:31:14 Daniel Tihelka wrote: > Hallo Mick. > Thank you very much - it helped. Removing 'video=vesafb:ywrap,mtrr:3 > vga=792' > from kernel boot options, and framebuffer-related stuff in kernel config, > especially: > You can have enabled the following: CONFIG_FB=y > # CONFIG_FB_DDC is not set > # CONFIG_FB_BOOT_VESA_SUPPORT is not set > # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS is not set <--enable this =y > # CONFIG_FB_TILEBLITTING is not set > # CONFIG_FB_VESA is not set > # CONFIG_FB_RADEON is not set CONFIG_DISPLAY_SUPPORT is not set <--enable this =y > # CONFIG_VGACON_SOFT_SCROLLBACK is not set <--you can also enable this > # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set and also these: CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 > (not all the options were removed by hand, it is just diff of the configs, > and maybe, some of them could be enabled without causing problems). Yes, see above suggestions. > Now, there are much more 'drm'-related messages in 'dmesg', and also X.org > uses the drm correctly. The 'glxinfo' returns: > ... > OpenGL vendor string: X.Org R300 Project > OpenGL renderer string: Gallium 0.4 on RV370 > OpenGL version string: 2.1 Mesa 7.9 > OpenGL shading language version string: 1.20 > ... > > It looks good now. Thank you very much for your advice again. You're welcome. :-) All of this good advice is from this page: http://www.gentoo.org/doc/en/xorg-config.xml -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] disk error, where?
Am 2011-01-17 21:47, schrieb Volker Armin Hemmann: > On Monday 17 January 2011 19:59:57 Stefan G. Weichinger wrote: >> Would someone help me out on this issue? >> >> I have a flaky disk in a server, and dmesg says: >> >> end_request: I/O error, dev sdb, sector 1835240116 >> >> Now i have this layout: >> >> # fdisk -l /dev/sdb >> >> Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes >> 255 heads, 63 sectors/track, 121601 cylinders >> Units = cylinders of 16065 * 512 = 8225280 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> Disk identifier: 0x >> >>Device Boot Start End Blocks Id System >> /dev/sdb1 1 13 104391 fd Linux raid >> autodetect >> /dev/sdb2 14 50 297202+ 82 Linux swap / Solaris >> /dev/sdb3 51248319543072+ fd Linux raid >> autodetect >> /dev/sdb42484 121601 9568153355 Extended >> /dev/sdb52484 106917 838866073+ 8e Linux LVM >> /dev/sdb6 106918 121601 117949198+ fd Linux raid >> autodetect >> >> >> My question (apart from the fact that I evacuate all on that >> non-raid-LVM-partition right now!): >> >> In which partition is that "sector 1835240116" ? >> >> Sorry for this maybe stupid question ... >> >> Thanks, Stefan > > man debugfs: > >bmap filespec logical_block > Print the physical block number corresponding to the logical > block number logical_block > in the inode filespec. > >icheck block ... > Print a listing of the inodes which use the one or more blocks > specified on the command > line. > >ncheck inode_num ... > Take the requested list of inode numbers, and print a > listing of pathnames to those > inodes. > > > if you are using extX- thanks I also found this one: http://smartmontools.sourceforge.net/badblockhowto.html looks also worth reading Stefan
Re: [gentoo-user] Microcode update AMD
On Monday 17 January 2011 16:59:26 Jason Weisberger wrote: > The word "probably" implies that you have no idea what the statistics were > on getting a perfectly good core were or why they disabled entire batches of > cores based on an error from one. > > You are just overdriving your point. If he doesn't want to enable updation > of microcode, it won't hurt anything. If it was functioning fine before, it > will also be fine without an update. There is nothing wrong with keeping > the version of code that is stable for you. It isn't stupid, its a good > rule of thumb. If it isn't broken, don't fix it. the problem is: how do you know it is stable? Just might be lucky that fixed function was not hit by you so far. But will that be true tomorrow? Next week? With the next gcc version? Microcode updates are there for a reason. There are ZILCH reasons to turn it off in the bios. 'Oh, there are a lots of fine 4cores marketed as 3cores. I want that' is not a reason not to turn it on. It is a reason to buy a mobo who can unlock those cores without turning off microcode updates. Call me old fashioned, but I prefer computers as deterministic machines - and not very expensive random number generators (which is also the main reason why I don't overclock. 5% faster for 1% better chance of errors? 5% I will never ever able to 'feel'? No thank you).
Re: [gentoo-user] Near freezes during large emerges
On Monday 17 January 2011 22:45:39 kashani wrote: > On 1/17/2011 12:29 AM, Alan McKinnon wrote: > > Not so much :-) > > > > I too have db servers with 96G of ram. 5 of them, so I'm current. I'm > > just gobsmacked that a desktop needs 3G to build a compiler and system > > libs. It's consuming 2G to do that, I'll bet that 1.75G of that is pure > > wastage. > > > > Much like authors who proudly declare that they spent 7 years writing > > some magnum opus. It's a sure bet they were drunk of 6.5 of them :-) > > Not a compiler or system libs. > > "whenever I undertake a large emerge such as chromium or openoffice" > > OpenOffice. Nuff said. Yep, amd64 laptop with 4G RAM and 4G swap (for when I hibernate on it). Still, other than hibernating emerging openoffice is I think the only(?) package that actually makes use of swap. Not by much but uses it all the same. A x86 desktop with only 3G RAM also uses swap and it uses more of it than the laptop does when emerging openoffice. Same x86 desktop used to have 1G memory in the past and it used even more swap during OOo emerges. If I recall right OOo also complains that my /var/tmp is not larger than 6G. I won't be surprised if in a few years time it completely refuses to start the emerge because my /var/tmp is not 12G+ or some such! -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Near freezes during large emerges
On Monday 17 January 2011 12:38:56 Neil Bothwick wrote: > On Mon, 17 Jan 2011 19:40:15 +0800, William Kenworthy wrote: > > > If it's diskless, where are /tmp and /var/tmp mounted? If they use > > > tmpfs the "memory" usage is understandable. If they use NFS the > > > emerges must be unbearably slow. > > > > For normal usage, they are in tmpfs along with portage but I mount them > > over nfs for larger packages as memory is too constrained (just comment > > out the lines in fstab) - most packages take much less than a hundred mb > > or so for the storage unless its glibc or the like. After a reboot they > > are using no space (of course) and it just takes a sync to replace > > portage and I use http-replicator on the network so distfiles are not a > > problem. > > So root is on another (more powerful?) machine and mounted over NFS? Why > not chroot into the root on the host machine and run the emerge there? Is there a howto for this somewhere please? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Near freezes during large emerges
> I think the idea is never use swap if possible, but in a case where > you don't have swap space or run out of swap space I think it's still > possible to lose data. Isn't swap just an extension of system memory? Isn't adding 4GB of memory just as effective at preventing out-of-memory as dedicating 4GB of HD space to swap? I can understand enabling swap on a laptop or other system with constrained memory capacity, but doesn't it make sense to disable swap and add memory on a 24GB server? Is swap basically a way to save money on RAM? - Grant
Re: [gentoo-user] Near freezes during large emerges
On Mon, 17 Jan 2011 23:44:59 +, Mick wrote: > > So root is on another (more powerful?) machine and mounted over NFS? > > Why not chroot into the root on the host machine and run the emerge > > there? > > Is there a howto for this somewhere please? It's just the same as if you'd booted from a live CD and followed the handbook. The chroot just needs to be done from an environment that has the necessary tools, which a Gentoo base installation does. -- Neil Bothwick If I agreed with you, we'd both be wrong. signature.asc Description: PGP signature
Re: [gentoo-user] Near freezes during large emerges
On 1/17/2011 4:23 PM, Grant wrote: I think the idea is never use swap if possible, but in a case where you don't have swap space or run out of swap space I think it's still possible to lose data. Isn't swap just an extension of system memory? Isn't adding 4GB of memory just as effective at preventing out-of-memory as dedicating 4GB of HD space to swap? I can understand enabling swap on a laptop or other system with constrained memory capacity, but doesn't it make sense to disable swap and add memory on a 24GB server? Is swap basically a way to save money on RAM? Most users won't willingly trades 4ns data access for 13ms data access. I'd say swap in that situation is a way to gracefully degrade performance so that a user or admin can decide what to do. And yes in some cases that graceful part isn't. In my experience swap has allowed me to log in, kill runaway processes, then shut down the database gracefully to make sure all data was saved. I tend not to configure more than 2-4GB these days on servers. The other thing to remember is alerting on 98% RAM usage under Linux is a not starter because Linux will shove everything into RAM until it's full. However alerting on 5% swap usage does work fairly well. kashani
Re: [gentoo-user] Near freezes during large emerges
On Mon, Jan 17, 2011 at 4:23 PM, Grant wrote: >> I think the idea is never use swap if possible, but in a case where >> you don't have swap space or run out of swap space I think it's still >> possible to lose data. > > Isn't swap just an extension of system memory? Isn't adding 4GB of > memory just as effective at preventing out-of-memory as dedicating 4GB > of HD space to swap? I can understand enabling swap on a laptop or > other system with constrained memory capacity, but doesn't it make > sense to disable swap and add memory on a 24GB server? > > Is swap basically a way to save money on RAM? > > - Grant > > OK, please keep in mind that I'm not a programmer or a sys admin so take all of this with less than a grain of salt. First, leaving out the hibernation issue that uses swap as non-volatile memory, even then no, I don't think it's exactly the same. The kernel knows when memory is overfull & swap is coming into play so it knows to change how it handles what's it allows to be done. You always have the potential that some program starts filling memory with data to be written to disk, but the kernel cannot flush that data out to disk as fast as the program fills up memory, so memory fills completely and the system starts swapping. At that point the kernel can interrupt the program, start cleaning things up, and when memory is back to some portion used and some portion free then it can let programs take over again. If you have no swap and completely run out of memory then there's some potential that if the kernel needs memory of its own to get some job done it may have to write over the top of some program's data and at that point the data is lost. I do agree that 4GB DRAM is better (most of the time) vs 4GB of swap. However I have 2.5TB of disk space in my home server. I see no real problem handing over 12GB (.5%?) of disk space to duplicate memory size & have a more graceful slowdown at the limit of memory usage. Thanks just me though. Cheers, Mark
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
On Mon, Jan 17, 2011 at 2:31 PM, Daniel Tihelka wrote: > Hallo Mick. > Thank you very much - it helped. Removing 'video=vesafb:ywrap,mtrr:3 > vga=792' > from kernel boot options, and framebuffer-related stuff in kernel config, > especially: > > # CONFIG_FB_DDC is not set > # CONFIG_FB_BOOT_VESA_SUPPORT is not set > # CONFIG_FB_BACKLIGHT is not set > # CONFIG_FB_MODE_HELPERS is not set > # CONFIG_FB_TILEBLITTING is not set > # CONFIG_FB_VESA is not set > # CONFIG_FB_RADEON is not set > # CONFIG_DISPLAY_SUPPORT is not set > # CONFIG_VGACON_SOFT_SCROLLBACK is not set > # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set > > (not all the options were removed by hand, it is just diff of the configs, > and > maybe, some of them could be enabled without causing problems). > > Now, there are much more 'drm'-related messages in 'dmesg', and also X.org > uses the drm correctly. The 'glxinfo' returns: > ... > OpenGL vendor string: X.Org R300 Project > OpenGL renderer string: Gallium 0.4 on RV370 > OpenGL version string: 2.1 Mesa 7.9 > OpenGL shading language version string: 1.20 > ... > > It looks good now. Thank you very much for your advice again. > Dan > > On Sunday 16 January 2011 16:52:30 Mick wrote: >> On Sunday 16 January 2011 15:18:50 Daniel Tihelka wrote: >> > And the kernel seems to use them (when started with boot options >> >> > 'video=vesafb:ywrap,mtrr:3 vga=792'): >> Dan, try removing uvesa/vesa/radeon/etc. framebuffer modules from your >> kernel and the above line too from grub when you boot and see if your KMS >> radeon driver can now work on its own. > Daniel, I'm seeing the same problem here and trying to follow my way through your kernel config changes. I don't think I have it yet on this box as I'm seeing a message about rendering being disabled in Xorg.log.0 c2stable ~ # cat /var/log/Xorg.0.log | grep render [29.017] (WW) RADEON(0): Direct rendering disabled c2stable ~ # even though glxinfo says it's enabled: c2stable ~ # glxinfo | grep render direct rendering: Yes OpenGL renderer string: Gallium 0.4 on softpipe GL_NV_blend_square, GL_NV_conditional_render, GL_NV_light_max_exponent, c2stable ~ # Anyway, I'm sure I'll figure it out but I'm curious how you measure that it's working up to it's potential. I'm getting less than 200FPS in glxgears. I get >2500 on a cheaper nvidia card so I'm certain this Radeon 300 can do better. What do you see in glxgears? Thanks, Mark
Re: [gentoo-user] Firmware loading problem
Daniel Pielmeier [11-01-18 03:13]:
> meino.cra...@gmx.de schrieb am 17.01.2011 17:12:
> >
> > The problem is, that the channel selection does not work in a proper
> > way:
> >
> > Suppose you have the channels:
> > A B C D E F G
> > *
> >
> > * => currently selected channel
> >
> > Now (in vlc) you press N for "next". "B" gets selected. "N"...nothing
> > happens. "N" "D" gets selected. "P" (previous) ... "C" gets
> > selected. Sometimes you have to go even three steps forward and two
> > backward to get a certain channel selected.
> > A few channel sometime are not selectable at all
> >
> > Same with mplayer...so it is not the player itsself...
>
> Do you have all needed modules loaded? According to [1] you need bttv,
> bt878, mt352, dvb_bt8xx and dst (this one is probably responsible for
> the remote control).
>
> If the problem is not about missing modules I am out here as I do not
> have any experience with this type of card.
>
> http://www.vdr-wiki.de/wiki/index.php/Diskussion:DVB-T_Budget-PCI-Karten
>
> --
> Daniel Pielmeier
>
Hi Daniel,
Thank you for your reply ! :)
I have all this modules loaded except dst, because I am using the
keyboard for this ("N"-key, "P"-key as described).
Does anyone has any hint for me?
iHow is my card (AVermedia AverTV DVB-T 771) know to behave under
Linux ?
Best regards,
mcc
Re: [gentoo-user] Near freezes during large emerges
Grant wrote: I think the idea is never use swap if possible, but in a case where you don't have swap space or run out of swap space I think it's still possible to lose data. Isn't swap just an extension of system memory? Isn't adding 4GB of memory just as effective at preventing out-of-memory as dedicating 4GB of HD space to swap? I can understand enabling swap on a laptop or other system with constrained memory capacity, but doesn't it make sense to disable swap and add memory on a 24GB server? Is swap basically a way to save money on RAM? - Grant I'm just a desktop user and I'm not going to claim I know it all either. My thinking, I have two rigs here, one x86 with 2Gbs of ram and one AMD_64 with 4GBs of ram. I used to have 1Gb of ram on the older x86 rig. When I started using swap on a regular basis, I bought some more ram. Keep in mind, it only had 512Mbs when I first built it which was about 8 years ago. My new rig, I plan to max out at 16Gbs and just buy the sticks as I can afford them. Then put portage's work directory on tmpfs or something. That should speed up a few things. Since swap is a lot slower, you don't want to use much swap all the time. Using swap on occasion when emerging OOo or something that is similarly huge then that may be OK. When you login or get your server running and with little activity you are using swap, you need to think about adding some memory. I have always tried to view swap as something that can be used at times when needed or as a failsafe to a system running out of ram and crashing or something nasty. It's not something I want my system to use all the time and becomes a performance issue. That's my thinking. I'm sure it is worth a grain of salt to someone. ;-) Dale :-) :-)
Re: [gentoo-user] Microcode update AMD
On Mon, 2011-01-17 at 20:46 +0100, Volker Armin Hemmann wrote: > On Monday 17 January 2011 20:19:04 meino.cra...@gmx.de wrote: > > Volker Armin Hemmann [11-01-17 20:16]: > > > On Monday 17 January 2011 18:21:48 meino.cra...@gmx.de wrote: > > > > Hi, > > > > > > > > I have two questions: > > > > 1) Do I have to enable microcode updates in the BIOS of my > > > > Crosshair > > > > > > > > IV Formula to activate microcodes push in the CPU by the > > > > module > > > > "microcode" ? (AMD Phenom X6 1090T) > nobody knows. > Not amd, but follow the links for some explanation. * sys-apps/microcode-ctl Latest version available: 1.17-r2 Latest version installed: [ Not Installed ] Size of downloaded files: 319 kB Homepage:http://www.urbanmyth.org/microcode Description: Intel processor microcode update utility License: GPL-2 * sys-apps/microcode-data Latest version available: 20100209 Latest version installed: [ Not Installed ] Size of downloaded files: 549 kB Homepage:http://urbanmyth.org/microcode/ Description: Intel IA32 microcode update data License: as-is I manually grabbed a later data set from Intel when the kernel would throw a message about needing a microcode update on my Intel Atom. There are a couple of kernel options that need setting as well as the above packages - loading is via an /etc/init.d/ script. There was a changelog there as well - AMD should be similar. Also, you could ask AMD what the update fixes? The bios microcode update is likely an enable setting rather than the bios actually updating the cpu. You need to do some reading/asking of the manufacturers (not here) if it bothers you. BillK -- William Kenworthy Home in Perth!
Re: [gentoo-user] Near freezes during large emerges
On Mon, 2011-01-17 at 16:23 -0800, Grant wrote: > > I think the idea is never use swap if possible, but in a case where > > you don't have swap space or run out of swap space I think it's still > > possible to lose data. > > Isn't swap just an extension of system memory? Isn't adding 4GB of > memory just as effective at preventing out-of-memory as dedicating 4GB > of HD space to swap? I can understand enabling swap on a laptop or > other system with constrained memory capacity, but doesn't it make > sense to disable swap and add memory on a 24GB server? > > Is swap basically a way to save money on RAM? > > - Grant > No swap contains pages from memory that have not been accessed for awhile so they can be stored elsewhere freeing ram for actual active pages. When they need to be accessed, they have to be swapped back in, and often something swapped back out to make room for it. And for those with gigabytes of swap, keep in mind that the majority of processors can only access up to 32 x 2G swapfiles under linux, so 4G is only going to be half used. Some processors are only able to handle very small swapfiles, whilst amd opterons can handle very large ones. It does appear however that some distros (redhat and suse ?) have modified something to allow larger swap sizes on 64bit systems, but via google it seems very muddy at the moment. On my mostly 32bit systems its only the opterons (which are running 64bit systems) that can access more than 2G swap using gentoo-sources kernels when I tested late last year. BillK -- William Kenworthy Home in Perth!
