Bugzilla – Bug 73092
machine hard lockup when starting X
Last modified: 2007-06-22 15:20:40 UTC
The machine works fine, in runlevel 3. Say X and the machine locks up hard immediately. I logged the complete startup and crash via serial console. The crash isn't really readable, maybe the memory gets corrupted too fast. I will also attach complete hwinfo output
Created attachment 31874 [details] lspci
Created attachment 31875 [details] hwinfo
Created attachment 31876 [details] serial console log of startup and crash
can you try with pci=nommconf as kernel parameter?
Does not help.
I added Option "XaaNoScreenToScreenCopy" to xorg.conf (cf. bug 66744), and system does not crash, but screen goes blank and nothing happens - X does not work with that option either.
Ok. Try "noaccel" instead, although I don't think that this will help ...
"noaccel" gives the same as "XaaNoScreenToScreenCopy". Output switches from Digital to Analogue and the monitor behaves like frequency is out of sync range. Here is the Modes section; Section "Modes" Identifier "Modes[0]" Modeline "1600x1200" 140.00 1600 1632 2024 2052 1200 1200 1208 1216 Modeline "1600x1200" 173.38 1600 1712 1888 2176 1200 1201 1204 1245 Modeline "1280x1024" 134.72 1280 1368 1504 1728 1024 1025 1028 1068 Modeline "1024x768" 79.52 1024 1080 1192 1360 768 769 772 801 Modeline "800x600" 47.53 800 840 920 1040 600 601 604 626 Modeline "640x480" 29.84 640 664 728 816 480 481 484 501 EndSection The same section works with a ATI Radeon 9000 AGP card in another AMD64 machine.
Created attachment 32475 [details] Xorg.0.log Is this the reason for the problem? (WW) RADEON(0): Failed to set up write-combining range (0xd0000000,0x8000000)
Unlikely.
This needs to be passed to ATi. Without a card I will be unable to reproduce this. This is PCIe.
This might be a x86_64 specific problem. We don't have this problem with our PCIe X600 boards on i915 (IA32).
Stefan F., I can give you my PCIe X600 board for testing on your AMD64 nForce4 SLI board. Just let me know.
Thanks, Stefan D. The X600 works on an ASUS A8N SLI board.
Stefan F./Philipp, could you please attach the X.Org logfile, so we have this issue at least somewhat documented? Thanks.
Here's the log.
Hmm ... where is it?
Attached to this bug?
Something went wrong, so I'm trying again ...
Created attachment 32919 [details] xorg start-up of Radeon X600 PCIe on Asus nforce4 board.
The first difference one can see is that the reporter uses a SMP kernel whereas we use a UP kernel. Philipp, could you please try again with a the SMP kernel? I'll give you another X600 board with exactly the same device ID, before you can do this.
The problem is not reproducable with the SMP kernel and the new X600 board. BTW, I mixed up the device IDs of the chips. The new X600 has the same device ID as the one we tested before (3E50). :-( Probably we need to test this on a EM64T machine (SMP) with PCIe (16x) slots. If we find one ...
> Probably we need to test this on a EM64T machine (SMP) with PCIe (16x) > slots. If we find one ... This matches the HP xw8200 I have here for testing and I cannot reproduce this problem on this machine as well ==> WORKSFORME.
still the same problem in 10.0 RC1. machine locks up, when using radeon driver suggested by yast. I installed fglrx 8.16.20, and it works without 3D, because the kernel module does not compile. Any chance to get this investigated again?
The card also does not work in a Intel D915PBL Mainboard with radeon. Whereas a X300SE works in the D915PBL.
The current CVS driver from bug #115283 has several issues fixed. You can download it in compressed form from: https://bugzilla.novell.com/attachment.cgi?id=49796 Please test this driver (replace the one in /usr/X11R6/lib/modules/drivers/ after backing it up).
Can I have a 64 Bit version, please. vetter@beder:~> file radeon_drv.o radeon_drv.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
Created attachment 50017 [details] 64bit version of CVS radeon driver Err.... yes, of course. Here it is.
Of course you will have to replace the driver in /usr/X11R6/lib64/modules/drivers/ (not /usr/X11R6/lib/).
Sorry, the machine has some problems with memory and/or CPU, which are currently investigated by the dealer. Maybe this fixes the lockup. The behaviour was in 10.0beta and rc1 better, because it does not lockup immediately, but first shows a black screen with the blinking cursor. So it might be the same problem as in bug 115283
For the moment I close this as INVALID (due to broken RAM or CPU). If that can be ruled out, feel free to reopen the bug. The black screen with the blinking cursor is actually just the virtual terminal #7 to which the Xserver switches before initializing the graphics mode.