Bug#566617: i915: Waking up sleeping processes ... reboot required
On Sat, Feb 27, 2010 at 08:10:36AM +0100, Cyril Brulebois wrote: Hi, Juha Mäkinen juha.maki...@koti.soon.fi (24/01/2010): Package: xorg-video-intel Version: xserver-xorg-video-intel Severity: normal (please make sure to fill this information properly next time, there's a script collecting extra data for you so we don't have to ask) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Old kernel, see below. My X session did a lockup, must reboot to unlock X. Jan 24 08:20:27 mirembe kernel: [ 77.024037] i915: Waking up sleeping processes Jan 24 08:20:27 mirembe kernel: [ 77.025029] reboot required Many regressions got fixed in i915 since 2.6.32-trunk, so please check what happens with latest 2.6.32 kernel from sid. If you still encounter this issue, please check with 2.6.33 kernel from experimental. I had the same problem previously with 2.6.32-trunk; yesterday, I had it also occur with 2.6.32-3. I haven't tried with the experimental 2.6.33. The hard part of diagnosing is its randomness; my system was up for 9 days before it occurred, for what it's worth. I found that /var/log/kern.log gave a little more information than /var/log/messages. Here's a log snippet from the time of my crash: Apr 1 14:58:07 athens kernel: [768399.828014] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Apr 1 14:58:07 athens kernel: [768399.828024] render error detected, EIR: 0x Apr 1 14:58:07 athens kernel: [768399.828028] i915: Waking up sleeping processes Apr 1 14:58:07 athens kernel: [768399.828043] [drm:i915_do_wait_request] *ERROR* i915_do_wait_reque st returns -5 (awaiting 104345010 at 104345009) Apr 1 14:58:07 athens kernel: [768399.828451] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged Apr 1 14:58:07 athens kernel: [768399.828614] reboot required Apr 1 14:58:07 athens kernel: [768400.222390] [drm] DAC-5: set mode 1440x900 1d Apr 1 14:58:12 athens kernel: [768404.448220] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged Apr 1 14:58:12 athens kernel: [768404.584494] [drm] DAC-5: set mode 1440x900 1d After ssh'ing in from another system, I noticed that xdm had crashed. I tried restarting it, but was unsuccessful. The last lines of my /var/log/Xorg.conf.0 were: (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_make_current_read (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects (II) AIGLX: Loaded and initialized /usr/lib/dri/i915_dri.so (II) GLX: Initialized DRI2 GL provider for screen 0 (II) intel(0): Setting screen physical size to 380 x 238 Fatal server error: Failed to submit batchbuffer: Input/output error Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at /var/log/Xorg.0.log for additional information. (II) AIGLX: Suspending AIGLX clients for VT switch Hope that helps some, Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552085: vim-scripts: gnupg plugin fails if /bin/sh is a link to dash instead of bash
On Sat, Jan 23, 2010 at 06:02:05PM -0500, James Vega wrote: Are you still seeing this? I had been, but when I sat down to give it a good look this weekend, everything was working fine. If you are still seeing it, can you try running ???vim -u NORC -N??? to eliminate any interactions from your vimrc? I was still seeing this until a week ago. I noticed there hadn't been any activity on the bug since I last commented, so I contacted the author of the script directly. He wasn't aware of the Debian bug, and couldn't reproduce it on his end, so we worked together to fix it. There was a bug in his script that wasn't processing properly if the default shell was csh or tcsh. He has a new version that works for me regardless of where /bin/sh points to; he said he wanted to do more testing before publishing it, and after he was done he'd upload it to the project page at vim.org. I'll reply back here with the version number once I notice it's uploaded so it can be included in future versions. (This is the message I tried to send 12 hours ago; for some reason, it didn't seem to go through, and now I see you've sent him a patch already; oh well, I tried But, your patch was the same fix he'd come up with.) Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552085: vim-scripts: gnupg plugin fails if /bin/sh is a link to dash instead of bash
I experienced the same error with this plugin. For over a month now I couldn't figure out why the plugin worked flawlessly on one system but failed on another. The errors I got were the same, and went away as soon as I switched /bin/sh to point at /bin/bash instead of /bin/dash. Error detected while processing function SNR4_GPGInit: line 89: Error detected while processing function SNR4_GPGDecrypt: line 15: E484: Can't open file /tmp/v224282/1 File is not encrypted, all GPG functions disabled! Press ENTER or type command to continue Version numbers: vim-scripts: 20091011 dash: 0.5.5.1-3 Thanks, Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#458964: rss2email: XML feeds are mis-parsed
On Thu, Jan 03, 2008 at 10:48:27PM +0100, Hilko Bengen wrote: I have subscribed to http://thecommandline.net/feed and all messages generated from that feed get the title Creative Commons License. Apparently, so it turns out, instead of the item's title, the title for a media object embedded at the end of that item is used: This looks like a problem with a package rss2email depends on, python-feedparser. See the bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490613. It was fixed just recently, and version 4.1-11 is currently in unstable. I was having the same problem with both a wordpress.com RSS feed as well as a sample one I made up like your example. After emailing the upstream author, I installed the new python-feedparser described in the above bug report, and my emails had the right subject lines again. I also just added the example you gave at commandline.net to rss2email, and it also emailled me the right subject lines for the RSS entries. Hope that helps, Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
