| Summary: | [i945] X crashes in fbBlt() when using Sun Java Plugin 6 + firefox3.0 on Asus EEEPC 1000 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Bryce Harrington <bryce> | ||||||
| Component: | Driver/intel | Assignee: | Jesse Barnes <jbarnes> | ||||||
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | critical | ||||||||
| Priority: | high | CC: | yan.i.li | ||||||
| Version: | 7.3 (2007.09) | Keywords: | NEEDINFO | ||||||
| Hardware: | x86 (IA32) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Bryce Harrington
2009-03-18 16:05:53 UTC
I can't reproduce this with xf86-video-intel git from today and a fairly recent 2.6.29 version of drm-intel, I'll try 2.6.1 next. This could have been fixed by one of the many fence reg related fixes that went in post 2.6.1. Can't reproduce on 2.6.29 w/2.6.1 either, must have been a GEM fix between Jaunty's 2.6.28 and the current code... Several fencing related fixes from Chris Wilson went in after 2.6.28 came out, it would be worth trying those. But there have been a ton of changes (mostly fixes), and unless Jaunty's 2.6.28 includes GTT mapping support, the fencing fixes aren't likely to help. Bryce, can you get Manoj to try with a newer 2D driver and/or newer kernel? I'll try grabbing Jaunty's kernel in the meantime. Ok I finally got the Jaunty bits and saw the crash with 2.6.28-11-generic and the 2.6.1 driver, but with the latest Jaunty 2.6.3 driver things seem stable. Can you confirm that? Created attachment 24678 [details] [review] Manage pixmaps in the driver w/EXA Here's a crazy patch to fix this bug. The real bug is in the server somewhere (EXA pixmap migration appears to be broken, judging by the corruption shown in the text case vs. UXA and EXA with this patch). But rather than deal with the server's EXA migration code (scary) why not just make our driver do pixmap management itself? It should avoid migration altogether but may affect performance or have other bugs... Please test. Manoj, I built a package with this patch and stuck it in my ppa, if you want to use a deb for this. (I had to modify the patch slightly to apply to Ubuntu). (In reply to comment #4) > Here's a crazy patch to fix this bug. The real bug is in the server somewhere > (EXA pixmap migration appears to be broken, judging by the corruption shown in > the text case vs. UXA and EXA with this patch). But rather than deal with the > server's EXA migration code (scary) why not just make our driver do pixmap > management itself? The reported crash is not likely to be directly related to EXA migration, as that doesn't have any impact on the size of memory mappings. So while I very much like this patch (I wish this approach had been taken in the first place rather than the whole UXA silliness...), I'm afraid it can only solve the problem indirectly. (Not to mention it won't help people without a kernel memory manager) Yeah, I think the corruption I saw is due to migration code (or more specifically the dirty update stuff), but the crash must be due to either an unmap happing at the wrong time or the mapping size changing like you say. If you have a driver that doesn't manage pixmaps it's pretty easy to see the corruption with the default migration scheme (always I think?) at the Java test page referenced in this bug. I'd like to solve the problem properly as well, but I'll have to dig through the EXA code a lot more (I haven't looked at the migration or sys vs offscreen mapping code much at all). (In reply to comment #7) > Yeah, I think the corruption I saw is due to migration code (or more > specifically the dirty update stuff), but the crash must be due to either an > unmap happing at the wrong time or the mapping size changing like you say. If > you have a driver that doesn't manage pixmaps it's pretty easy to see the > corruption with the default migration scheme (always I think?) at the Java test > page referenced in this bug. Does Option "EXAOptimizeMigration" "off" work around the corruption? Also I'm having a hard time reproducing reports of problems with that option enabled with xserver master, can you reproduce it with that? > I'd like to solve the problem properly as well, but I'll have to dig through > the EXA code a lot more (I haven't looked at the migration or sys vs offscreen > mapping code much at all). It's not clear to me at this point it's an EXA bug at all... some values in the backtrace look way off, but the trace may just be inaccurate, or even if not the question is which layer would be responsible for sanitizing them. Haven't heard from the reporter in awhile, but:
- there's a patch available that "fixes" this for me, distros can pick it up if
desired
- EXA is no longer in the driver and UXA doesn't have this bug afaict
so I'm going to mark this invalid.
|
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.