Bug#683499: Segmentation fault in gen7_update_renderbuffer_surface()
Hi, I have an Intel HD 4000 from the i7-3770 processor. I'm still having this segfault for any GL programs (e.g. glxgears). I'm on Debian testing, libgl1-mesa-dri 8.0.5-3 I think the stack trace is pretty much the same. Program received signal SIGSEGV, Segmentation fault. gen7_update_renderbuffer_surface (brw=0x77fd8040, rb=0x61a0c0, unit=0) at gen7_wm_surface_state.c:200 200 gen7_wm_surface_state.c: No such file or directory. (gdb) bt #0 gen7_update_renderbuffer_surface (brw=0x77fd8040, rb=0x61a0c0, unit=0) at gen7_wm_surface_state.c:200 #1 0x7fffee26b750 in brw_update_renderbuffer_surfaces (brw=0x77fd8040) at brw_wm_surface_state.c:1047 #2 0x7fffee255a90 in brw_upload_state (brw=brw@entry=0x77fd8040) at brw_state_upload.c:503 #3 0x7fffee243527 in brw_try_draw_prims (max_index=optimized out, min_index=optimized out, ib=0x0, nr_prims=2, prim=0x80e680, arrays=0x699a70, ctx=0x77fd8040) at brw_draw.c:482 #4 brw_draw_prims (ctx=0x77fd8040, arrays=0x699a70, prim=0x80e680, nr_prims=2, ib=0x0, index_bounds_valid=optimized out, min_index=0, max_index=161, tfb_vertcount=0x0) at brw_draw.c:566 #5 0x7fffee370c2c in vbo_save_playback_vertex_list (ctx=0x77fd8040, data=0x80dee8) at vbo/vbo_save_draw.c:298 #6 0x7fffee2c2542 in ext_opcode_execute (node=0x80dee0, ctx=0x77fd8040) at main/dlist.c:602 #7 execute_list (ctx=0x77fd8040, list=optimized out) at main/dlist.c:7505 #8 0x7fffee2c5f82 in _mesa_CallList (list=1) at main/dlist.c:8922 #9 0x004028a2 in ?? () #10 0x00401fd1 in ?? () #11 0x76b61ead in __libc_start_main (main=optimized out, argc=optimized out, ubp_av=optimized out, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffe478) at libc-start.c:228 #12 0x004025fd in ?? () #13 0x7fffe478 in ?? () #14 0x001c in ?? () #15 0x0001 in ?? () #16 0x7fffe76a in ?? () #17 0x in ?? () The line is: struct intel_region *region = irb-mt-region; But irb-mt is NULL. I have tried a few different versions of kernels (3.2, 3.4, 3.7) but the crash is exactly the same. Thanks. Pigeon. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130116211252.5b430...@gokuu.pigeond.net
Bug#624548: More info for #624548
Pretty sure it's the XFS bug, 1st bullet, 1st item on: http://blog.mraw.org/2011/04/03/DXN-8/ Thank you very much. I, for one, can confirm that is the problem I am having. And fixed by removing the xfs package as well as removing the xfs FontPath in my xorg.conf. Regards, Pigeon. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110718135618.78f91441@furiza
Bug#624548: More info for #624548
Hi all, I have the same problem for a quite while now. The first time was running urxvt as mentioned by others. I also found that clicking on a qt dropdown list (so that it pops up the list of items for you to choose) will cause a crash too. Tested with qtconfig-qt4 and skype. The backtrace from Xorg is pretty much the same as running urxvt: Backtrace: 0: Xorg (xorg_backtrace+0x26) [0x4a3836] 1: Xorg (0x40+0x65049) [0x465049] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fabbf523000+0xf020) [0x7fabbf532020] 3: Xorg (doListFontsWithInfo+0x10b) [0x43372b] 4: Xorg (ProcessWorkQueue+0x21) [0x436eb1] 5: Xorg (WaitForSomething+0x65) [0x45e745] 6: Xorg (0x40+0x32a92) [0x432a92] 7: Xorg (0x40+0x26fae) [0x426fae] 8: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7fabbe25cead] 9: Xorg (0x40+0x2729d) [0x42729d] I'm using nvidia with the proprietary driver btw. Pigeon. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715111758.61334...@saba.fluffyspider.com.au
Bug#478293: xterm: scrollback: disable scroll to bottom on new output while Shift key remains depressed?
Package: xterm Severity: wishlist xterm provides the facility to turn the scrollback feature scroll to bottom on new output on or off completely, but it would be very useful to have a third option, so that that feature is disabled while the Shift key is held down and re-enabled only when the Shift key is released. Say I am running tail -f /var/log/syslog in an xterm. I want scroll to bottom on new output enabled so that the tail works. I then go into scrollback using Shift-PageUp in order to read some portion of the log output which has scrolled off the top. I have read half of whatever it was when suddenly there is some new syslog output and the xterm jumps back to the bottom and I lose my place. Which is really annoying. At the moment the options available are 1) put up with it 2) explicitly disable scroll to bottom on new output every time I use scrollback and then re-enable it afterwards 3) Ctrl-C out of tail -f, use eg. less to examine the log file, then restart tail -f once I've finished It would be really useful if holding down the Shift key would disable scroll to bottom on new output for as long as the Shift key remains depressed, and then re-enable it when the Shift key is released. That way I could read the tailed log in scrollback without it randomly jumping out of sight, and when I'd finished reading it would revert to normal without any extra action required. -- Pigeon Be kind to pigeons Pigeon's Nest - http://pigeonsnest.co.uk/ Lucy Pinder Television - http://www.lucy-pinder.tv/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F signature.asc Description: Digital signature
Bug#454546: Cause of problem, possible patch
On Sat, Dec 08, 2007 at 01:11:10PM +0100, Brice Goglin wrote: Does both wheels work very fine with your patch? (apart from some unrecognized packet warnings in the Xorg log) ...update since my last message: I have since had several unrecognised packet events recorded in the log, but both wheels have continued to work fine throughout. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F signature.asc Description: Digital signature
Bug#454546: Cause of problem, possible patch
On Fri, Dec 14, 2007 at 11:36:45PM +0100, Brice Goglin wrote: I have forwarded your problem at the URL above. Feel free to add any comment if you think it could help. These which I have just googled are probably relevant: Probably related problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392864 Reasoning behind the introduction of the problem code: https://bugzilla.novell.com/show_bug.cgi?id=144682 Copied to above bugzilla along with link to this bug. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F signature.asc Description: Digital signature
Bug#454546: Cause of problem, possible patch
On Sat, Dec 08, 2007 at 01:11:10PM +0100, Brice Goglin wrote:
Pigeon wrote:
Looking at the source code for xserver-xorg-input-mouse it seems that this
behaviour is a gross overreaction to the reception of a spurious z-axis
packet from the mouse.
if (pMse-negativeW != MSE_NOAXISMAP) {
switch (pBuf[3] 0x0f) {
case 0x00: break;
case 0x01: dz = 1; break;
case 0x02: dw = 1; break;
case 0x0e: dw = -1; break;
case 0x0f: dz = -1; break;
default:
xf86Msg(X_INFO,
Mouse autoprobe: Disabling secondary
wheel\n);
pMse-negativeW = pMse-positiveW =
MSE_NOAXISMAP;
}
}
So, if it receives any z-axis data that it does not understand, it does not
simply ignore it, it immediately and for no reason nukes the secondary
wheel,
and moreover does this in such a way that it also destroys any wheel
remapping,
with the result that it also destroys my vertical wheel. This is very rude.
So I am currently testing the following patch, which simply reports and then
ignores the spurious packet, instead of making my mouse unusable.
I will report your problem upstream. Does both wheels work very fine
with your patch?
(apart from some unrecognized packet warnings in the Xorg log)
Because of the intermittent nature of the problem the warning has only
appeared once since I installed the patch, but it has indeed occurred,
and both wheels are still working fine. As far as I can tell there is
no problem.
--
Pigeon
Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F
signature.asc
Description: Digital signature
Bug#454546: Cause of problem, possible patch
Looking at the source code for xserver-xorg-input-mouse it seems that this
behaviour is a gross overreaction to the reception of a spurious z-axis
packet from the mouse.
if (pMse-negativeW != MSE_NOAXISMAP) {
switch (pBuf[3] 0x0f) {
case 0x00: break;
case 0x01: dz = 1; break;
case 0x02: dw = 1; break;
case 0x0e: dw = -1; break;
case 0x0f: dz = -1; break;
default:
xf86Msg(X_INFO,
Mouse autoprobe: Disabling secondary
wheel\n);
pMse-negativeW = pMse-positiveW =
MSE_NOAXISMAP;
}
}
So, if it receives any z-axis data that it does not understand, it does not
simply ignore it, it immediately and for no reason nukes the secondary wheel,
and moreover does this in such a way that it also destroys any wheel remapping,
with the result that it also destroys my vertical wheel. This is very rude.
So I am currently testing the following patch, which simply reports and then
ignores the spurious packet, instead of making my mouse unusable.
diff -u src/mouse.c.orig src/mouse.c
--- src/mouse.c.orig2007-12-06 14:57:38.0 +
+++ src/mouse.c 2007-12-06 14:27:08.0 +
@@ -1511,9 +1511,14 @@
case 0x0e: dw = -1; break;
case 0x0f: dz = -1; break;
default:
+#ifdef notdef
xf86Msg(X_INFO,
Mouse autoprobe: Disabling secondary wheel\n);
pMse-negativeW = pMse-positiveW = MSE_NOAXISMAP;
+#else
+ xf86Msg(X_INFO,
+ ExplorerPS/2 decode: unrecognised z-axis packet
received\n);
+#endif
}
}
if (pMse-negativeW == MSE_NOAXISMAP)
--
Pigeon
Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F
signature.asc
Description: Digital signature
Bug#454546: Mouse wheel mapping randomly fails with (II) Mouse autoprobe: Disabling secondary wheel
Package: xorg Version: 1:7.1.0-19 After the X server has been up for some random amount of time the scroll wheel mapping on my two-wheel mouse (Trust AmiTrack trackball configured using ExplorerPS2 protocol - same thing happens using IMPS2) goes to cock. The vertical wheel becomes a horizontal wheel and the horizontal wheel becomes a double-spacing horizontal wheel. This often, but not invariably, happens when scrolling a page in the browser that has not fully loaded and the browser is chugging while it loads and not responding immediately to scroll events. Sometimes it happens after X has been up only a few minutes. Sometimes it takes several days at the same level of activity before it happens. The only cure is to restart X - and with it all the applications - major PITA. Restarting gpm, or unplugging and replugging the mouse, does nothing. When it happens the following message appears in Xorg.0.log: (II) Mouse autoprobe: Disabling secondary wheel xorg.conf mouse section reads: Section InputDevice # Identifier and driver Identifier Mouse1 Driver mouse #Option ProtocolIMPS/2 Option ProtocolExplorerPS/2 #Option Protocolauto #Option Device /dev/psaux Option Device /dev/gpmdata Option Buttons7 Option ZAxisMapping 6 7 5 4 Option Emulate3Buttons off EndSection As you can see I have tried various protocol options, and have tried reading direct vs. reading via gpm -Rraw; with the latter I have tried the same protocol options in gpm. The behaviour is the same in all cases. I still get the autoprobe log message even when not using Protocol auto. Mouse uses PS/2 port, kernel is custom 2.6.10. -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F signature.asc Description: Digital signature
