Re: [gentoo-user] Experiences with ATI Radeon HD 4250 video card?
2010/12/21 Walter Dnes waltd...@waltdnes.org: I'm looking for a Boxing-Day gift for myself. The local Walmart shows an interesting 17 Acer laptop at... http://www.walmart.ca/Electronics/Computers/Laptops/17quot-Laptops/Acer-Aspire-AS7551-3029-173-Notebook Reading the specs, it does not seem to be cutting corners, low price notwithstanding. As usual, my main concern is the video chip, and Gentoo support (or lack thereof?). If it can be made to work under Gentoo without trouble, I'm very interested. Anyone hear one way or the other about linux, especially Gentoo, compatability? My chip is integrated, but it's close to that one. It's a 4200hd card. It works perfectly with the open source (radeon) driver. Compositing works ok as well. I don't do gaming, though. So can't comment on that. The open source drivers is all I would ever recommend for ATi cards. If you plan to use proprietary drivers then I'd use some other brand. -- Jesús Guerrero Botella
Re: [gentoo-user] Experiences with ATI Radeon HD 4250 video card?
On 12/21/10 09:02:32, Jesús J. Guerrero Botella wrote: If you plan to use proprietary drivers then I'd use some other brand. Why? I have several machines with an onboard Radeon HD 3300 chip. The recent versions of x11-drivers/ati-drivers (currently 10.11) run just fine with the lastest kernel (2.6.36) and the latest xorg-server (1.9.2.902) Helmut.
Re: [gentoo-user] Experiences with ATI Radeon HD 4250 video card?
2010/12/21 Helmut Jarausch jarau...@igpm.rwth-aachen.de: On 12/21/10 09:02:32, Jesús J. Guerrero Botella wrote: If you plan to use proprietary drivers then I'd use some other brand. Why? I have several machines with an onboard Radeon HD 3300 chip. The recent versions of x11-drivers/ati-drivers (currently 10.11) run just fine with the lastest kernel (2.6.36) and the latest xorg-server (1.9.2.902) If you have been an fglrx user for a long time you should know that's not the usual case (unless things have changed drastically in the last few months). This driver **usually** doesn't work with latest X and/or kernel. Punctually, it might, but usually you have to keep your system downgraded intentionally to keep these drivers working. I am not advertising any other brand here (and I have mentioned no brand name). Merely describing my experience with fglrx, for several years and until a few months ago. -- Jesús Guerrero Botella
Re: [gentoo-user] Experiences with ATI Radeon HD 4250 video card?
On 12/21/10 11:46:21, Jesús J. Guerrero Botella wrote: 2010/12/21 Helmut Jarausch jarau...@igpm.rwth-aachen.de: On 12/21/10 09:02:32, Jesús J. Guerrero Botella wrote: If you plan to use proprietary drivers then I'd use some other brand. Why? I have several machines with an onboard Radeon HD 3300 chip. The recent versions of x11-drivers/ati-drivers (currently 10.11) run just fine with the lastest kernel (2.6.36) and the latest xorg-server (1.9.2.902) If you have been an fglrx user for a long time you should know that's not the usual case (unless things have changed drastically in the last few months). Yes, I do think it has changed recently. There is even a a more recent version 10.12 but not in the tree, yet. This driver **usually** doesn't work with latest X and/or kernel. Punctually, it might, but usually you have to keep your system downgraded intentionally to keep these drivers working. I am not advertising any other brand here (and I have mentioned no brand name). Merely describing my experience with fglrx, for several years and until a few months ago. -- Jesús Guerrero Botella -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany
Re: [gentoo-user] Experiences with ATI Radeon HD 4250 video card?
On 12/21/10 09:02:32, Jesús J. Guerrero Botella wrote: If you plan to use proprietary drivers then I'd use some other brand. Why? I have several machines with an onboard Radeon HD 3300 chip. The recent versions of x11-drivers/ati-drivers (currently 10.11) run just fine with the lastest kernel (2.6.36) and the latest xorg-server (1.9.2.902) If you have been an fglrx user for a long time you should know that's not the usual case (unless things have changed drastically in the last few months). Yes, I do think it has changed recently. There is even a a more recent version 10.12 but not in the tree, yet. I've been using fglrx for 18 months without problem on amd64 (which is currently using xorg 1.7.7). I would assume that ~amd64/~x86 would be more troublesome as the driver will take some time to catch up with the latest developments.
Re: [gentoo-user] Experiences with ATI Radeon HD 4250 video card?
on 12/21/2010 01:15 AM Walter Dnes wrote the following: I'm looking for a Boxing-Day gift for myself. The local Walmart shows an interesting 17 Acer laptop at... http://www.walmart.ca/Electronics/Computers/Laptops/17quot-Laptops/Acer-Aspire-AS7551-3029-173-Notebook Reading the specs, it does not seem to be cutting corners, low price notwithstanding. As usual, my main concern is the video chip, and Gentoo support (or lack thereof?). If it can be made to work under Gentoo without trouble, I'm very interested. Anyone hear one way or the other about linux, especially Gentoo, compatability? I would recommend a laptop with a graphics card from a vendor, whose name starts with nv... and ends with ...idia(*) O:-) *and* make sure it has adequate ventilation for cooling (reviews should help). (*)It would save you from a lot of trouble with support for 3D drivers ... 8-)
Re: [gentoo-user] Experiences with ATI Radeon HD 4250 video card?
2010/12/21 Adam Carter adamcart...@gmail.com: On 12/21/10 09:02:32, Jesús J. Guerrero Botella wrote: If you plan to use proprietary drivers then I'd use some other brand. Why? I have several machines with an onboard Radeon HD 3300 chip. The recent versions of x11-drivers/ati-drivers (currently 10.11) run just fine with the lastest kernel (2.6.36) and the latest xorg-server (1.9.2.902) If you have been an fglrx user for a long time you should know that's not the usual case (unless things have changed drastically in the last few months). Yes, I do think it has changed recently. There is even a a more recent version 10.12 but not in the tree, yet. I've been using fglrx for 18 months without problem on amd64 (which is currently using xorg 1.7.7). I would assume that ~amd64/~x86 would be more troublesome as the driver will take some time to catch up with the latest developments. Admittedly, I never used stable arch, in either x86 or x86_64. Admittedly -as well- it's been long since I used any proprietary driver. I suggest using the open driver unless you need the extra power for gaming. Depending on your requisites the open driver might be ok for you even if you are a gamer. Such chip is very well supported nowadays when using the radeon free driver, even for 3d. It's just easier and you don't have to recompile anything each time you install a new kernel and/or xorg bumps its version number. -- Jesús Guerrero Botella
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
Dale rdalek1...@gmail.com writes: Le 20 décembre à 15:12 Allan Gottlieb a écrit Something seems wrong. Yesterday depclean removed hal and then xdm wouldn't run. Re-merging hal (with -1) fixed this, but again today depclean wants to remove it. I'm running amd64 here but xdm doesn't show it needing hal here. It's not even in the USE flags and I did a emerge -epv xdm and it still didn't show it. It did pull in policykit tho. Could it be that it doesn't use hal anymore and you need to figure out what it is using? I know hal is going away but I haven't read that it already was. That said, I did notice that policykit was pulled in yesterday. Of course, xdm doesn't show it needs it either. Could it be udev? To summarize 1. All is running fine but. 2. deplcean wants to remove hal and when it does xdm will not run. 3. I have run emerge world with --newuse, and have run revdep-rebuild, and have remerged xdm. 4. Currently I just refuse depclean's offer to remove hal, halinfo, and dmidecode. My plan is to stay like this until xorg 1.9 hits ~amd64 since I believe at that time hal is going away and hence xdm won't need it. Does this sound reasonable? allan PS Why is no one else having this problem?
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
On Tue, Dec 21, 2010 at 6:41 AM, Allan Gottlieb gottl...@nyu.edu wrote: SNIP To summarize 1. All is running fine but. 2. deplcean wants to remove hal and when it does xdm will not run. 3. I have run emerge world with --newuse, and have run revdep-rebuild, and have remerged xdm. 4. Currently I just refuse depclean's offer to remove hal, halinfo, and dmidecode. My plan is to stay like this until xorg 1.9 hits ~amd64 since I believe at that time hal is going away and hence xdm won't need it. Does this sound reasonable? To me, yes. If you make a mistake and depclean hal by mistake then it seems you can get it back in. allan PS Why is no one else having this problem? I don't use xdm? Granted, it seems my current state is a bit strange. There is a lot of stuff on my system that says it depends on hal, but then again i don't start it explicitly. Other things apparently do however: c2stable ~ # equery depends hal [ Searching for packages depending on hal... ] app-cdr/k3b-2.0.0 (sys-apps/hal) app-emulation/vmware-workstation-7.1.2.301548 (sys-apps/hal) app-misc/hal-info-20090716 (=sys-apps/hal-0.5.10) gnome-base/gnome-applets-2.30.0-r1 (battstat hal? =sys-apps/hal-0.5.3) gnome-base/gnome-vfs-2.24.3-r1 (hal? =sys-apps/hal-0.5.7) gnome-base/gvfs-1.6.4-r2 (hal? =sys-apps/hal-0.5.10) gnome-extra/gnome-power-manager-2.30.1 (hal? =sys-apps/hal-0.5.9) kde-base/solid-4.4.5 (hal? sys-apps/hal) media-libs/libgphoto2-2.4.9 (hal? =sys-apps/hal-0.5) x11-base/xorg-server-1.7.7-r1 (hal? sys-apps/hal) x11-drivers/xf86-input-virtualbox-3.2.12 (hal? sys-apps/hal) xfce-base/exo-0.3.107 (hal? sys-apps/hal) xfce-base/thunar-1.0.2 (hal? sys-apps/hal) c2stable ~ # rc-update show bootmisc | boot checkfs | boot checkroot | boot clock | boot consolefont | boot dbus | default hostname | boot keymaps | boot local | default nonetwork localmount | boot modules | boot net.eth0 | default net.lo | boot netmount | default ntp-client | default ntpd | default rmnologin | boot sshd | default syslog-ng | default udev-postmount | default urandom | boot vixie-cron | default vmware | default xdm | default c2stable ~ # /etc/init.d/hald status * status: started c2stable ~ # I sort of figure that one of these days I'll see what I can build that uses it today without it and then see how things go. In the short terms it's sort of 'it ain't broke so...' Note that I don't 'try' to use hal. It just shows up. I don't ask for it in package.use and it's supposedly disabled in make.conf. Ah, the mysteries of Life... ;-) c2stable ~ # cat /etc/portage/package.use | grep hal c2stable ~ # cat /etc/make.conf | grep hal USE=nptl nptlonly -ipv6 fortran unicode -hal dbus X -bluetooth -esound -timidity -cups -java gnome gstreamer kde qt4 qt3support -arts -eds pngi policykit c2stable ~ # Cheers, Mark
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
Allan Gottlieb wrote: Dalerdalek1...@gmail.com writes: Le 20 décembre à 15:12 Allan Gottlieb a écrit Something seems wrong. Yesterday depclean removed hal and then xdm wouldn't run. Re-merging hal (with -1) fixed this, but again today depclean wants to remove it. I'm running amd64 here but xdm doesn't show it needing hal here. It's not even in the USE flags and I did a emerge -epv xdm and it still didn't show it. It did pull in policykit tho. Could it be that it doesn't use hal anymore and you need to figure out what it is using? I know hal is going away but I haven't read that it already was. That said, I did notice that policykit was pulled in yesterday. Of course, xdm doesn't show it needs it either. Could it be udev? To summarize 1. All is running fine but. 2. deplcean wants to remove hal and when it does xdm will not run. 3. I have run emerge world with --newuse, and have run revdep-rebuild, and have remerged xdm. 4. Currently I just refuse depclean's offer to remove hal, halinfo, and dmidecode. My plan is to stay like this until xorg 1.9 hits ~amd64 since I believe at that time hal is going away and hence xdm won't need it. Does this sound reasonable? allan PS Why is no one else having this problem? Well, if it helps any, I'm already running xorg 1.9. Here is my list: [I--] [ ~] x11-base/xorg-drivers-1.9 (0) [I--] [ ~] x11-base/xorg-server-1.9.2.902 (0) They are working fine here so you may want to just go ahead and upgrade. This is the settings for mine here: [ebuild R ] x11-base/xorg-server-1.9.2.902 USE=ipv6 nptl udev xorg -dmx -doc -kdrive -minimal -static-libs -tslib 0 kB It uses udev instead of hal. I didn't have to run a unstable version of udev either. I'm sure it is some sort of setting somewhere but no idea why you are the only one running into this. Dale :-) :-)
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
On 12/21/10 15:41:20, Allan Gottlieb wrote: My plan is to stay like this until xorg 1.9 hits ~amd64 since I It is already unmasked in ~amd64 (It's running just fine here) Helmut.
Re: [gentoo-user] distcc and crossdev, anyone?
On Tue, Dec 21, 2010 at 1:56 AM, Bill Longman bill.long...@gmail.comwrote: On 12/18/2010 07:15 AM, Peter Humphrey wrote: On Saturday 18 December 2010 10:18:43 Neil Bothwick wrote: I've found there's just too much overhead with distcc, plus much of the work is still done locally. I expected that but I wanted to try it to see. I have a couple of Atom boxes, a server and a netbook, and I've set up a chroot for each on my workstation. In the chroot I have FEATURES=buildpkg, using an NFS mounted PKGDIR available to both computers, then I emerge -k on the Atom box. Maybe I'll go this way instead. Thanks for the idea, which is similar to one from YoYo Siska three days ago. I had my Atom 330 running as a distcc client for a long time. I have several other speedy CPUs alongside it so it could spray plenty of compilation requests out its gigabit NIC to various much beefier machines. But as Neil stated, lots of the processing still occurs locally, so as you increase nodes, you need to decrease the amount of compilation done locally. With such a disparity between CPU, it takes less time overall to just do it the way Neil describes - make a chroot and then just build it with the intention that the slow CPUs will use the binary build. You still need lots of CPU to compile, so a slow machine will still compile slowly. If your client is a pokey 1.6GHz Atom and you're sending jobs to two quad core 3GHz CPUs on your subnet, you'll soon see that the Atom's load goes up toward 8 as it tries to bring those remote jobs back. So, the four threads on my 330 get completely filled up and it's dog slow. And it's even more painful when you use the preprocessor because the client must zip the compile construction before it ships it out, so you have even less CPU available for compilation (although you get some of that back). All said and done, my back-of-the-napkin and seat-of-the-pants calculation tells me that I still get a _minimum_ 25% reduction in overall compile times with distcc. That's my experience after using distcc for almost ten years with various configurations of network and CPUs. I have set up my system as Neil described chroots for different systems on a fast computer. I use this setup for my gentoo boxes I have and it has made my compilations fast(er). I tried to use distcc with one U2300 celeron and some amd 4x cpu and the amd didn't really compile, because the U2300 was a bottleneck, so I decided to chroot it and been happy ever since. I have been thinking about a tool that could automagically start the emerge on the remote system. I thought about just ssh in with a script. But I am on so many flaky Internet connections that it isn't reliable enough. Petri
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
On 12/21/2010 9:41 AM, Allan Gottlieb wrote: To summarize 1. All is running fine but. 2. deplcean wants to remove hal and when it does xdm will not run. Is it just xdm that doesn't run? That is, if you disable xdm and log in via the console, can you run startx? It's possible that your Xorg configuration is relying on some device or setting that HAL is providing for you but udev itself isn't. (Can't think of anything specific offhand, though). If this were the case, trying to run X by itself as root should also fail. You would also see the errors in your Xorg.0.log file, pointing to whichever device is the problem. To fix this, you'd need to find and remove the offending device reference. A good first start is to try simply removing any xorg.conf you happen to have lying around and let X try to find everything itself (without HAL). --Mike
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
Helmut Jarausch jarau...@igpm.rwth-aachen.de writes: On 12/21/10 15:41:20, Allan Gottlieb wrote: My plan is to stay like this until xorg 1.9 hits ~amd64 since I It is already unmasked in ~amd64 (It's running just fine here) Bingo. There was a mesa problem a while ago (7.8.2) that caused me to mask =media-libs/mesa-7.8.2. This caused me to mask xorg-server above the current running one. I didn't notice that mesa did advance and I am running 7.9-r1. So I just now unmasked both mesa and xorg-server and update world updated xorg-server and xinit. Let's see if this now permits me to let depclean remove hal. thank you all for your help! allan
[gentoo-user] Re: Experiences with ATI Radeon HD 4250 video card?
Walter Dnes waltdnes at waltdnes.org writes: I'm looking for a Boxing-Day gift for myself. The local Walmart shows an interesting 17 Acer laptop at... I never had an Acer before. I have this video card, fanless: 2:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] (prog-if 00 [VGA controller]) Kernel driver in use: fglrx_pci Kernel modules: fglrx It works fine with ati-drivers (currently using : xorg-server-1.7.7-r1 ati-drivers-10.9-r1 xorg-x11-7.4-r1 linux - linux-2.6.34-gentoo-r6 with and xorg.conf file... hth, James
[gentoo-user] SOLVED: Re: depclean wants to remove hal, which kills xdm
Allan Gottlieb gottl...@nyu.edu writes: Helmut Jarausch jarau...@igpm.rwth-aachen.de writes: On 12/21/10 15:41:20, Allan Gottlieb wrote: My plan is to stay like this until xorg 1.9 hits ~amd64 since I It is already unmasked in ~amd64 (It's running just fine here) Bingo. There was a mesa problem a while ago (7.8.2) that caused me to mask =media-libs/mesa-7.8.2. This caused me to mask xorg-server above the current running one. I didn't notice that mesa did advance and I am running 7.9-r1. So I just now unmasked both mesa and xorg-server and update world updated xorg-server and xinit. Let's see if this now permits me to let depclean remove hal. It all works fine. Depclean removed hal and friends and a reboot still has X and xdm (i.e., gdm). thanks again. allan
