Summary: | xorg-server-1.5.3-r5 + xf86-video-intel-2.6.3 crashes under gentoo-sources-2.6.29 (amd64) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrew Church <achurch+gentoo> |
Component: | [OLD] Unspecified | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | asolokha, kernel, scott |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.freedesktop.org/show_bug.cgi?id=21596 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 260582 | ||
Bug Blocks: | |||
Attachments: |
Xorg.0.log
Crash log from xf86-video-intel-2.7.0 Log from xorg-server-1.6.1 with xf86-video-intel-2.7.0 |
Description
Andrew Church
2009-03-30 07:29:53 UTC
Created attachment 186719 [details]
Xorg.0.log
Please advise if any other information would be useful.
I did have the same problem. I tried xorg-1.6 from x11 overlay and works fine so far This is the same as Bug 261783 Marking as a blocker on the Xserver 1.6 tracker. Thanks Unfortunately, I'm still not having any luck with xorg-1.6. Here's a table of how things look with the latest versions from the x11 overlay: 2.6.28-r5 1.5.3-r5 2.6.3-r1 | OK 2.6.28-r5 1.5.3-r5 2.7.0 | OK 2.6.28-r5 1.6.1 2.6.3-r1 | OK 2.6.28-r5 1.6.1 2.7.0 | OK 2.6.29-r3 1.5.3-r5 2.6.3-r1 | Crash (*1) 2.6.29-r3 1.5.3-r5 2.7.0 | Crash (*2), (*4) 2.6.29-r3 1.6.1 2.6.3-r1 | Freeze (*3) 2.6.29-r3 1.6.1 2.7.0 | Freeze (*3), (*4) (*1) This combination crashed as described in the original report. (*2) This combination succeeded in starting up to the point of allowing mouse pointer movement into and out of the single terminal started in my .xinitrc, but attempting to either open a second window or exit X via the window manager caused a crash. (*3) These combinations froze when exiting X via the window manager. There was nothing abnormal in Xorg.0.log; the system just failed to return to the original virtual console (and wouldn't accept any keyboard input, including Alt-Fn or SysRq magic keys). (*4) For these combinations, the displayed graphics were corrupt, with lines scattered horizontally across the screen as though the framebuffer line stride was set incorrectly. The graphic data itself appeared to be correct, judging from window frame color changes that occurred when I moved the mouse pointer to where the window was supposed to be (as a side note, the mouse pointer itself was displayed correctly). Created attachment 190498 [details]
Crash log from xf86-video-intel-2.7.0
This is for the crash-on-exit case (note 2 in my last comment), just in case it's desired. The crash itself seems to be in the same place, judging from the backtrace.
Also, sorry for forgetting to add headers to the table columns; in case it's not clear, the version numbers are for gentoo-sources, xorg-server, and xf86-video-intel respectively.
(In reply to comment #6) > Also, sorry for forgetting to add headers to the table columns; in case it's > not clear Wow, no, it's perfectly clear! Thanks a bunch for running such extensive tests :) Reading your log file, I see you've built xorg-server before we started enabling DRI2 in it. Could you try rebuilding xorg-server again, making sure that the "dri2" module is loaded and the intel driver try to use DRI2 instead of DRI1? Thanks Created attachment 190502 [details]
Log from xorg-server-1.6.1 with xf86-video-intel-2.7.0
As far as I can tell, the xorg-server-1.6.1 builds were already using DRI2, judging from the line:
(II) intel(0): direct rendering: DRI2 Enabled
in the logfile. I rebuilt 1.5.3-r5 and added an explicit "LoadModule dri2" to xorg.conf, and that resulted in an immediate crash using either intel-2.6.3-r1 or intel-2.7.0.
Actually, it looks like the LoadModule "dri2" didn't do anything at all for 1.5.3-r5; maybe that version didn't have DRI2 support to begin with? (And since there was no change, I guess the delayed crash I saw before was just the luck of the draw.) By "LoadModule dri2" I did of course mean: Section "Module" ... Load "dri2" EndSection Whatever DRI2 was available in 1.5.3 has been completely disabled because it wasn't ready when upstream made the 1.5 branch. But does anything new happen with DRI2 on X 1.6.1 ? Do you still get lock ups/crashes? Thanks Sorry if I wasn't clear -- the latest log (Xorg-161-...) is an instance of the freezes I mentioned earlier, which were already using DRI2. So no, there have been no changes. Ok, I get it. Please open a bug in FreeDesktop's bugzilla and add "remi@gentoo.org" as a CC on that bug so I can track it. There's little else I can do here as you're using the latest recommended bits by upstream. Here's a little document that should help you save time when filing the bug : http://intellinuxgraphics.org/how_to_report_bug.html Thanks Opened a bug on the freeze issue as: https://bugs.freedesktop.org/show_bug.cgi?id=21596 There's also a separate bug about the crash that links back here: https://bugs.freedesktop.org/show_bug.cgi?id=21245 As a side note, the graphics corruption issue I mentioned seems to be fixed by a patch mentioned in #21246 on freedesktop.org, namely: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=f544847fbaf099278343f875987a983f2b913134 Applied it to 2.6.29-r3 and it fixed the corruption, though not the freeze. Alright, that's great. Thanks a bunch for taking this upstream, let's track the bugs there. Don't hesitate to ping me here if the upstream bug is fixed and I forgot to backport whatever patches need to be backported. Thanks Hi, The above kernel patch does fix the graphics errors for me as well. On my system however, X will crash whenever i edit a line of text (in gedit) or when i try to execute a long command. But only the first time i run it after rebooting. Regards, Scott @kernel folks, Could you guys make sure that the patch linked in comment 14 is applied to the stable 2.6.29 branch or to the gentoo-sources patchset? Thanks for your help The patch from comment 14 was included in kernel 2.6.29.3, so gentoo-sources-2.6.29-r4 should have it. It turns out the "freeze" in comment 5 was kernel modesetting taking over the console from the VGA console driver and not restoring it afterwards. According to upstream, this is designed behavior and you have to use the framebuffer console driver with KMS, but there will (eventually, though I don't see it yet) be a kernel config patch to force-enable fbcon if KMS is selected. Either disabling KMS or enabling fbcon resolved the freeze for me. I haven't checked the status of the crash with xorg-server 1.5, but I noticed a changelog entry in the Intel driver talking about BO reference counts or some such, so that may be fixed in the current git version. Alright, thanks for the follow up. In any case, this bug will be fixed in the kernel directly where selecting KMS will automatically enable fbcon. Cheers And closing with the proper resolution. Thanks |