New symptom:
Positions within a kdenlive project's timeline
and a clip's effects and transitions weren't
synchronized.
Same solution:
$ mv ~/.config/kdenliverc tmp
worked again!
That's the good news.
The bad news?
The aptly named "debugger" (gdb) fixes
[mlt_pool] out of
Oops!
I forgot to mention that
[mlt_pool] out of memory
also appears on the console when kdenlive hangs.
Sorry,
Kingsley
--
Time is the fire in which we all burn.
For what it's worth, the workaround I described
above
$ rm .config/kdenliverc
basically seems to have fixed another bug.
Here's what happened:
$ export MESA_EXTENSION_OVERRIDE=-GL_ARB_draw_indirect ; kdenlive
kdenlive->File->Open recent->(a kdenlive project)
kdenlive->mute
I tried
$ rm .config/kdenliverc
and re-ran kdenlive.
It worked!
Humble suggestion:
Keep this bug open for a month or so, in case the
bug reappears.
Thanks,
Kingsley
--
Time is the fire in which we all burn.
Hi,
Julien Cristau very nicely explained that
libgl1-mesa-dri-dbgsym is available in the debug
archive.
So, I'm happy to report the following gdb trace
with symbolic offsets in nouveau:
Program received signal SIGSEGV, Segmentation fault.
0xa2c17e2e in list_del (item=0x48920048) at
../.
Package: libgl1-mesa-dri
Version: 11.2.2-1
Severity: normal
Dear Maintainer,
Sorry, I wish I didn't feel the need to mention
thia, but I seem to have stumbled upon a way to
elicit a SIGSEGV from
/usr/lib/i386-linux-gnu/dri/nouveau_dri.so
I was using a video editor named "kdenlive" to
previe
Hi Sven,
I'm happy to report that appending
nouveau.config=NvMSI=0
to grub2's boot line seems to have worked.
Thank you very much for saving me time,
Kingsley
On 11/08/15 23:34, Sven Joachim wrote:
> Control: reassign -1 libgl1-mesa-dri 11.0.4-1
>
> On 2015-11-08 22:3
Hi Sven,
Thanks for your thoughts.
On 11/08/15 22:14, Sven Joachim wrote:
> [...]
> It's currently not, but probably should be
> reassigned to it.
I agree.
> Could you please provide information about your
> graphics card and the version of libgl1-mesa-dri
> that's installed on your system?
S
Here's a stack trace with debugging symbols of
when kdenlive froze.
It seems to me to be the same bug that freezes
glxgears.
(gdb) bt
#0 0xb7fddbe0 in __kernel_vsyscall ()
#1 0xb4eb6e2b in poll () at ../sysdeps/unix/syscall-template.S:81
#2 0xb4abe86d in poll (__timeout=-1, __n
I just learned that someone had the foresight to
provide versions of the packages involved with
debugging symbols conveniently included.
So I
1.) installed
libgl1-mesa-dri-dbg
libx11-6-dbg
libxcb1-dbg
libgl1-mesa-dri-dbg
2.) run glxg
Hi Andreas,
2 days ago, you very politely and nicely asked if
bug #784641 was still an issue.
Yes, glxgears shows static gears for me too, and
the stack trace has
/usr/lib/i386-linux-gnu/dri/nouveau_dri.so
which is in libgl1-mesa-dri.
I filed the bug report at
https://bugs.debian.org/
It seems to me that bugs #784641 and #803528 are
similar.
1.) Both say glxgears has static gears.
2.) Both point at libgl1-mesa-dri
The stack traces above includes
/usr/lib/i386-linux-gnu/dri/nouveau_dri.so
which is in libgl1-mesa-dri.
#803528 is assigned
For what it's worth, someone with the nick name
"Sc0rpius" on OFTC's #debian-next channel said
glxgears works with the same versions of the
libgl1-mesa-dri:i386, libgl1-mesa-glx:i386,
libx11-6:i386 and libxcb1:i386 packages.
However, Sc0rpius was using x64 and an AMD card.
glxgears fails for me w
Here's a stack trace from when glxgears hangs
(gdb) bt
#0 0xb7fddbe0 in __kernel_vsyscall ()
#1 0xb7b81e03 in __poll_nocancel () at
../sysdeps/unix/syscall-template.S:81
#2 0xb784586d in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1
#3 0xb784766b in ?? () from /usr/lib/i3
On 05/30/15 09:58, Sven Joachim wrote:
> On 2015-05-30 08:56 +0200, Kingsley G. Morse Jr. wrote:
>
> > Package: xserver-xorg-video-nouveau
> > Version: 1:1.0.11-1+b1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Thanks for maintaining Debian
Package: xserver-xorg-video-nouveau
Version: 1:1.0.11-1+b1
Severity: normal
Dear Maintainer,
Thanks for maintaining Debian's nouveau driver.
It's great to have an open alternative.
The main reason I'm writing is that a recent
$ aptitude full-upgrade
and reboot, failed to run X.
xorg's lo
On 08/18/11 21:18, Cyril Brulebois wrote:
> Hi,
>
> Kingsley G. Morse Jr. (18/08/2011):
> > Package: xserver-xorg-video-nouveau
> > Version: 2.4.26-1
> > Severity: normal
>
> surely that's libdrm's version?
Oops!
Thanks.
I should have wri
Package: xserver-xorg-video-nouveau
Version: 2.4.26-1
Severity: normal
Thanks for trying to provide an open source driver
for nVidia graphics cards.
I tested nouveau with a G72 [GeForce 7300 SE/7200
GS] (rev a1).
I
installed the package,
changed /etc/X11/xorg.conf's driver to "no
Upgrading X broke my mouse.
It's a Logitech Marble.
It stopped:
a.) Pasting the X selection when I pressed
both of it's big buttons simultaneously.
No pasting is a big inconvenience.
b.) Emulating a scroll wheel.
Here's how I worked around the problem:
1.) I created a direct
On 01/17/07 10:01, Brice Goglin wrote:
[...]
> Did you reproduce this problem recently?
[...]
The good news is that I haven't.
The bad news is that we seem to have lost the
chance to debug it.
Thanks,
Kingsley
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Tro
X went away again, but this time I was able to
check /var/log/XFree86.0.log.old.
No stack trace from xserver-xfree86-dbg!
So I checked /var/log/messages and found:
Jun 6 13:38:44 debian1 kernel: <5>__alloc_pages: 0-order allocation
failed (gfp=0x1d2/0)
Jun 6 13:38:45 debian1 kernel:
When my X applications started popping, one by
one, I knew it wouldn't be long before
xserver-xfree86-dbg would breach too.
And soon enough, it died, it died.
Here's the big but.
But, on the way back up, X hung at the checkered
gray-scale screen.
It hung harder than (U.S.) Vice President Dick
C
The new version fails with
the "nvidia" driver too.
Hopefully we'll catch a SEGV if I leave
XFree86-debug with the "nv" driver running long
enough!
Thanks,
Kingsley
On 05/12/05 18:16, David Nusinow wrote:
> On Thu, May 12, 2005 at 12:57:52PM -0700, Kingsley G. Morse Jr. wr
On 05/10/05 23:47, Siward de Groot wrote:
> Maybe best solution would be to purge and reinstall X.
Although purging and reinstalling xserver-xfree86
and its configuration file seemed plausible, I
tried it and was still able to duplicate the
xserver-xfree86-dbg bug, which reports
no screens fo
I see in FAQ.gz that package maintainer scripts
won't overwrite XF86Config-4 because I modified
it.
However, I'm still wondering why XFree86-debug
aborted with
"no screens found"
in /var/log/XFree86.0.log when the unchanged
XF86Config-4 has a "Screen" section.
Feedback welcome,
Kingsl
Evidently the package named "xserver-xfree86-dbg"
has a version of X with debugging information
compiled in.
I hoped to use it on this report's bug and did
$ ln -s /usr/X11R6/bin/XFree86-debug /etc/X11/X
Unfortunately,
1.)
$ dpkg-reconfigure xserver-xfree86-dbg
didn't change /etc
After installing mscorefonts, the above GIMP
technique crashed X when choosing the fourth font
down in the "Script-Fu Font Selection" window
named
arial (msttcorefonts)
with its default style of "medium italic".
Since X crashes with a different arial font, I
suspect the bug isn't in the font
Upgrading libfreetype6 didn't fix it either.
However, I found that commenting out
FontPath "unix/:7101"
in
/etc/X11/XF86Config-4
stops GIMP->xtns->Script-Fu->Logos->Basic 1
from being able to use an arial font, which caused
X to crash.
Therefore, I suspect this bug is related to
X still crashes after upgrading
motifnls
ude
uwm
waimea
x-window-system
x-window-system-core
xbase-clients
xfonts-100dpi
xfonts-75dpi
xfonts-base
xfonts-cyrillic
xfonts-scalable
xfree86-common
xmbdfed
xutils
to unstable's current version
I just upgraded
ttf-freefont, xfs, freetype2, libttf2, oneko,
procmeter, rxvt, tkdesk, xboing, xtron
and removed
xf86setup, xfonts-pex, xfntil2, xesslite,
oledit, pavuk-x86-linux-glibc1-xt,
pointerlite, rv50-linux20, tk42, wabi,
wordperfect, xesslite, xlib6
and the GIM
Package: xserver-xfree86
Version: 4.3.0.dfsg.1-12.0.1
Severity: normal
Tags: sid
Thanks for maintaining Debian's xserver-xfree86
package.
It's important.
X can be made to crash by doing the following:
1.) run gimp
2.) use your mouse to select
xtns->Script-Fu->Logos->Basic 1
3.) click on
a VT8233A audio chip solved the
problem, but frankly, I'm guessing.
It's OK with me if you close this bug report.
Keep up the good work,
Kingsley
On 10/18/04 04:53, Branden Robinson wrote:
> On Fri, Oct 15, 2004 at 03:44:42PM -0700, Kingsley G. Morse Jr. wrote:
> > Unfortuna
On 10/15/04 16:53, Branden Robinson wrote:
> On Mon, Oct 11, 2004 at 03:15:19PM -0700, Kingsley G. Morse Jr. wrote:
> > > Are you aware of anything in particular that you
> > > are doing when the X server crashes?
> >
> > Good question.
> >
> > It se
On 10/11/04 16:28, Branden Robinson wrote:
> Thanks for following up with information about
> what happens when you use the nv driver.
Thanks for maintaining Debian's X packages.
> Are you aware of anything in particular that you
> are doing when the X server crashes?
Good question.
It seems to
1.) > sorry but you are using the nvidia binary
> driver and we can't provide any support for it,
> mainly due to the fact that there is no source
> code to check or fix.
Unless I'm mistaken, source code is in the package
named "nvidia-kernel-source", which I compiled.
2.) The bug is still in ver
Package: xserver-xfree86
Version: 4.3.0.dfsg.1-6
Severity: normal
Tags: sid
Thanks for maintaining Debian's xserver-xfree86
package.
It's important.
The main reason I'm writing is to report that its
intermittently crashing.
The last error message it reports in
/var/log/XFree86.0.log.old is
36 matches
Mail list logo
