Hi,
I have been using Centos since 3.0. I have been upgrading regularly without any major problem.
4.1 to 4.2 has been a total disaster.
I ran yum update, it went through and a couple of hours later I rebooted and X froze with the screen just being just fuzz [regular rectangles, orange, green...] and the keyboard froze. Could not do a alt-ctrl-backspace, nor a Alt-F1-6 nor Alt-Ctrl-Del.
I have a ATI9200 with a Samsung 710N [It only works at 1240x1024 @ 60Hz, it will not work at any other frequency]
This is the same hardware as I was running with 4.1.
I had to reinstall 4.1, now I cannot run yum update to get the security updates, it tries to upgrade to 4.2.
1. Is there a way to just get the updates for 4.1 and not 4.2 2. Any suggestion on what went wrong with X. It's not just the frequency display because the keyboard also froze.
Thanks
I installed Centos 4.2 the day it was released. It was a 512MB Ram, Sempron 2800+, Asus K8N-E Deluxe motherboard. The install from DVD went fine. However the computer wouldn't boot. Grub froze after flashing the Loading stage 2 screen with a blank screen. Booting from rescue resulted in rescue mode (anaconda I assume) finishing with an error just after I selected network interfaces on. Booting from rescue again (with network off) and fixing grub.conf not to use the splash screen didn't help - still didn't boot from HDD. Finally I rebooted from rescue and reinstalled grub - this time the computer boots normally. I went through firstboot configuration and X booted ok and I logged into gdm, did some minor configuration tasks (nothing to do with X, mostly iptables related stuff, adding a user, copying a few DVDs as iso images onto the 120GB disk for later and to speed access) and rebooted. This time the computer froze upon loading the X server. Mouse would work (move a big block of horizontal random colored lines over a screen full of horizontal random colored lines) but keyboard wouldn't (not leds not ctrl+alt+backspac). Had to do a reset. This time after verifying nothing got borked on disk it froze again. Had to switch to run level 4 do disable gdm. Since then the system has been running, but it doesn't seem to be very snappy (but that might not be the OS's fault).
Comments? Cheers, Maciej Z.
On Sun, 16 Oct 2005, Syv Ritch wrote:
Hi,
I have been using Centos since 3.0. I have been upgrading regularly without any major problem.
4.1 to 4.2 has been a total disaster.
I ran yum update, it went through and a couple of hours later I rebooted and X froze with the screen just being just fuzz [regular rectangles, orange, green...] and the keyboard froze. Could not do a alt-ctrl-backspace, nor a Alt-F1-6 nor Alt-Ctrl-Del.
I have a ATI9200 with a Samsung 710N [It only works at 1240x1024 @ 60Hz, it will not work at any other frequency]
This is the same hardware as I was running with 4.1.
I had to reinstall 4.1, now I cannot run yum update to get the security updates, it tries to upgrade to 4.2.
- Is there a way to just get the updates for 4.1 and not 4.2
- Any suggestion on what went wrong with X. It's not just the frequency
display because the keyboard also froze.
Thanks _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 10/16/05, Maciej Żenczykowski maze@cela.pl wrote:
I installed Centos 4.2 the day it was released. It was a 512MB Ram, Sempron 2800+, Asus K8N-E Deluxe motherboard. The install from DVD went fine. However the computer wouldn't boot.
On Sun, 16 Oct 2005, Syv Ritch wrote:
4.1 to 4.2 has been a total disaster.
I ran yum update, it went through and a couple of hours later I rebooted and X froze with the screen just being just fuzz
Hmmm, for me 4.2 (upgraded via yum) thus far has been a big ho-hum - nothing has changed. I have a P4 with onboard Sis (crappy) video card. I'll have to try the upgrade on my laptop.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Collins Richey wrote:
Hmmm, for me 4.2 (upgraded via yum) thus far has been a big ho-hum - nothing has changed. I have a P4 with onboard Sis (crappy) video card. I'll have to try the upgrade on my laptop.
Same here, on slightly different hardware. My DFI NFII Ultra Infinity with 1 GB RAM and an nVidia 5700FX upgraded from 4.1 to 4.2 with no problems beyond saturated Yum mirrors. (grin!) I had the usual problems with the proprietary nVidia driver, but that was expected.
Your mileage may vary!
Maciej Żenczykowski wrote:
I installed Centos 4.2 the day it was released. It was a 512MB Ram, Sempron 2800+, Asus K8N-E Deluxe motherboard. The install from DVD went fine. However the computer wouldn't boot. Grub froze after flashing the Loading stage 2 screen with a blank screen. Booting from rescue resulted in rescue mode (anaconda I assume) finishing with an error just after I selected network interfaces on. Booting from rescue again (with network off) and fixing grub.conf not to use the splash screen didn't help - still didn't boot from HDD. Finally I rebooted from rescue and reinstalled grub - this time the computer boots normally. I went through firstboot configuration and X booted ok and I logged into gdm, did some minor configuration tasks (nothing to do with X, mostly iptables related stuff, adding a user, copying a few DVDs as iso images onto the 120GB disk for later and to speed access) and rebooted. This time the computer froze upon loading the X server. Mouse would work (move a big block of horizontal random colored lines over a screen full of horizontal random colored lines) but keyboard wouldn't (not leds not ctrl+alt+backspac). Had to do a reset. This time after verifying nothing got borked on disk it froze again. Had to switch to run level 4 do disable gdm. Since then the system has been running, but it doesn't seem to be very snappy (but that might not be the OS's fault).
Comments? Cheers, Maciej Z.
Mine isn't hosed; just slightly confused.
I did a yum upgrade AFTER first manually installing the new kernel. Everything went great until I noticed that there hadn't been any screen scrolling for a couple hours. Investigation showed that the yum python module had taken a nap. After some thought, I decided I could either kill it or wait for the next power failure that exceeded my UPS which would have been a no-brainer even without a current backup (which I had). So, I killed the process, checked the GRUB, gritted my teeth and rebooted. All appeared normal except for a screwed up yum database. At least, I hope that's all it is and I'll find out Wednesday morning following another weekly full backup.
First screen of output from #rpm -qa | sort | less looks like this (annotated) 4Suite-1.0-3 a2ps-4.13b-41 aalib-1.4.0-5.2.el4.rf acl-2.2.23-5 acpid-1.0.3-2 acroread-5.0.10-1.2.el4.rf alchemist-1.0.34-1 alchemist-devel-1.0.34-1 alsa-lib-1.0.6-5.RHEL4 alsa-lib-devel-1.0.6-5.RHEL4 alsa-utils-1.0.6-3 <<<<-- Hello! alsa-utils-1.0.6-4 amanda-2.4.4p3-1 amanda-client-2.4.4p3-1 amanda-devel-2.4.4p3-1 amanda-server-2.4.4p3-1 am-utils-6.0.9-10 am-utils-6.0.9-15.RHEL4 anaconda-10.1.1.19-1.centos4 <<<-- Hello again anaconda-10.1.1.25-1.centos4 anaconda-help-10.1.0-1.centos4 anaconda-product-4.0-2.centos4 anaconda-runtime-10.1.1.19-1.centos4 anaconda-runtime-10.1.1.25-1.centos4 anacron-2.3-32 apel-10.6-5 apel-xemacs-10.6-5 apmd-3.0.2-24 apr-0.9.4-24.3 : ...so, it looks like rebuilding the RPM database will bring happiness. My sympathy to those with *real* damage.
Robert wrote:
I did a yum upgrade AFTER first manually installing the new kernel.
why did you manually need to install the kernel ? you can / should use yum to do that for you. perhaps go with a 'yum update yum' before you kick everything off with a 'yum update'. if you really want the kernel in and running before you do the yum update, then do a yum update yum; yum update kernel; reboot; yum update
- K
Karanbir Singh wrote:
Robert wrote:
I did a yum upgrade AFTER first manually installing the new kernel.
why did you manually need to install the kernel ?
Because a "yum update kernel" offered to install the -SMP kernel. This is, no doubt, an artifact of anaconda & associates deciding at the time CentOS4 was first installed that an SMP kernel was appropriate for an Athlon XP in an ASUS A7NX8 ver.2 deluxe m/b, compounded by my packrat reluctance to throw it away at the outset.
you can / should use yum to do that for you. perhaps go with a 'yum update yum' before you kick everything off with a 'yum update'.
THAT is what I would definitely do different.
if you really want the kernel in and running before you do the yum update, then do a yum update yum; yum update kernel; reboot; yum update
No. I didn't want -- or have -- the new kernel running before the update. I simply wanted it to be available.
I'm reasonably sure everything is gonna be O.K. Yum is one of the packages that gets reported twice:
[root@mavis yum.repos.d]# rpm -q yum yum-2.2.1-1.centos4 yum-2.4.0-1.centos4
The correct version gets executed:
[root@mavis yum.repos.d]# yum --version 2.4.0
...but the list of files installed is screwy. So, it looks like my work is cut out for me:
[root@mavis yum]# rpm -qa | gawk -F-[0123456789] '{ print $1 }' | sort | uniq | wc -l 1433 [root@mavis yum]# rpm -qa | gawk -F-[0123456789] '{ print $1 }' | sort | wc -l 1655
I'm not overwhelmed by brilliant ideas for scripting the obvious. :-(
FWIW:
A yum upgrade on my main server (no pre-loading kernel, yum, etc), caused a hiccup. I didn't see the x86_64 release notes until too late. I did see the useradd chomping down CPU time. I ignored it as long as possible, but then the install wound up hanging the machine. Rebooted, and had to do some fancy tweaking using yum to restore the system to a stable state. Not difficult, just a minor annoyance.
I am not sure if others are having issues with the 4.2 upgrade, but it might be a good idea to avoid upgrading the package (I think it was mysql) to avoid hitting that.
That said, apart from a missing firewire driver, I am quite happy with Centos (and that is an upstream provider issue, addressed for the most part in centosplus). The minor pain I went through with this is nothing compared to the days of sheer abject terror I went through using other distributions "upgrade" system.
Good work folks!
joe
Robert wrote:
Karanbir Singh wrote:
Robert wrote:
I did a yum upgrade AFTER first manually installing the new kernel.
why did you manually need to install the kernel ?
Because a "yum update kernel" offered to install the -SMP kernel. This is, no doubt, an artifact of anaconda & associates deciding at the time CentOS4 was first installed that an SMP kernel was appropriate for an Athlon XP in an ASUS A7NX8 ver.2 deluxe m/b, compounded by my packrat reluctance to throw it away at the outset.
you can / should use yum to do that for you. perhaps go with a 'yum update yum' before you kick everything off with a 'yum update'.
THAT is what I would definitely do different.
if you really want the kernel in and running before you do the yum update, then do a yum update yum; yum update kernel; reboot; yum update
No. I didn't want -- or have -- the new kernel running before the update. I simply wanted it to be available.
I'm reasonably sure everything is gonna be O.K. Yum is one of the packages that gets reported twice:
[root@mavis yum.repos.d]# rpm -q yum yum-2.2.1-1.centos4 yum-2.4.0-1.centos4
The correct version gets executed:
[root@mavis yum.repos.d]# yum --version 2.4.0
...but the list of files installed is screwy. So, it looks like my work is cut out for me:
[root@mavis yum]# rpm -qa | gawk -F-[0123456789] '{ print $1 }' | sort | uniq | wc -l 1433 [root@mavis yum]# rpm -qa | gawk -F-[0123456789] '{ print $1 }' | sort | wc -l 1655
I'm not overwhelmed by brilliant ideas for scripting the obvious. :-(
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Joe Landman wrote:
FWIW: I am not sure if others are having issues with the 4.2 upgrade, but it might be a good idea to avoid upgrading the package (I think it was mysql) to avoid hitting that.
the useradd / audit issue is not specific to the mysql pkg.
what kernel were you running at the time( before the update ) ? smp-2.6.9-11.x86_64 should have been ok.. the only machines I got hit with were x86_64 SMP running 2.6.9-5.0.5
- K
Hi Robert,
Robert wrote:
why did you manually need to install the kernel ?
Because a "yum update kernel" offered to install the -SMP kernel. This is, no doubt, an artifact of anaconda & associates deciding at the time CentOS4 was first installed that an SMP kernel was appropriate for an Athlon XP in an ASUS A7NX8 ver.2 deluxe m/b, compounded by my packrat reluctance to throw it away at the outset.
if you remove the kernel-smp ( which, based on your statement - you dont seem to be using) yum should not update it :) technically, only packages already installed are updated ( or pkgs that satisfy depends for other pkgs ).
Anyway, if anaconda left behind a smp kenel on UP machine, sounds like a bugreport to me.....
I'm reasonably sure everything is gonna be O.K. Yum is one of the packages that gets reported twice:
sounds like you are going to have a fun filled Monday morning. I forsee rpm and coffee in your immediate future. Be a good idea to backup the rpmdb somewhere. Just in case.
remove everything apart from the Packages file from /var/lib/rpm - then rebuild the db ( rpm -v --rebuilddb ). then try work with the -V option to verify what you have what rpm thinks you have.
- K
Karanbir Singh wrote:
Hi Robert,
Robert wrote:
why did you manually need to install the kernel ?
Because a "yum update kernel" offered to install the -SMP kernel. This is, no doubt, an artifact of anaconda & associates deciding at the time CentOS4 was first installed that an SMP kernel was appropriate for an Athlon XP in an ASUS A7NX8 ver.2 deluxe m/b, compounded by my packrat reluctance to throw it away at the outset.
if you remove the kernel-smp ( which, based on your statement - you dont seem to be using) yum should not update it :) technically, only packages already installed are updated ( or pkgs that satisfy depends for other pkgs ).
Anyway, if anaconda left behind a smp kenel on UP machine, sounds like a bugreport to me.....
Not only leaves it behind but configures GRUB to make SMP the default. Drives NTP nuts! I should be shot for not removing it when I first installed CentOS4. It'll be gone when the smoke clears from my upcoming exercise.
I'm reasonably sure everything is gonna be O.K. Yum is one of the packages that gets reported twice:
sounds like you are going to have a fun filled Monday morning. I forsee rpm and coffee in your immediate future. Be a good idea to backup the rpmdb somewhere. Just in case.
remove everything apart from the Packages file from /var/lib/rpm - then rebuild the db ( rpm -v --rebuilddb ). then try work with the -V option to verify what you have what rpm thinks you have.
- K
Thanks for the advice. My Monday and Tuesday have already been scheduled for other joyous tasks, so I'll attack this fiasco Wednesday. (Now that I'm retired, I wonder almost daily how the hell I ever had time to work!) At any rate, I've already burned /var/lib/rpm to a CD and I'll have a brand new full backup by about 3:00 AM Wednesday.
Robert wrote:
Karanbir Singh wrote:
Hi Robert,
Robert wrote:
why did you manually need to install the kernel ?
Because a "yum update kernel" offered to install the -SMP kernel. This is, no doubt, an artifact of anaconda & associates deciding at the time CentOS4 was first installed that an SMP kernel was appropriate for an Athlon XP in an ASUS A7NX8 ver.2 deluxe m/b, compounded by my packrat reluctance to throw it away at the outset.
if you remove the kernel-smp ( which, based on your statement - you dont seem to be using) yum should not update it :) technically, only packages already installed are updated ( or pkgs that satisfy depends for other pkgs ).
Anyway, if anaconda left behind a smp kenel on UP machine, sounds like a bugreport to me.....
Not only leaves it behind but configures GRUB to make SMP the default. Drives NTP nuts! I should be shot for not removing it when I first installed CentOS4. It'll be gone when the smoke clears from my upcoming exercise.
I'm reasonably sure everything is gonna be O.K. Yum is one of the packages that gets reported twice:
sounds like you are going to have a fun filled Monday morning. I forsee rpm and coffee in your immediate future. Be a good idea to backup the rpmdb somewhere. Just in case.
remove everything apart from the Packages file from /var/lib/rpm - then rebuild the db ( rpm -v --rebuilddb ). then try work with the -V option to verify what you have what rpm thinks you have.
- K
Thanks for the advice. My Monday and Tuesday have already been scheduled for other joyous tasks, so I'll attack this fiasco Wednesday. (Now that I'm retired, I wonder almost daily how the hell I ever had time to work!) At any rate, I've already burned /var/lib/rpm to a CD and I'll have a brand new full backup by about 3:00 AM Wednesday.
I rebuilt the rpm database but when I verified the packages, the number of output lines approached the vaalue of 1/0 as a limit. But that's neither here nor there. I'll get over the fresh install of CentOS4.2. What I was really interested in commenting on is anaconda's penchant for installing the SMP kernel *and making it the default* when the UP is clearly (to humans, anyhow) indicated. Here is my untouched-at-this-point grub.conf: [root@mavis ~]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 # initrd /initrd-version.img #boot=/dev/hdb default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS-4 i386 (2.6.9-22.ELsmp) root (hd0,0) kernel /vmlinuz-2.6.9-22.ELsmp ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-22.ELsmp.img title CentOS-4 i386-up (2.6.9-22.EL) root (hd0,0) kernel /vmlinuz-2.6.9-22.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-22.EL.img [root@mavis ~]#
[root@mavis ~]# grep ' kernel' install.log Installing kernel-2.6.9-22.EL.i686. Installing kernel-smp-2.6.9-22.EL.i686. Installing kernel-utils-2.4-13.1.69.i386. Installing kernel-devel-2.6.9-22.EL.i686. Installing kernel-hugemem-devel-2.6.9-22.EL.i686. Installing kernel-smp-devel-2.6.9-22.EL.i686. Installing kernel-doc-2.6.9-22.EL.noarch. [root@mavis ~]# =========================
This excerpt from /var/log/dmesg shows that anaconda correctly identifies both the m/b and, a few lines from the end of this snippet, the CPU. =========================================== HighMem zone: 0 pages, LIFO batch:1 DMI 2.2 present. Asus A7N8X v2 detected: BIOS IRQ0 pin2 override will be ignored ACPI: RSDP (v000 Nvidia ) @ 0x000f75e0 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff74c0 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000 ACPI: PM-Timer IO Port: 0x4008 Built 1 zonelists Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet Initializing CPU#0 CPU 0 irqstacks, hard=c03e5000 soft=c03e4000 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1913.094 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 514240k/524224k available (2111k kernel code, 9412k reserved, 667k data, 144k init, 0k highmem) Calibrating delay loop... 3776.51 BogoMIPS (lpj=1888256) Security Scaffold v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode There is already a security framework initialized, register_security failed. selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After all inits, caps: 0383f3ff c1c3fbff 00000000 00000020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) XP 2600+ stepping 00 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: IRQ9 SCI: Edge set to Level Trigger. checking if image is initramfs... it is =================================
I'm NOT trying to blame anaconda or anyone else for the exercise I've been through today, merely pointing out the reason that I manually installed the kernel before doing the upgrade.
Best regards to all who have made CentOS happen! Robert
On Sun, 2005-10-16 at 12:23 -0700, Syv Ritch wrote:
Hi,
I have been using Centos since 3.0. I have been upgrading regularly without any major problem.
4.1 to 4.2 has been a total disaster.
I ran yum update, it went through and a couple of hours later I rebooted and X froze with the screen just being just fuzz [regular rectangles, orange, green...] and the keyboard froze. Could not do a alt-ctrl-backspace, nor a Alt-F1-6 nor Alt-Ctrl-Del.
I have a ATI9200 with a Samsung 710N [It only works at 1240x1024 @ 60Hz, it will not work at any other frequency]
This is the same hardware as I was running with 4.1.
I had to reinstall 4.1, now I cannot run yum update to get the security updates, it tries to upgrade to 4.2.
- Is there a way to just get the updates for 4.1 and not 4.2
- Any suggestion on what went wrong with X. It's not just the
frequency display because the keyboard also froze.
Thanks
The first thing that came to my mind that there was something not nice between 3.0 and 4.X but reading on you are already running 4.1 as I.
I confess that I was kinda in the dark...about 10 days ago I unsubscribed to this list and then yest. morn. I started to upgrade and knew something big was going on but didn't really know til I read on the Centos' site.
I am sorry to hear of the problems and I guess I consider myself lucky. Using yum update I updated all 3 of my machines w/no problems other than a hell of a lot of time to do it and lots of restarting the update process.
All 3 of my machines are stictly generic...most people would probably call them junk and they probably right but I must say I have had no problems upgrading.
thx
John Rose
ATI hardware and linux typcially don't get along IME. I am wondering if this is the key to your issue?
Syv Ritch wrote:
Hi,
I have been using Centos since 3.0. I have been upgrading regularly without any major problem.
4.1 to 4.2 has been a total disaster.
I ran yum update, it went through and a couple of hours later I rebooted and X froze with the screen just being just fuzz [regular rectangles, orange, green...] and the keyboard froze. Could not do a alt-ctrl-backspace, nor a Alt-F1-6 nor Alt-Ctrl-Del.
I have a ATI9200 with a Samsung 710N [It only works at 1240x1024 @ 60Hz, it will not work at any other frequency]
This is the same hardware as I was running with 4.1.
I had to reinstall 4.1, now I cannot run yum update to get the security updates, it tries to upgrade to 4.2.
- Is there a way to just get the updates for 4.1 and not 4.2
- Any suggestion on what went wrong with X. It's not just the frequency
display because the keyboard also froze.
Thanks _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sunday 16 October 2005 15:23, Syv Ritch wrote:
I ran yum update, it went through and a couple of hours later I rebooted and X froze with the screen just being just fuzz [regular rectangles, orange, green...] and the keyboard froze. Could not do a alt-ctrl-backspace, nor a Alt-F1-6 nor Alt-Ctrl-Del.
I have a ATI9200 with a Samsung 710N [It only works at 1240x1024 @ 60Hz, it will not work at any other frequency]
Ok, a couple of data points, and a suggestion.
First, updated my Dell 600m laptop. Following is the video card: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [FireGL 9000] (rev 02) (prog-if 00 [VGA]) Subsystem: Dell: Unknown device 011e Flags: bus master, VGA palette snoop, stepping, 66Mhz, medium devsel, latency 32, IRQ 11 Memory at e8000000 (32-bit, prefetchable) [size=128M] I/O ports at c000 [size=256] Memory at fcff0000 (32-bit, non-prefetchable) [size=64K] Capabilities: <available only to root>
Ok, that works fine.
Next, updated a Dell 2850 with the following video card: 0b:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA]) Subsystem: Dell: Unknown device 016d Flags: bus master, VGA palette snoop, stepping, medium devsel, latency 32, IRQ 185 Memory at d0000000 (32-bit, prefetchable) [size=128M] I/O ports at cc00 [size=256] Memory at df4f0000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2
Same symptoms you have. I worked around it by disabling rhgb on the boot line (see /boot/grub/grub.conf and remove all rhgb kernel command line parameters). Probably something related to the kernel DRM/DRI stuff, although the problem persists regardless of kernel I boot (the .11 kernel had been working fine, but with the new Xorg it didn't).
Lamar Owen wrote:
Same symptoms you have. I worked around it by disabling rhgb on the boot line (see /boot/grub/grub.conf and remove all rhgb kernel command line parameters). Probably something related to the kernel DRM/DRI stuff, although the problem persists regardless of kernel I boot (the .11 kernel had been working fine, but with the new Xorg it didn't).
Thanks but actually, I have already tried it by removing "rhgb quiet" from grub to see what happened and X still died. X dies after rhgb ends.
I don't think that this has anything to do with with the kernel. I downloaded Ubuntu 5.10 and tried to install and the same thing happened. They use 2.6.12... It must be either the radeon driver that is bad or X itself.
Other people have reported having similar problem with ATI on both Suse 10 and Ubuntu 5.10, so it must be something recent in X.
I don't think it's video-card related.
My home system is runnign CentOS 3. I run it in runmode 3, and then use tightvnc-server from Dag's site to access the GUI as necessary. After I yum updated today, the vnc-server won't refresh the whole screen. I tried uninstalling tightvnc-server and installing vnc-server. Same issue.
My guess is that it's something to do with the X.org system, but I'm not familiar with the source at all.
I'm glad I checked here that 4.x is borked as well, I was getting ready to re-load my system with 4.2...
Ben
Syv Ritch wrote:
Lamar Owen wrote:
Same symptoms you have. I worked around it by disabling rhgb on the boot line (see /boot/grub/grub.conf and remove all rhgb kernel command line parameters). Probably something related to the kernel DRM/DRI stuff, although the problem persists regardless of kernel I boot (the .11 kernel had been working fine, but with the new Xorg it didn't).
Thanks but actually, I have already tried it by removing "rhgb quiet" from grub to see what happened and X still died. X dies after rhgb ends.
I don't think that this has anything to do with with the kernel. I downloaded Ubuntu 5.10 and tried to install and the same thing happened. They use 2.6.12... It must be either the radeon driver that is bad or X itself.
Other people have reported having similar problem with ATI on both Suse 10 and Ubuntu 5.10, so it must be something recent in X. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 2005-10-19 at 14:30 -0500, Benjamin J. Weiss wrote:
I don't think it's video-card related.
<snip>
I'm glad I checked here that 4.x is borked as well, I was getting ready to re-load my system with 4.2...
Ben
Syv Ritch wrote:
Lamar Owen wrote:
Same symptoms you have. I worked around it by disabling rhgb on the boot line (see /boot/grub/grub.conf and remove all rhgb kernel command line parameters). Probably something related to the kernel DRM/DRI stuff, although the problem persists regardless of kernel I boot (the .11 kernel had been working fine, but with the new Xorg it didn't).
Thanks but actually, I have already tried it by removing "rhgb quiet" from grub to see what happened and X still died. X dies after rhgb ends.
I don't think that this has anything to do with with the kernel. I downloaded Ubuntu 5.10 and tried to install and the same thing happened. They use 2.6.12... It must be either the radeon driver that is bad or X itself.
Other people have reported having similar problem with ATI on both Suse 10 and Ubuntu 5.10, so it must be something recent in X. _______________________________________________
<snip>
I was concerned because of the posts I saw. So I followed suggestions and upgraded w/o problems. ATI Radeon (AGP), AK-77/400 (Max/N) Mobo, AMD 180MHz (220PR).
(--) PCI:*(1:0:0) ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] rev 0, Mem @ 0xd8000000/27, 0xe1000000/16, I/O @ 0xc000/8
I Did yum update of up2date, yum update of yum. Rebooted. Updated kernel. Installed all updates *except* everything start with "X" (actually, anything I could ID as coming from X-org and a few extras just to be sure), reboot, removing the rhgb.
Install all the rest, reboot normally. Not one problem yet. I know the 64 bit machines seed to report the most (only?) problems.
HTH
On Wed, 2005-10-19 at 16:50 -0400, William L. Maltby wrote:
On Wed, 2005-10-19 at 14:30 -0500, Benjamin J. Weiss wrote:
I don't think it's video-card related.
<snip>
I'm glad I checked here that 4.x is borked as well, I was getting ready to re-load my system with 4.2...
Ben
Syv Ritch wrote:
Lamar Owen wrote:
Same symptoms you have. I worked around it by disabling rhgb on the boot line (see /boot/grub/grub.conf and remove all rhgb kernel command line parameters). Probably something related to the kernel DRM/DRI stuff, although the problem persists regardless of kernel I boot (the .11 kernel had been working fine, but with the new Xorg it didn't).
Thanks but actually, I have already tried it by removing "rhgb quiet" from grub to see what happened and X still died. X dies after rhgb ends.
I don't think that this has anything to do with with the kernel. I downloaded Ubuntu 5.10 and tried to install and the same thing happened. They use 2.6.12... It must be either the radeon driver that is bad or X itself.
Other people have reported having similar problem with ATI on both Suse 10 and Ubuntu 5.10, so it must be something recent in X. _______________________________________________
<snip>
I was concerned because of the posts I saw. So I followed suggestions and upgraded w/o problems. ATI Radeon (AGP), AK-77/400 (Max/N) Mobo, AMD 180MHz (220PR).
(--) PCI:*(1:0:0) ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] rev 0, Mem @ 0xd8000000/27, 0xe1000000/16, I/O @ 0xc000/8
I Did yum update of up2date, yum update of yum. Rebooted. Updated kernel. Installed all updates *except* everything start with "X" (actually, anything I could ID as coming from X-org and a few extras just to be sure), reboot, removing the rhgb.
Install all the rest, reboot normally. Not one problem yet. I know the 64 bit machines seed to report the most (only?) problems.
There is a problem with xorg-6.8.2 and certain ATI cards. The problem is upstream though.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170008
This issue is more prevalent on 64-bit machines ... but it probably also happens on many RADEON cards and on all arches.
Pasi Pirhonen (our ia64, alpha, s390(x), sparc guy :) saw this problem early on, and has developed a fix that works ... but RH now has it for action.
In the meantime, if you remark out the load DRI line in /etc/X11/xorg.conf, it should fix this specific issue.
Syv Ritch wrote:
4.1 to 4.2 has been a total disaster.
I ran yum update, it went through and a couple of hours later I rebooted and X froze with the screen just being just fuzz [regular rectangles, orange, green...] and the keyboard froze. Could not do a alt-ctrl-backspace, nor a Alt-F1-6 nor Alt-Ctrl-Del.
I have a ATI9200 with a Samsung 710N [It only works at 1240x1024 @ 60Hz, it will not work at any other frequency]
This is the same hardware as I was running with 4.1.
I had to reinstall 4.1, now I cannot run yum update to get the security updates, it tries to upgrade to 4.2.
- Is there a way to just get the updates for 4.1 and not 4.2
- Any suggestion on what went wrong with X. It's not just the frequency
display because the keyboard also froze.
I have finally solved the problem.
The problem IS [present tense] X. X dies with the ATI card. I have tried changing the driver to ATI's, and still no dice. I ended cannibalizing an older PC and changing the video card to an nVidia GeForce2. Everything works well.
Something's wrong on how X talks or does not talk to the ATI9200. It's not the driver because it happens with both dri and fglrx, so ...
On Mon, 31 Oct 2005, Syv Ritch wrote:
I have finally solved the problem.
The problem IS [present tense] X. X dies with the ATI card. I have tried changing the driver to ATI's, and still no dice. I ended cannibalizing an older PC and changing the video card to an nVidia GeForce2. Everything works well.
Something's wrong on how X talks or does not talk to the ATI9200. It's not the driver because it happens with both dri and fglrx, so ...
Same thing with the Radeon 7000 series...
On Mon, 2005-10-31 at 10:35 -0800, Paul Heinlein wrote:
On Mon, 31 Oct 2005, Syv Ritch wrote:
I have finally solved the problem.
The problem IS [present tense] X. X dies with the ATI card. I have tried changing the driver to ATI's, and still no dice. I ended cannibalizing an older PC and changing the video card to an nVidia GeForce2. Everything works well.
Something's wrong on how X talks or does not talk to the ATI9200. It's not the driver because it happens with both dri and fglrx, so ...
Same thing with the Radeon 7000 series...
Guys,
This is a known issue with a patch on the 6.8.2 version of xorg-x11. It is an upstream issue.
Pasi Pirhonen (one of our CentOS developers) found and reported the issue upstream.
In the meantime, I believe if you disable dri in your /etc/X11/xorg.conf file everything will work (except 3D).
On Tue, 1 Nov 2005, Johnny Hughes wrote:
On Mon, 2005-10-31 at 10:35 -0800, Paul Heinlein wrote:
On Mon, 31 Oct 2005, Syv Ritch wrote:
I have finally solved the problem.
The problem IS [present tense] X. X dies with the ATI card. I have tried changing the driver to ATI's, and still no dice. I ended cannibalizing an older PC and changing the video card to an nVidia GeForce2. Everything works well.
Something's wrong on how X talks or does not talk to the ATI9200. It's not the driver because it happens with both dri and fglrx, so ...
Same thing with the Radeon 7000 series...
Guys,
This is a known issue with a patch on the 6.8.2 version of xorg-x11. It is an upstream issue.
Pasi Pirhonen (one of our CentOS developers) found and reported the issue upstream.
In the meantime, I believe if you disable dri in your /etc/X11/xorg.conf file everything will work (except 3D).
Sadly, disabling dri didn't work for me. Taking a look at ticket #170008 at bugzilla.redhat.com suggests that others are experiencing the same trouble.
Just as sadly, I haven't yet taken the time to poke around the xorg sources to see if any patches have been commited that claim to fix the problem...
-- Paul Heinlein heinlein@madboa.com
-
Benjamin J. Weiss -
Collins Richey -
Jay Leafey -
Joe Landman -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Maciej Żenczykowski -
Paul Heinlein -
rado -
Robert -
Syv Ritch -
William L. Maltby -
William Warren