From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 Description of problem: Dell 650n with 2x2.6Mhz. P4s (hyperthreading on/off doesn't matter) Booting with non-SMP kernel work just fine. Chaninging to SMP kernel system boots fine to graphical login. Login as root (or anyone else) and the preparations for the new session start normally until Red Hat Update Icon becomes highlighted. Screen, mouse, freeze. Power-off is only possible by holding power button for several seconds. Version-Release number of selected component (if applicable): kernel-2.6.9-1.667 (base FC3 release kernel) How reproducible: Always Steps to Reproduce: Install FC3 release with all packages on P4 SMP system. Login at root (or anyone else). Actual Results: See above. Expected Results: Normal login like uni-processor version of same kernel. Additional info: Can provide other information if guidance is provided.
I have a similar problem. This is on a dual PIII-800 (6-8-6) which was upgraded from FC2. Booting any smp kernel (the stock fc3 2.6.9 or a hand configured 2.6.9) makes the machine lock while doing graphical activity. As the lockup is total I have little info gathered on the system state. The problem is both in the Gnome and in the KDE environment. If I don't login graphicaly and work in a text console only the machine keeps running till doomsday even though the X server is started. If I boot a Uniprocessor kernel the problem also disappears.
I confirm similar behaviour - SMP kernel (2.6.9-1.667) - dual P4 scsi only system. Did update install from FC2 - then yum install of all base packages not installed - then yum update. Gnome _always_ dies at the "redhat network monitor" phase on the screen - but this may be coincidental. KDE let me login and but it crashed hard 5 minutes later. Even Alt-sysrq had no effect - there was heaevy fan or disk activity while machine was hung - it was also unpingable from the network.
As suggested in bug#138779, this problem can be fixed by backing out to the x.org 6.7.0-9 packages from FC2. This suggests that it is not a kernel, but rather an x.org problem, where xorg-x11-6.8.1-12 is not SMP safe. Im running with the stock FC3 SMP kernel and the FC2 xorg-x11 stuff -> no problems anymore
The problem does not seem to occur on a single P4 with hyperthreading. I've been working a full morning on a P4HT machine with FC3 upgraded from FC2. A P4HT is not a full SMP machine of course. The booted kernel is a stock FC3 SMP kernel. Config: Dell Inspiron 5150, NVidia Gforce Go5200/64MB, 1MB memory, P4HT 3,06 GHz.
This is likely to be a problem with a specific video chipset/driver, because SMP has been heavily tested with no problems on a wide variety of hardware. If you are seeing this trouble, please provide details about your video card. lspci -n and lspci -vvv OF THAT DEVICE ONLY may help.
I believe my video card on the system is an ATI 7000. I was going to replace it with an NVidia card so perhaps I'll just go ahead and do that.
You mean ATI Radeon 7000? Try this... 1) Edit /etc/X11/xorg.conf 2) Comment out the line that reads Load "dri" Any better?
I also have ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE lspci -n 00:00.0 Class 0600: 8086:2531 (rev 04) 00:01.0 Class 0604: 8086:2532 (rev 04) 00:02.0 Class 0604: 8086:2533 (rev 04) 00:1e.0 Class 0604: 8086:244e (rev 04) 00:1f.0 Class 0601: 8086:2440 (rev 04) 00:1f.1 Class 0101: 8086:244b (rev 04) 00:1f.2 Class 0c03: 8086:2442 (rev 04) 00:1f.3 Class 0c05: 8086:2443 (rev 04) 00:1f.4 Class 0c03: 8086:2444 (rev 04) 01:00.0 Class 0300: 1002:5159 02:1f.0 Class 0604: 8086:1360 (rev 03) 03:00.0 Class 0800: 8086:1161 (rev 01) 03:0c.0 Class 0100: 9005:0080 (rev 02) 03:0e.0 Class 0100: 9005:008f (rev 02) 04:0b.0 Class 0200: 10b7:9200 (rev 78) 04:0c.0 Class 0c00: 104c:8020 04:0e.0 Class 0401: 1102:0002 (rev 08) 04:0e.1 Class 0980: 1102:7002 (rev 08) lspic -vv 1:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 1b8a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (2000ns min), Cache Line Size 10 Interrupt: pin A routed to IRQ 9 Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at ec00 [size=256] Region 2: Memory at ff8f0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at c1000000 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4 Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Those with Radeon 7000, please try after disabling DRI as described in Comment #7. Does this workaround this issue?
Sorry, Yes I meant ATI Radeon 7000. I removed the load "dri" and the SMP version worked as well as the UP version. I'm glad others are being helped by this report. So I assume the xfree86 guys are working this issue and we can expect a FC3 update at some point? Thanks, Dan
No, xfree86 is an irrelevant and dead project. This sounds to be a SMP kernel issue, not the X server's fault.
Same issue? bug #138108
Removing dri - and reebooting 2.6.9-1.667smp seems stable so far. As an aside - what do folks use for 3-d capability in FC3 - nothing fancy but something that works - preferable with stock FC3 - or do people bite the binary driver bullet - and if which - nvidia? Will let this run until and if it chooses not to behave! gene/
One more comment: I get loads of color bleed on fonts (didnt have this prob under fc2) - no matter how I set the anti aliasing options - could this be related or a separate issue? g/
For what it's worth, the system that gives me trouble also has a radeon 7000 (well actually a radeon VE, but that's the same chip, it was renamed for commercial reasons later). If you want me to test turning off dri, let me know. For that matter, if you need any kind of testing done, let me know. I still don't think it's a kernel issue though. I run with xorg 6.7.0-9 from FC2, with the 2.6.9-1.667 SMP kernel and that works fine, with DRI enabled. This could be in the DRI part of the x.org Radeon 7000 driver.
I am the one who reported bug#138779, which is an xorg-x11 bugreport. As I explain in that report, reverting back to FC2's xorg (while keeping the new FC3 SMP kernel, and having 'load "dri"' in the xconf file) solves the problem. Being a non-expert, could you explain to me then how can the problem be still a kernel or ATI chipset bug? Does the new FC3 xorg update solve the problem? Thx
I can confirm that commenting out load "dri" in xorg.conf is a fine workaround; my system seems stable after 48 hours of quite heave usage.
According to what I read in other sources, there are other distros with the same problem. Namely mandrake users have experienced this problem since the switch to x.org 6.8.0 and have had no improvement from 6.8.1.
Has anyone tried to attach a serial console and capture a kernel panic when it locks up? Capturing that kind of debug information would go a long way toward solving this problem.
This is most likely a dupe of bug #138108, for which I believe we now have a fix. xorg-x11-6.8.1-17 or later in rawhide should make the crashes go away, and we'll be putting out an update shortly for FC3. Please test either the udpate or the rawhide packages so we can confirm that this is indeed the same issue. Thanks. *** This bug has been marked as a duplicate of 138108 ***
Bugzilla does not let me access (look at) bug #138108.
Similar problem using radeon driver on Centrino Thinkpad; disabling dri fixes it. I get lockups mostly when GLX apps are running or if Xorg is restart. Appropriate device string from lspci: ATI Technologies Inc Radeon Mobility M6 LY
Created attachment 107511 [details] X server log from the crashed session This is the X server log from the crash after installing xorg-x11-6.8.1-19.
I have tested xorg-x11-6.8.1-19 from development. 6.8.1-17 was no longer available, but I assume anything fixed in -17 will still be fixed in -19. The behavior has changed somewhat: Boot->Login->GlxGears->Xserver crash->Login->spontaneous reboot. Althought it's different it's hardly an improvement. Backing out to 6.7.0-10 from FC2 produces a rock solid system again. System: Dual PIII-800 with Radeon 7000 Although I normally run a slightly modified kernel (PIII optimized and 4G/4G VM layout removed), booting the stock kernel (2.6.9-1.681_FC3smp) also gives this result. Unfortunately the X server left no extra goodies in the log when it crashed. The X server log is attached. Disabling dri also makes the problem go away, but is no option for me as I need hardware assisted 3D.
After (admitedly brief but adequate) testing - I confirm that after installing xorg-x11 6.8.1-12.FC3.21 my system no longer crashes with dri turned back on using SMP kernel-2.6.9-1.681_FC3. Thank you. g/
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.