Created attachment 32797 [details] dmesg with dri off and booting to X If option dri is set to off and I'm booting to X then I get the oops. When it is set to on (or I boot only to console) I do not get the oops. Still the acceleration is not working when dri is set to on. It complains about dri version mismatch which is strange since I compiled libdrm with --enable-radeon-experimental-api and I recompiled xf86-video-ati and mesa only after the new libdrm was installed. But this is probably a separate issue. Anyway looks to me it should not be possible to make kernel oops so here is the report. Ach, and it is an agp system but I never had any stability problems with it on windows (also worked very well with 2.6.30 and agd5f's r6xx-r7xx-3d drm module with agp 8x and even the fast writes). I'll attach dmesg with the oops and also without it (a boot to console).
Created attachment 32798 [details] dmesg when I booted to console only
Please attach your xorg log and config.
I cannot simulate the bug as it was when I reported the error. I'll attach the exact xorg.conf I used, but I do not have Xorg.0.log any more. But I looked at it when the errors happened and there were not any errors or warnings which are not in the Xorg.0.log I'll attach. But the log I'll attach is when I booted 2.6.32. I thought the error is repeatable since I tried 2 times and it happened 2 times. But I do not think so any more. It is not a problem to crash it again, but this time the machine is completely locked up, not even ssh works. Computer does not seem to react to keyboard too (keyboard leds do work though). When I set radeon.agpmode=-1 on the kernel command line I'm not able to make the kernel crash. I tried 6 times. Without setting agpmode to -1 it crashes with probability of about 0.5 when DRI is off. When DRI is on it typically does not crash. So it looks like it is related to AGP. I did not have any AGP related problems in linux before nor I have them in windows now.
Created attachment 32812 [details] xorg.conf when the error happend
Created attachment 32813 [details] Xorg.log (not when the eroror happend, everything the same except kernel) Notice that when the error happened as I described it the first time the machine did boot to X at the end and was usable (without dri with sw renderer). Not sure whether X server was restarted though. My guess would be that not but I did not check it.
(In reply to comment #3) > When I set radeon.agpmode=-1 on the kernel command line I'm not able to make > the kernel crash. I tried 6 times. Without setting agpmode to -1 it crashes > with probability of about 0.5 when DRI is off. When DRI is on it typically does > not crash. radeon.agpmode only has an effect if KMS is enabled, in which case an X driver with KMS support can't really work without the DRI; not sure what happens if you try. But from > It complains about dri version mismatch which is strange since I compiled > libdrm with --enable-radeon-experimental-api [...] it sounds like your X driver doesn't have KMS support built in, in which case it's not expected to work properly at all if KMS is enabled. In summary, unless your X log contains a line like (II) [KMS] Kernel modesetting enabled. without Option "DRI" "off", this report is probably invalid.
(In reply to comment #6) > In summary, unless your X log contains a line like > > (II) [KMS] Kernel modesetting enabled. > > without Option "DRI" "off", this report is probably invalid. Ok, so this report is invalid since when I run without radeon.agpmode=-1 and when Option DRI is on then I do not have line (II) [KMS] Kernel modesetting enabled. in my Xorg.log.
I had incorrectly (with --disable-kms) compiled xf86-video-ati. I recompiled everything (libdrm, mesa, xf86-xf86-video-ati) today from git master and it seems to work ... well until I try to put "video=1280x1024" on kernel command line. Then I get another hard kernel crash and lockup. But that is probably something completely different. Should I create a bug report for it? Btw it looks like Bug 18397 (Small pixmap corruption [EXA enabled]) is not there any more with kernel mode setting enabled.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.