Re: [gentoo-user] Near freezes during large emerges
On Tuesday 18 January 2011 04:42:38 William Kenworthy wrote: On Mon, 2011-01-17 at 16:23 -0800, Grant wrote: 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. Unless you are using your swap partition for hibernating to disk, when most of your memory in usage will be saved on it. In that case, if swap is less than RAM, hibernation fails. BTW, it used to be that the kernel would not (easily?) access more than 128M of swap for some reason and multiple 128M swap partitions were more efficient than a single larger space, but this has probably changed with amd64 processors and modern kernels. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Near freezes during large emerges
Apparently, though unproven, at 09:27 on Tuesday 18 January 2011, Mick did opine thusly: BTW, it used to be that the kernel would not (easily?) access more than 128M of swap for some reason and multiple 128M swap partitions were more efficient than a single larger space, but this has probably changed with amd64 processors and modern kernels. That limitation was lifted a very very long time ago. I'm not sure when it happened it was so long ago. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Near freezes during large emerges
On Tue, 2011-01-18 at 07:27 +, Mick wrote: On Tuesday 18 January 2011 04:42:38 William Kenworthy wrote: On Mon, 2011-01-17 at 16:23 -0800, Grant wrote: 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. Unless you are using your swap partition for hibernating to disk, when most of your memory in usage will be saved on it. In that case, if swap is less than RAM, hibernation fails. BTW, it used to be that the kernel would not (easily?) access more than 128M of swap for some reason and multiple 128M swap partitions were more efficient than a single larger space, but this has probably changed with amd64 processors and modern kernels. Separate swapfiles of equal priority can be used (ala raid0) across multiple disks for a measurable performance boost The one big job I needed a large swapfile for (a clustalw alignment, which caused me to investigate swap usage) ran for nearly a month, generated ~46GB swap usage - and then generated a bus error and died. Developed hardware problems :( Two other areas I have needed insane swapfiles are humongous spreadsheets and graphics. More ram is always best, but sometimes its just not possible/available. BillK -- William Kenworthy bi...@iinet.net.au Home in Perth!
Re: [gentoo-user] disk error, where?
Am 18.01.2011 00:06, schrieb Stefan G. Weichinger: http://smartmontools.sourceforge.net/badblockhowto.html looks also worth reading I had badblocks running over night, it told me that it found 33 bad blocks. Reallocated_Sector_Ct, Current_Pending_Sector and Offline_Uncorrectable increased (77,8,8) ... Should I re-run badblocks? Get another disk anyway? Stefan
Re: [gentoo-user] disk error, where?
Am 18.01.2011 10:31, schrieb Stefan G. Weichinger: Am 18.01.2011 00:06, schrieb Stefan G. Weichinger: http://smartmontools.sourceforge.net/badblockhowto.html looks also worth reading I had badblocks running over night, it told me that it found 33 bad blocks. Reallocated_Sector_Ct, Current_Pending_Sector and Offline_Uncorrectable increased (77,8,8) ... Should I re-run badblocks? Get another disk anyway? I (have to) add: that flaky partition is part of a raid0 which is building the so-called holding disk in my installation of the AMANDA backup suite. So it is containing kind of temporary data only and I can easily reformat or rebuild it if necessary or helpful.
[gentoo-user] Re: Near freezes during large emerges
Alan McKinnon alan.mckin...@gmail.com writes: 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 bi...@iinet.net.au 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 Well, GCC has issues like this, with the file insn-attrtab, which, I suppose, is generated and processed at least twice (due to the bootstrap nature of the GCC build process). Although there's not a specific value, even with 512 MiB of ram it's still an issue - but it doesn't go that far (3GB), it's only more critical because GCC is a key part of the toolchain. This just to say, well, it happens :-) -- Nuno J. Silva gopher://sdf-eu.org/1/users/njsg
[gentoo-user] Re: Near freezes during large emerges
William Kenworthy bi...@iinet.net.au writes: 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? 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. Like BillK said, it's not, whatever gets there must be swapped back in to be used again. For example, let's say you have a program that needs to open a really really big file, an 8GiB file (no FAT jokes, please), and you have 4GiB of RAM and 6GiB on swapfiles/partitions. The system will not be able to put the entire file on the physical memory (and it may not even be able to do so on virtual memory (memory as the process sees it), if you're on 32 bits, IIRC). This means, although the program can access the file data, and from its own point-of-view, all data is on memory, the system will have to do some swap-in-swap-out gymnastics every time the program wants a chunk of the file that's not on RAM. OTOH if you actually add 6GiB of RAM, you'll probably be able to do it all from RAM (8GiB for the file, and the other 2GiB for whatever else is running). It is better to see it as BillK describes - not a way to extend your memory, but a way to store not-that-frequently-used pages when you need to load something else. It saves money, but it's still expensive - on time. -- Nuno J. Silva gopher://sdf-eu.org/1/users/njsg
[gentoo-user] How to mask xfce 4.8?
My last update bumped XFCE to 4.8, and I quickly learned that it's got some serious bugs. So, I need to roll back to whatever the prevous version was. How do I tell portage to not use 4.8? I tried adding this line in /etc/portage/package.mask: =xfce-base/xfce4-meta-4.8 But that does nothing. Do I have to individually mask all 20+ components of XFCE? -- Grant Edwards grant.b.edwardsYow! Jesus is my POSTMASTER at GENERAL ... gmail.com
Re: [gentoo-user] disk error, where?
On Tuesday 18 January 2011 10:45:37 Stefan G. Weichinger wrote: Am 18.01.2011 10:31, schrieb Stefan G. Weichinger: Am 18.01.2011 00:06, schrieb Stefan G. Weichinger: http://smartmontools.sourceforge.net/badblockhowto.html looks also worth reading I had badblocks running over night, it told me that it found 33 bad blocks. Reallocated_Sector_Ct, Current_Pending_Sector and Offline_Uncorrectable increased (77,8,8) ... Should I re-run badblocks? Get another disk anyway? I (have to) add: that flaky partition is part of a raid0 which is building the so-called holding disk in my installation of the AMANDA backup suite. So it is containing kind of temporary data only and I can easily reformat or rebuild it if necessary or helpful. yes, rerun badblocks in destructive write mode. Twice. The second time create a badblocks file and use it with mkfs - that way bad blocks should be skipped.
[gentoo-user] Re: Microcode update AMD
Jason Weisberger jbdu...@gmail.com writes: On Jan 17, 2011 4:15 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: On Monday 17 January 2011 15:13:54 Jason Weisberger wrote: 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. 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. I think you should worry more about the fact AMD disables known-good cores due to excessive demand for lower-core versions. If you can somehow manage to find out if the disabled core is good or not (keeping in mind that testing may convincingly demonstrate the presence of bugs, but can never demonstrate their absence. (EWD1036) - it's more or less like when you use memtest), then you have a good heuristic on whether or not to enable that core. Now I doubt I'd do it blindly - YMMV, of course. Also, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- Nuno J. Silva gopher://sdf-eu.org/1/users/njsg
[gentoo-user] Re: How to mask xfce 4.8?
On 2011-01-18, Grant Edwards grant.b.edwa...@gmail.com wrote: My last update bumped XFCE to 4.8, and I quickly learned that it's got some serious bugs. So, I need to roll back to whatever the prevous version was. How do I tell portage to not use 4.8? I tried adding this line in /etc/portage/package.mask: =xfce-base/xfce4-meta-4.8 But that does nothing. Do I have to individually mask all 20+ components of XFCE? I think XFCE 4.8 was given stable status prematurely. Quoting one of the XFCE apps when asked by a user if it was time to upgrade to 4.8: Although we've made a lot of development releases; during 4.8.0 the code gets some real testing. So unless something is 4.6 that bothers you is broken that should've been resolved in 4.8, it's better to wait a bit until 4.8.1 or .2. Trying to roll XFCE back to a version that works is also proving to be difficult... -- Grant Edwards grant.b.edwardsYow! Gibble, Gobble, we at ACCEPT YOU ... gmail.com
Re: [gentoo-user] Microcode update AMD
On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy bi...@iinet.net.au wrote: 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. Thanks for the links, I didn't realize they made the microcode data available separately. From Intel's download site for the microcode data: The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux Operating System and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system.
Re: [gentoo-user] How to mask xfce 4.8?
On Tue, 18 Jan 2011 15:22:20 + (UTC), Grant Edwards wrote: But that does nothing. Do I have to individually mask all 20+ components of XFCE? Yes, but it's not difficult: qlist -ICv xfce-base/ | sed 's/^/~/' /etc/portage/package.mask/xfce-48 -- Neil Bothwick mandelbug /man'del-buhg/ n. [from the Mandelbrot set] A bug whose underlying causes are so complex and obscure as to make its behavior appear chaotic or even non-deterministic. This term implies that the speaker thinks it is a Bohr bug, rather than a heisenbug. See also schroedinbug. signature.asc Description: PGP signature
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy bi...@iinet.net.au wrote: 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. Thanks for the links, I didn't realize they made the microcode data available separately. From Intel's download site for the microcode data: The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux Operating System and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system. Thanks for the info Paul. For kicks I tried it on an Intel DH55HC MB running an Core i5-661. 1) Created /etc/firmware 2) Downloaded the Intel microcode-20101123.tgz file 3) Enabled the /dev/cpu/microcode option under Processor Types and Features 4) Rebuilt the kernel and rebooted I see this in dmesg: mark@firefly ~ $ dmesg | grep micro [0.495337] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [0.495436] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [0.495535] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [0.495635] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [0.495751] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba mark@firefly ~ $ On this machine the message doesn't change whether the microcode file is located in /etc/firmware or not so I don't know how to tell if the process worked but the processor doesn't need any updates or whether it didn't work at all. - Mark
Re: [gentoo-user] Microcode update AMD
btw, very related: http://blog.flameeyes.eu/2011/01/17/microupdates-for-microcodes
[gentoo-user] BIOS flash safe with dosemu ?
Hi, does anybody if it's safe to flash the BIOS using a DOS emulator like app-emulation/dosemu ? Thanks for sharing your experience, Helmut.
Re: [gentoo-user] BIOS flash safe with dosemu ?
On Tue, Jan 18, 2011 at 10:41 AM, Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote: Hi, does anybody if it's safe to flash the BIOS using a DOS emulator like app-emulation/dosemu ? Thanks for sharing your experience, Helmut. I don't think it will work (unless you are flashing the emulated BIOS?)
Re: [gentoo-user] BIOS flash safe with dosemu ?
On Tuesday 18 January 2011 17:41:52 Helmut Jarausch wrote: Hi, does anybody if it's safe to flash the BIOS using a DOS emulator like app-emulation/dosemu ? Thanks for sharing your experience, Helmut. it is not considered safe. Get an usb stick with freedos or systemrescue cd or use the builtin flashtool of you mobos bios. dosemu is not a good idea. Even if it may work - are you really willing to brick your board?
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 8:16 AM, Mark Knecht markkne...@gmail.com wrote: On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy bi...@iinet.net.au wrote: 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. Thanks for the links, I didn't realize they made the microcode data available separately. From Intel's download site for the microcode data: The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux Operating System and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system. Thanks for the info Paul. For kicks I tried it on an Intel DH55HC MB running an Core i5-661. 1) Created /etc/firmware 2) Downloaded the Intel microcode-20101123.tgz file 3) Enabled the /dev/cpu/microcode option under Processor Types and Features 4) Rebuilt the kernel and rebooted I see this in dmesg: mark@firefly ~ $ dmesg | grep micro [ 0.495337] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [ 0.495436] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [ 0.495535] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [ 0.495635] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [ 0.495751] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba mark@firefly ~ $ On this machine the message doesn't change whether the microcode file is located in /etc/firmware or not so I don't know how to tell if the process worked but the processor doesn't need any updates or whether it didn't work at all. - Mark OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. Add microcode_ctl to the boot level: rc-update add microcode_ctl boot 2) Unzip and untar the microcode file from Intel. 3) The above emerge placed the microcode.dat file in /lib/firmware, not /etc/firmware as suggested by the kernel, so I loaded the newer one from Intel by hand using microcode-ctl: firefly firmware # microcode_ctl -f /etc/firmware/microcode-20101123.dat microcode_ctl: writing microcode (length: 430080) microcode_ctl: microcode successfuly written to /dev/cpu/microcode firefly firmware # dmesg | grep micro [0.495755] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [0.495853] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [0.495952] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [0.496050] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [0.496168] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [ 2647.731262] microcode: CPU0 updated to revision 0xc, date = 2010-06-10 [ 2647.731982] microcode: CPU1 updated to revision 0xc, date = 2010-06-10 [ 2647.732815] microcode: CPU2 updated to revision 0xc, date = 2010-06-10 [ 2647.733608] microcode: CPU3 updated to revision 0xc, date = 2010-06-10 firefly firmware # Now the microcode revision appears to be updated. I suspected that if I renamed the file in /etc/firmware to 'microcode.dat' maybe it would load automatically at boot time but it didn't so I moved it to lib/firmware where microcode_ctl does load it. NOTE: There is a /etc/conf.d/microcode_ctl config file but it doesn't see to include a path for microcode so I guess at this time I'm stuck overwriting the /lib/firmware directory until I learn more. Cheers, Mark
Re: [gentoo-user] Microcode update AMD
On Tuesday 18 January 2011 09:34:14 Mark Knecht wrote: On Tue, Jan 18, 2011 at 8:16 AM, Mark Knecht markkne...@gmail.com wrote: On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy bi...@iinet.net.au wrote: 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. Thanks for the links, I didn't realize they made the microcode data available separately. From Intel's download site for the microcode data: The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux Operating System and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system. Thanks for the info Paul. For kicks I tried it on an Intel DH55HC MB running an Core i5-661. 1) Created /etc/firmware 2) Downloaded the Intel microcode-20101123.tgz file 3) Enabled the /dev/cpu/microcode option under Processor Types and Features 4) Rebuilt the kernel and rebooted I see this in dmesg: mark@firefly ~ $ dmesg | grep micro [0.495337] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [0.495436] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [0.495535] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [0.495635] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [0.495751] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba mark@firefly ~ $ On this machine the message doesn't change whether the microcode file is located in /etc/firmware or not so I don't know how to tell if the process worked but the processor doesn't need any updates or whether it didn't work at all. - Mark OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. Add microcode_ctl to the boot level: rc-update add microcode_ctl boot 2) Unzip and untar the microcode file from Intel. 3) The above emerge placed the microcode.dat file in /lib/firmware, not /etc/firmware as suggested by the kernel, so I loaded the newer one from Intel by hand using microcode-ctl: firefly firmware # microcode_ctl -f /etc/firmware/microcode-20101123.dat microcode_ctl: writing microcode (length: 430080) microcode_ctl: microcode successfuly written to /dev/cpu/microcode firefly firmware # dmesg | grep micro [0.495755] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9 [0.495853] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9 [0.495952] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9 [0.496050] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9 [0.496168] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [ 2647.731262] microcode: CPU0 updated to revision 0xc, date = 2010-06-10 [ 2647.731982] microcode: CPU1 updated to revision 0xc, date = 2010-06-10 [ 2647.732815] microcode: CPU2 updated to revision 0xc, date = 2010-06-10 [ 2647.733608] microcode: CPU3 updated to revision 0xc, date = 2010-06-10 firefly firmware # Now the microcode revision appears to be updated. I suspected that if I renamed the file in /etc/firmware to 'microcode.dat' maybe it would load automatically at boot time but it didn't so I moved it to lib/firmware where microcode_ctl does load it. NOTE: There is a /etc/conf.d/microcode_ctl config file but it doesn't see to include a path for microcode so I guess at this time I'm stuck overwriting the /lib/firmware directory until I learn more. Cheers, Mark and that is all the intel stuff. For AMD all you have to do is: modprobe -r microcode modprobe microcode
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com wrote: OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. The ebuild for newer versions (including the latest 20101123) is in portage as ~amd64 and ~x86.
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com wrote: OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. The ebuild for newer versions (including the latest 20101123) is in portage as ~amd64 and ~x86. Thanks Paul. Also, it does seem to work, for Intel anyway, as a module or built into the kernel. I chose to build it in as I'm tired of how long lsmod is looking these days. Cheers, Mark
[gentoo-user] Re: How to mask xfce 4.8?
On 2011-01-18, Neil Bothwick n...@digimed.co.uk wrote: On Tue, 18 Jan 2011 15:22:20 + (UTC), Grant Edwards wrote: But that does nothing. Do I have to individually mask all 20+ components of XFCE? Yes, but it's not difficult: qlist -ICv xfce-base/ | sed 's/^/~/' /etc/portage/package.mask/xfce-48 Nice. In my case, it masks exo and thunar when it doesn't need to, and it misses appfinder (and presumably other extras). I should spend some time reading the qlist manpage. [I still tend to use equery.] Adding xfce-extras and then grepping for '-4.8.[0-9] would probably do the trick. -- Grant Edwards grant.b.edwardsYow! I appoint you at ambassador to Fantasy gmail.comIsland!!!
[gentoo-user] Re: BIOS flash safe with dosemu ?
On 01/18/2011 06:41 PM, Helmut Jarausch wrote: Hi, does anybody if it's safe to flash the BIOS using a DOS emulator like app-emulation/dosemu ? It won't work. The flashing tools are designed to be run in real mode. Dosemu runs in vm86 mode. Your best bet is to get a bootable *.iso from the mainboard manufacturer, write it on CD and boot from it.
Re: [gentoo-user] Re: X -config fail
i'm sorry,but chinese doc is different form english doc, i read chinese doc and loss some step. 2011/1/16 Mick michaelkintz...@gmail.com On Sunday 16 January 2011 13:53:14 doherty pete wrote: how can i confim i have evdev,if i donn't have ,i think i have to edite /etc/make.cof USE=-evdev -dri -dri2 or VIDEOCARD=-evdev -dri -dri2 and recompile xorg-server Pete, can you please read the documentation and follow it to the letter: http://www.gentoo.org/doc/en/xorg-config.xml What you are asking is covered under the section titled make.conf configuration. To find out if you have something installed you can try: === # emerge --search evdev Searching... [ Results for search key : evdev ] [ Applications found : 1 ] * x11-drivers/xf86-input-evdev Latest version available: 2.5.0 Latest version installed: 2.5.0 Size of files: 306 kB Homepage: http://xorg.freedesktop.org/ Description: Generic Linux input driver License: MIT === If it has not been installed before, it will say: Latest version installed: [ Not Installed ] Alternatively, you can emerge and use app-portage/eix and then run: === # eix -l evdev [I] x11-drivers/xf86-input-evdev Available versions: 2.4.0 alpha amd64 arm hppa ia64 ~mips ppc ppc64 sh sparc x86 [debug] 2.5.0 ~alpha amd64 arm hppa ~ia64 ~mips ~ppc ppc64 ~sh ~sparc x86 ~ 2.6.0 ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc ~x86 Installed versions: 2.5.0(22:20:38 26/12/10) Homepage:http://xorg.freedesktop.org/ Description: Generic Linux input driver === Finally, if you know the exact package name try running: === # emerge -1aDv xf86-input-evdev These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/xf86-input-evdev-2.5.0 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] No Quitting. The R symbol denotes that you are trying to re-emerge it. If you hadn't installed it, you get [ebuild N] for 'new'. HTH. PS. Please try to avoid top posting. It breaks the natural flow of the discussion. 2011/1/16 walt w41...@gmail.com On 01/15/2011 07:17 AM, doherty pete wrote: when i input Xorg -configure the log is [ 442.765] (EE) Failed to load module evdev (module does not exist, 0) This is all very confusing unless you know the history of evdev, which most sane people don't know. (I obviously don't qualify as sane :) Try emerging xf86-input-evdev. -- Regards, Mick -- pete_doherty
Re: [gentoo-user] BIOS flash safe with dosemu ?
On 2011-01-18 17:41, Helmut Jarausch wrote: does anybody if it's safe to flash the BIOS using a DOS emulator like app-emulation/dosemu ? If you have a compatible board you could try flashrom. It's in portage and the homepage is: http://www.flashrom.org/Flashrom MfG Peter K
Re: [gentoo-user] Near freezes during large emerges
On 1/17/2011 8:42 PM, William Kenworthy wrote: 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 On a 32bit x86 Linux OS your swap file or swap partitions can have a max size of 2GB. If you're using a kernel later than 2.4.10 you can have 32 swap device and previous to that it was 8. With a 64bit Linux OS you can have swap devices of 64GB each. kashani
[gentoo-user] kernel 2.6.37 : MCE problem
I've just installed compiled gentoo-sources-2.6.37 am getting msgs in all my terminals Message from syslogd@localhost at Tue Jan 18 14:32:38 2011 ... localhost kernel: [Hardware Error]: No human readable MCE decoding support on this CPU type. Message from syslogd@localhost at Tue Jan 18 14:32:38 2011 ... localhost kernel: [Hardware Error]: Run the message through 'mcelog --ascii' to decode. There seems to be no change in config options re MCE since 2.6.33 , the previous kernel, which doesn't suffer from this internal spam. My CPU is an Intel Core 2 Duo. Everything else seems to be working ok. Does anyone have any idea what's going on ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht markkne...@gmail.com wrote: On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com wrote: OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. The ebuild for newer versions (including the latest 20101123) is in portage as ~amd64 and ~x86. Thanks Paul. Also, it does seem to work, for Intel anyway, as a module or built into the kernel. I chose to build it in as I'm tired of how long lsmod is looking these days. If you use the /etc/init.d/microcode_ctl runscript and have MICROCODE_UNLOAD=yes set in /etc/conf.d/microcode_ctl (which is the default), it will unload the module automatically after it runs, so you shouldn't see it in lsmod anyway, and saves a few kb of memory. But, quite honestly, 8kb of memory is probably inconsequential on a system where microcode_ctl is being used in the first place... :)
Re: [gentoo-user] kernel 2.6.37 : MCE problem
On Tue, Jan 18, 2011 at 1:53 PM, Philip Webb purs...@ca.inter.net wrote: I've just installed compiled gentoo-sources-2.6.37 am getting msgs in all my terminals Message from syslogd@localhost at Tue Jan 18 14:32:38 2011 ... localhost kernel: [Hardware Error]: No human readable MCE decoding support on this CPU type. Message from syslogd@localhost at Tue Jan 18 14:32:38 2011 ... localhost kernel: [Hardware Error]: Run the message through 'mcelog --ascii' to decode. There seems to be no change in config options re MCE since 2.6.33 , the previous kernel, which doesn't suffer from this internal spam. My CPU is an Intel Core 2 Duo. Everything else seems to be working ok. Does anyone have any idea what's going on ? No, but this seems possibly relevant: http://bkhome.org/blog/?viewDetailed=02069
Re: [gentoo-user] kernel 2.6.37 : MCE problem
On Tue, Jan 18, 2011 at 2:51 PM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Tue, Jan 18, 2011 at 1:53 PM, Philip Webb purs...@ca.inter.net wrote: I've just installed compiled gentoo-sources-2.6.37 am getting msgs in all my terminals Message from syslogd@localhost at Tue Jan 18 14:32:38 2011 ... localhost kernel: [Hardware Error]: No human readable MCE decoding support on this CPU type. Message from syslogd@localhost at Tue Jan 18 14:32:38 2011 ... localhost kernel: [Hardware Error]: Run the message through 'mcelog --ascii' to decode. There seems to be no change in config options re MCE since 2.6.33 , the previous kernel, which doesn't suffer from this internal spam. My CPU is an Intel Core 2 Duo. Everything else seems to be working ok. Does anyone have any idea what's going on ? No, but this seems possibly relevant: http://bkhome.org/blog/?viewDetailed=02069 And in the meantime you can perhaps boot with nomce kernel commandline parameter to make it stop trying.
Re: [gentoo-user] Microcode update AMD
On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote: On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht markkne...@gmail.com wrote: On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com wrote: OK, I got it to load by hand: 1) emerge microcode-ctl which also emerges microcode-data. Unfortunately microcode-data looks to be out of date. The ebuild for newer versions (including the latest 20101123) is in portage as ~amd64 and ~x86. Thanks Paul. Also, it does seem to work, for Intel anyway, as a module or built into the kernel. I chose to build it in as I'm tired of how long lsmod is looking these days. If you use the /etc/init.d/microcode_ctl runscript and have MICROCODE_UNLOAD=yes set in /etc/conf.d/microcode_ctl (which is the default), it will unload the module automatically after it runs, so you shouldn't see it in lsmod anyway, and saves a few kb of memory. But, quite honestly, 8kb of memory is probably inconsequential on a system where microcode_ctl is being used in the first place... :) Is the /etc/microcode.dat path a bug, now that firmware is typically placed in /lib/firmware? Shall I create a symlink or raise a bug report? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 2:56 PM, Mick michaelkintz...@gmail.com wrote:
On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht markkne...@gmail.com wrote:
On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
paul.hartman+gen...@gmail.com wrote:
On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com
wrote:
OK, I got it to load by hand:
1) emerge microcode-ctl
which also emerges microcode-data. Unfortunately microcode-data looks
to be out of date.
The ebuild for newer versions (including the latest 20101123) is in
portage as ~amd64 and ~x86.
Thanks Paul.
Also, it does seem to work, for Intel anyway, as a module or built
into the kernel. I chose to build it in as I'm tired of how long lsmod
is looking these days.
If you use the /etc/init.d/microcode_ctl runscript and have
MICROCODE_UNLOAD=yes set in /etc/conf.d/microcode_ctl (which is the
default), it will unload the module automatically after it runs, so
you shouldn't see it in lsmod anyway, and saves a few kb of memory.
But, quite honestly, 8kb of memory is probably inconsequential on a
system where microcode_ctl is being used in the first place... :)
Is the /etc/microcode.dat path a bug, now that firmware is typically placed in
/lib/firmware?
Shall I create a symlink or raise a bug report?
On my ~amd64 system, using microcode-ctl-1.17-r2 and
microcode-data-20101123 the data is installed to /lib/firmware and the
runscript does:
microcode_ctl -qu -f /lib/firmware/microcode.dat -d ${MICROCODE_DEV}
I think the gentoo packages are designed for you to use the installed
runscript which works when you use the microcode-data package from
portage since they both use the /lib/firmware location.
Based on this I would guess that it is not a bug, but that it is the
intended behavior.
Re: [gentoo-user] disk error, where?
Am 18.01.2011 16:30, schrieb Volker Armin Hemmann: yes, rerun badblocks in destructive write mode. Twice. The second time create a badblocks file and use it with mkfs - that way bad blocks should be skipped. Like in: # badblocks -p2 -wv /dev/sdb6 ?
Re: [gentoo-user] Microcode update AMD
On Tuesday 18 January 2011 21:13:49 Paul Hartman wrote:
On Tue, Jan 18, 2011 at 2:56 PM, Mick michaelkintz...@gmail.com wrote:
On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht markkne...@gmail.com
wrote:
On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
paul.hartman+gen...@gmail.com wrote:
On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht markkne...@gmail.com
wrote:
OK, I got it to load by hand:
1) emerge microcode-ctl
which also emerges microcode-data. Unfortunately microcode-data
looks to be out of date.
The ebuild for newer versions (including the latest 20101123) is in
portage as ~amd64 and ~x86.
Thanks Paul.
Also, it does seem to work, for Intel anyway, as a module or built
into the kernel. I chose to build it in as I'm tired of how long lsmod
is looking these days.
If you use the /etc/init.d/microcode_ctl runscript and have
MICROCODE_UNLOAD=yes set in /etc/conf.d/microcode_ctl (which is the
default), it will unload the module automatically after it runs, so
you shouldn't see it in lsmod anyway, and saves a few kb of memory.
But, quite honestly, 8kb of memory is probably inconsequential on a
system where microcode_ctl is being used in the first place... :)
Is the /etc/microcode.dat path a bug, now that firmware is typically
placed in /lib/firmware?
Shall I create a symlink or raise a bug report?
On my ~amd64 system, using microcode-ctl-1.17-r2 and
microcode-data-20101123 the data is installed to /lib/firmware and the
runscript does:
microcode_ctl -qu -f /lib/firmware/microcode.dat -d ${MICROCODE_DEV}
I think the gentoo packages are designed for you to use the installed
runscript which works when you use the microcode-data package from
portage since they both use the /lib/firmware location.
Based on this I would guess that it is not a bug, but that it is the
intended behavior.
Yes Paul, you're right. In the days before /lib/firmware was made available I
recall that /etc/microcode.dat was the default location of the code. Now that
I just ran it by hand once, it complained that /etc/microcode.dat doesn't
exist.
However, following your prompt I looked at the /etc/init.d/microcode-ctl
script and it all makes sense.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Microcode update AMD
On Tue, Jan 18, 2011 at 12:56 PM, Mick michaelkintz...@gmail.com wrote: SNIP Is the /etc/microcode.dat path a bug, now that firmware is typically placed in /lib/firmware? Shall I create a symlink or raise a bug report? -- Regards, Mick Mick, I don't think so. Seems to me Gentoo can put this where ever it wants as long as it matches the init script. - Mark
[gentoo-user] xorg 1.9
I upgraded my xorg from 1.76 to 1.9 yesterday, including downloading the most recent drivers. When the new system did not work, I checked the xorg log (attached) and I thought that the problem was the mode setting. So in the kernel, I enabled the modesetting by default and now the card does not send any signals to the screen at all. I can go back to the old kernel settings. But does anyone know what was the initial problem, and what needs to be done to correct this. Thanks for any advice. [ 331.184] X.Org X Server 1.9.2 Release Date: 2010-10-30 [ 331.204] X Protocol Version 11, Revision 0 [ 331.211] Build Operating System: Linux 2.6.32-gentoo-r7 i686 Gentoo [ 331.218] Current Operating System: Linux 2.6.32-gentoo-r7 #6 SMP Fri Jul 2 11:08:59 Local time zone must be set--see zic m i686 [ 331.231] Kernel command line: root=/dev/sda9 [ 331.239] Build Date: 17 January 2011 06:29:50PM [ 331.246] [ 331.253] Current version of pixman: 0.17.2 [ 331.260] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 331.273] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 331.296] (==) Log file: /var/log/Xorg.0.log, Time: Mon Jan 17 19:25:40 2011 [ 331.304] (++) Using config file: /root/xorg.conf.new [ 331.311] (==) Using system config directory /usr/share/X11/xorg.conf.d [ 331.318] (==) ServerLayout X.org Configured [ 331.318] (**) |--Screen Screen0 (0) [ 331.319] (**) | |--Monitor Monitor0 [ 331.319] (**) | |--Device Card0 [ 331.319] (**) |--Input Device Mouse0 [ 331.319] (**) |--Input Device Keyboard0 [ 331.319] (==) Automatically adding devices [ 331.319] (==) Automatically enabling devices [ 331.319] (WW) The directory /usr/share/fonts/misc/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/TTF/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/OTF/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/Type1/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/100dpi/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/75dpi/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/misc/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/TTF/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/OTF/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/Type1/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/100dpi/ does not exist. [ 331.320] Entry deleted from font path. [ 331.320] (WW) The directory /usr/share/fonts/75dpi/ does not exist. [ 331.321] Entry deleted from font path. [ 331.321] (**) FontPath set to: [ 331.321] (**) ModulePath set to /usr/lib/xorg/modules [ 331.321] (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 331.321] (WW) Disabling Mouse0 [ 331.321] (WW) Disabling Keyboard0 [ 331.321] (II) Loader magic: 0x81f1de0 [ 331.321] (II) Module ABI versions: [ 331.321] X.Org ANSI C Emulation: 0.4 [ 331.321] X.Org Video Driver: 8.0 [ 331.321] X.Org XInput driver : 11.0 [ 331.321] X.Org Server Extension : 4.0 [ 331.323] (--) PCI:*(0:0:2:0) 8086:2562:1028:0160 rev 1, Mem @ 0xe800/134217728, 0xfeb8/524288 [ 331.323] (II) extmod will be loaded. This was enabled by default and also specified in the config file. [ 331.323] (II) dbe will be loaded. This was enabled by default and also specified in the config file. [ 331.323] (II) glx will be loaded. This was enabled by default and also specified in the config file. [ 331.323] (II) record will be loaded. This was enabled by default and also specified in the config file. [ 331.323] (II) dri will be loaded. This was enabled by default and also specified in the config file. [ 331.323] (II) dri2 will be loaded. This was enabled by default and also specified in the config file. [ 331.323] (II) LoadModule: extmod [ 331.324] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [ 331.324] (II) Module extmod: vendor=X.Org Foundation [ 331.324] compiled for 1.9.2, module version = 1.0.0 [ 331.324] Module class: X.Org Server Extension [ 331.324] ABI class: X.Org Server Extension, version 4.0 [ 331.324] (II) Loading extension MIT-SCREEN-SAVER [ 331.324] (II) Loading extension XFree86-VidModeExtension [ 331.325] (II) Loading extension
[gentoo-user] Re: xorg 1.9
On 01/19/2011 06:46 AM, dan blum wrote: I upgraded my xorg from 1.76 to 1.9 yesterday, including downloading the most recent drivers. When the new system did not work, I checked the xorg log (attached) and I thought that the problem was the mode setting. So in the kernel, I enabled the modesetting by default and now the card does not send any signals to the screen at all. I can go back to the old kernel settings. But does anyone know what was the initial problem, and what needs to be done to correct this. Thanks for any advice. You seem to be using kernel 2.6.32. That *might* be the problem. Try 2.6.36. Other than that, the usual stuff applies: Delete your xorg.conf (so that X.Org can automatically configure everything) and make sure you don't have VESAFB enabled in the kernel.
