X crash when running video with the i810-2.2.1_pre20080123 Log: X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: UNKNOWN- Current Operating System: Linux tetsuo 2.6.23-hardened-r4-mactel #1 SMP PREEMPT Sun Jan 20 21:32:41 CET 2008 i686 Build Date: 17 November 2007 >---Before reporting problems, check http://wiki.x.org >---to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, >---(++) from command line, (!!) notice, (II) informational, >---(WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 24 23:59:32 2008 (==) Using config file: "/etc/X11/xorg.conf" (WW) intel: No matching Device section for instance (BusID PCI:0:2:1) found (II) Module already built-in (II) Module already built-in (II) Module already built-in (EE) AIGLX error: drmMap of framebuffer failed (Invalid argument)(EE) AIGLX: reverting to software rendering The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server Synaptics DeviceInit called SynapticsCtrl called. Synaptics DeviceOn called dwm: missing fontset: GB2312.1980-0 dwm: missing fontset: KSC5601.1987-0 Fatal server error: Bad channel value 285893360 XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"^M after 6545 requests (6545 known processed) with 0 events remaining.^M xinit: connection to X server lost.^M
Please attach the full log and xorg.conf. Does this ever work for you on the previous version?
Created attachment 13953 [details] Xorg log
Created attachment 13954 [details] xorg.conf
(In reply to comment #1) > Please attach the full log and xorg.conf. > > Does this ever work for you on the previous version? > Yes it was working with the version 1.7.4
jbarnes guess one of the fragment shader program is bogus as the bad channel message comes from i915_get_hardware_channel_val from i915_3d.h.
Does this happen everytime? Could you get more details on how to reproduce this?
(In reply to comment #6) > Does this happen everytime? Could you get more details on how to reproduce > this? > It crashes everytime when I run any video (mplayer, xine, etc...). And it happens with all i810-2* that have tested.
it's strange, we always assign channel to fixed value, and driver never trys to abuse channel value. And exa accel works fine, right? How about try to comment following negate value check? diff --git a/src/i915_3d.h b/src/i915_3d.h index 1090218..62a8eac 100644 --- a/src/i915_3d.h +++ b/src/i915_3d.h @@ -177,8 +177,8 @@ i915_fs_operand_one(void) static inline int i915_get_hardware_channel_val(int channel_val) { - if (channel_val < 0) - channel_val = -channel_val; +// if (channel_val < 0) +// channel_val = -channel_val; switch (channel_val) { case X_CHANNEL_VAL: ~
btw, do you have any other patches outside of upstream tree?
It doesn't change any thing and I have no patch. But I find a solution. The problem appears when I compile the driver with an hardened gcc. When I compile with i686-pc-linux-gnu-3.4.6-hardenednopiessp, it works well.
yeah, compiler issue was also my thought, so thanks for try it. then i'd like to figure out what might go wrong with our shader implement in i915_3d.h, macros...or a gcc issue? Eric, any sharp idea?
Zhenyu, those two lines you commented out are for an unused feature of the macros -- you can do i915_fs_operand(FS_R0, X, -Y, -X, W) for example to negate two components. We don't use it today, but I can imagine using it when we do gradients for example. If the issue is caused by special gcc, I'd be inclined to close it unless there's evidence of an actual bug in our code being exposed.
right, I don't meant we should delete negate channel, just want to see if it changes anything though... Cédric, I'll close the bug now, as it looks a compiler issue than our driver's bug.
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.