2011/3/12 Michel Dänzer
> On Fre, 2011-03-11 at 22:49 +, Thue Janus Kristensen wrote:
> > I had 7.10-4. Downgrading to libgl1-mesa-dri_7.7.1-4_amd64.deb seems
> > to fix the crash.
>
> Mesa upstream Git commit 9b7f3776359640d452697f3a487a345820abebf0
> ('r600: don't close fd on failed load')
On Fre, 2011-03-11 at 22:49 +, Thue Janus Kristensen wrote:
> 2011/3/11 Michel Dänzer
> On Don, 2011-03-10 at 15:33 +0100, Michel Dänzer wrote:
> > On Don, 2011-03-10 at 14:13 +, Thue Janus Kristensen
> wrote:
> > > Accoding to gdb, the second server is cal
2011/3/11 Michel Dänzer
> On Don, 2011-03-10 at 15:33 +0100, Michel Dänzer wrote:
> > On Don, 2011-03-10 at 14:13 +, Thue Janus Kristensen wrote:
> > > Accoding to gdb, the second server is called as
> > >drmDropMaster(fd=9)
> > > and the first server calls
> > >drmSetMaster(fd=9)
> >
On Don, 2011-03-10 at 15:33 +0100, Michel Dänzer wrote:
> On Don, 2011-03-10 at 14:13 +, Thue Janus Kristensen wrote:
> > Accoding to gdb, the second server is called as
> >drmDropMaster(fd=9)
> > and the first server calls
> >drmSetMaster(fd=9)
> >
> >
> > Switching between VT7 an
On Don, 2011-03-10 at 14:13 +, Thue Janus Kristensen wrote:
> Accoding to gdb, the second server is called as
>drmDropMaster(fd=9)
> and the first server calls
>drmSetMaster(fd=9)
>
>
> Switching between VT7 and VT8 a few times, they also are both called
> with drmDropMaster(fd=9) a
Accoding to gdb, the second server is called as
drmDropMaster(fd=9)
and the first server calls
drmSetMaster(fd=9)
Switching between VT7 and VT8 a few times, they also are both called
with drmDropMaster(fd=9) and drmSetMaster(fd=9).
Regards, Thue
2011/3/10 Michel Dänzer
> On Don, 2011-03-
On Don, 2011-03-10 at 13:21 +, Thue Janus Kristensen wrote:
> 2011/3/10 Michel Dänzer
> On Don, 2011-03-10 at 12:38 +, Thue Janus Kristensen
> wrote:
> > after "finish" on drmDropMaster on the second X server, I
> get the
> > value "-1".
>
2011/3/10 Michel Dänzer
> On Don, 2011-03-10 at 12:38 +, Thue Janus Kristensen wrote:
> > "finish" doesn't display the return value, because there is no debug
> > symbols.
>
> Install libdrm2-dbg? :)
>
Ah, thanks. The return value is indeed -1.
>
> > A random page on the Internet said that
On Don, 2011-03-10 at 12:38 +, Thue Janus Kristensen wrote:
> "finish" doesn't display the return value, because there is no debug
> symbols.
Install libdrm2-dbg? :)
> A random page on the Internet said that the return value is probably
> in eax. Doing
>
>
> > print $eax
>
>
> after "f
Googling a bit more, it turns out that the return value on amd64 is in $rax.
That value was also -1.
Regards, Thue
2011/3/10 Thue Janus Kristensen
> "finish" doesn't display the return value, because there is no debug
> symbols. And amd64 assembler is not my strong point.
>
> A random page on t
"finish" doesn't display the return value, because there is no debug
symbols. And amd64 assembler is not my strong point.
A random page on the Internet said that the return value is probably in eax.
Doing
> print $eax
after "finish" on drmDropMaster on the second X server, I get the value
"-1".
On Mit, 2011-03-09 at 18:04 +, Thue Janus Kristensen wrote:
> 2011/3/9 Michel Dänzer
> How about if you only set a breakpoint on drmDropMaster in the
> second server, and on hitting it just 'finish' the function
> before continuing. Does the first server hit drmSetMas
2011/3/9 Michel Dänzer
> On Die, 2011-03-08 at 22:00 +, Thue Janus Kristensen wrote:
> >
> > With both drmDropMaster breakpointed in the second server,
> > and drmSetMaster breakpointed in the first server, drmDropMaster is
> > called first in the second server, and the first server doesn't r
2011/3/9 Michel Dänzer
> On Die, 2011-03-08 at 22:00 +, Thue Janus Kristensen wrote:
> >
> > With both drmDropMaster breakpointed in the second server,
> > and drmSetMaster breakpointed in the first server, drmDropMaster is
> > called first in the second server, and the first server doesn't r
On Die, 2011-03-08 at 22:00 +, Thue Janus Kristensen wrote:
>
> With both drmDropMaster breakpointed in the second server,
> and drmSetMaster breakpointed in the first server, drmDropMaster is
> called first in the second server, and the first server doesn't reach
> drmSetMaster until after I
Thanks to the gdb guru :).
With both drmDropMaster breakpointed in the second server, and drmSetMaster
breakpointed in the first server, drmDropMaster is called first in the
second server, and the first server doesn't reach drmSetMaster until after I
continue the second server from the drmDropMast
On Tue, Mar 8, 2011 at 20:31:34 +, Thue Janus Kristensen wrote:
> I just tried, and with a gdb attached to both processes, there is no crash.
> I had to *continue* over some SIGPIPE etc, but I assume that is normal.
>
Yes, you want 'handle SIGPIPE nostop noprint' in gdb.
Cheers,
Julien
-
I just tried, and with a gdb attached to both processes, there is no crash.
I had to *continue* over some SIGPIPE etc, but I assume that is normal.
So I assume that the problem is some kind of race condition? As I said, it
is 100% reproducible until I tried it in gdb :).
Regards, Thue
2011/3/8 M
On Tue, Mar 08, 2011 at 01:08:53PM +0100, Michel D?nzer wrote:
> On Sam, 2011-03-05 at 18:36 +, Thue Janus Kristensen wrote:
> > As far as I can tell, there is nothing interesting in kdm.log or
> > Xorg.1.log (both attached, for a newly generated crash).
>
> Would be interesting if one of you
I am behind a NAT from my ISP. Would you be able to access a ssh server if I
installed the miredo package (ipv6 tunneling)? (you could perhaps use the
miredo package yourself)
Regards, Thue
2011/3/8 Michel Dänzer
> On Sam, 2011-03-05 at 18:36 +, Thue Janus Kristensen wrote:
> > As far as I
On Sam, 2011-03-05 at 18:36 +, Thue Janus Kristensen wrote:
> As far as I can tell, there is nothing interesting in kdm.log or
> Xorg.1.log (both attached, for a newly generated crash).
Would be interesting if one of you guys could (from a remote login)
attach gdb to both X servers and check t
On Don, 2011-03-03 at 10:33 +0100, Thue Janus Kristensen wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.0-1
> Severity: important
>
> I have a 100% reproducible crash, using these steps:
> 1) From inside KDE go "kde menu"->"leave"->"switch user"
> 2) "New session"
> 3) log in to th
22 matches
Mail list logo
