Hi!
I did some more tests, today with current xserver and video drivers from
testing and kernel 3.4 from experimental, still same old results, so I
thought I'd give a try to the new xserver-xorg-video-intel 2:2.19.0-2 from
unstable and the new aceleration, ... well, I didn't had the chance, as it
I thought I could test with lower bpp depths so that less memory was needed
(I seem to recall that at lower depth I could run without needing to specify
the memory parameter on previous versions of xorg) but the results were
exactly the same.
I even tested 800x600 @ 16 bpp with same blue video out
> Did
>
> > [ 199.905] (EE) intel(0): Detected a hung GPU, disabling acceleration.
> > [ 199.905] (EE) intel(0): When reporting this, please include
> > i915_error_state from debugfs and the full dmesg.
>
> and
>
> > [ 199.864077] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> > e
Package: xserver-xorg-video-intel
Version: 2:2.18.0-2
Severity: normal
Playing back video on a i830M card shows a blue video the first time and
X11 error: BadAlloc (insufficient resources for operation)
the next times you try it.
This is when using XV, if you try to render with X11 there is no p
> > I have just updated the machine to current Lenny and it still fails
> > in the very same way as it used to.
>
> is it going any better with squeeze or higher?
Nope, it is still failing at squeeze, I'm using the fb driver right now
because of this.
Do you want me to test upgrading to sid? any
reassign 571741 linux-source-2.6.32
stop
Hi!
As far as I can tell it seems that the kernel upstream patch I was reporting
about resolves this bug.
I have tested the patch on our 2.6.32 for several days without any problem.
I'm reasigning the bug to the kernel package as the problem is within t
Hi!
Upstream is sugesting that a Linus kernel patch is fixing this, I'm going to
try to test this on Debian's 2.6.32 kernel and report back, if anybody else
is willing to test, this is the commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=985b823b919273fe1327d56d
Hi!
I have just submitted it upstream, you can follow it here:
http://bugs.freedesktop.org/show_bug.cgi?id=26825
Regards.
--
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.o
This time I was testing with 2.6.33 after upgrading libdrm, mesa, ... as
Cyril Brulebois suggests on his "Where have you been" post at planet.
After first pm-hibernate everything seemed fine, but after the second one I
saw this:
[ 1083.562662] PM: restore of devices complete after 1476.094 msecs
I just tried with the nodri line (checked it and DRI was effectively
disabled) using 2.6.33-2 and same weird behaviour happened, at the
xscreensaver I wasn't able to authenticate after the pm-hibernate and when I
went to a tty it was not able to spawn a login and got some error about an
assertion n
Like I said on the report the machine was going well on the -1 version of
the intel driver, it was only then I upgraded to -2 that it started failing,
furthermore, if I disable kms the machine is fine again.
Machine is completely stable, there can be no poblem with any hardware,
machine is complet
Ok, I have started testing this new 2.6.32 and did a little bit better but I
think this was only luck, nothing else.
I could log on and saw this on dmesg:
[ 396.756554] Restarting tasks ...
[ 396.757030] klogd[1194]: segfault at cc9cd400 ip 7fe87ebb3c02 sp
7fffcc9ccf40 error 6 in libc-
I have just tried that new kernel and the behaviour was the same.
I could not log into the machine, not on ssh or the console. Let me explain
what I was seing... the screen was locked with xscreensaver and it didn't
recognice my password, so I switched to a VT and tried to log on there, but
the ge
I see there are a lot of solutions for this, I'd like to explain how I did
it and sugest that some comments of the ways to fix this and examples are
added in a README.Debian or examples dir or similar.
All I did was add this two sections to my xorg.conf:
Section "InputDevice"
Identifier
I have just updated the machine to current Lenny and it still fails in the
very same way as it used to.
I think I didn't mention that a normal kill doesn't kill the server and you
need a kill -9 to kill it and it doesn't restore the text mode after that,
the same totted X screen remains and keyboa
Package: xserver-xorg-video-intel
Version: 2:2.3.1-1
Severity: important
I sent this bug already for version 2:2.2.0-1 but we had it closed as it
seemed that the bug was gone, maybe some of the cases on which it was
happening are now fixed, but it still happens on current versions of the
driver.
> Ping?
>
> Please try with 2:2.2.0.90-2 which has been uploaded today.
Sorry, I could not reply before, this seems to fix the problem at least for
my system. The only weird thing I saw was that the server is coming up with
a resolution bigger than the one on the laptop's screen, I solved this by
Package: xserver-xorg-video-intel
Version: 2:2.2.0-1
Severity: important
The server works ok, but if I let it go into DPMS mode, when coming back I
get a black screen, only the mouse pointer is shown then, I can move it and
it is perfectly drawn, but the whole screen remains black. I can get the
s
> It seems to work for me using the latest intel driver (thus using EXA).
> Andreas Henriksson said he could reproduce this when using XAA, but not
> using EXA (with the radeon driver), so I'm retitling it accordingly (and
> tagging wontfix, because nobody seems interested in fixing XAA these
> day
> Can you try xserver-xorg-video-ati 6.7.196-2 currently in experimental?
I have tried it without any improvement, still no video if we use XAA.
Regards...
--
Manty/BestiaTester -> http://manty.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contac
> What did you upgrade when the breakage appeared? the whole Xorg from
> testing to unstable? or did you just update your unstable?
I hadn't realised of the problem as my amd64 was having it all the time as
it is my develpment machine and runs unstable since I installed it not too
long ago. What I
Package: xserver-xorg
Version: 1:7.3+7
Severity: important
The problem seems to be related to painting an image with cairo and maybe
scaling.
For example, trying to see a youtube video fails, also some swf files on
which there is a bitmap mixed with some vector graphics, are seen ok on
standard s
Hi!
I thought this patch would be applied on the new upload, but it seems it
wasn't, I have reworked it again so that it applies well against the new
packages and I'm sending it again to see if we have better luck next time
;-)
Regards...
--
Manty/BestiaTester -> http://manty.net
diff -r -u xc.
Package: xfree86
Severity: wishlist
Tags: patch
Hi!
I have found that my Radeon card as well as many others, says that it can
work from 20Mhz to 400Mhz, this would mean that it is not capable of
producing TV frequencies, which it is, I have found that this problem had
been reported on xfree86 bug
> > If so I think I should probably build and test 4.3.0-0pre1v5 with
> > 056_i810_make_i830_usable.diff instead of
> > 000_stolen_from_HEAD_i830_driver.diff, what do you think?
>
> Sounds like a good plan. Please let us know how this turns out.
Well, sorry for not reporting before, I have had t
> You should probably let David Dawes know that the fixes that were
> committed to xf-4_3-branch made things worse, not better.
I was going to ask him about that, but I realised that asside the changes in
the 000_post430.diff patch, which I suppose are the changes on the 4.3
branch, there is also
Hi!
I was happily using 4.3.0-0pre1v4 on my i830 based laptop and when I
upgraded to 4.3.0-0pre1v5 VT switching broke.
It is the typical effect descrived by David Dawes in his pages, this is:
going from X to the text mode vts will make me loose the screen, which
then, when going back to X will ge
> Why do you call it a "dummy" patch? It looks to me like it actually
> does something.
Yes, well the thing is that the patch is only a couple of defines and an if
sentence. It works by allowing the 64V2 work like the other trios and
setting the maximun clocks allowed (set using the values we've
> Why do you call it a "dummy" patch? It looks to me like it actually
> does something.
Yes, well the thing is that the patch is only a couple of defines and an if
sentence. It works by allowing the 64V2 work like the other trios and
setting the maximun clocks allowed (set using the values we've
EMAIL PROTECTED]
--- s3trio64v2.diff
Patch to add dummy support for the S3 Trio64V2 DX or GX
By Santiago Garcia Mantinan and Javier Moran Rua
--- xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c.orig Fri Jan 24
14:40:44 2003
+++ xc/programs/Xserver/hw/xfr
TYPE=es_ES@euro
--- s3trio64v2.diff
Patch to add dummy support for the S3 Trio64V2 DX or GX
By Santiago Garcia Mantinan and Javier Moran Rua
--- xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c.orig Fri Jan 24 14:40:44
2003
+++ xc/programs/Xserver/hw/xfr
Package: xfree86v3
Version: unavailable; reported 2002-11-29
Followup-For: Bug #137752
This is a dirty patch that enables xfree86v3 to build on powerpc, the first
part is to correct one of the patches to make it put the configuration for
xfree68 on the correct place, this was done on xfree86 but n
Package: xfree86v3
Version: unavailable; reported 2002-11-29
Followup-For: Bug #137752
This is a dirty patch that enables xfree86v3 to build on powerpc, the first
part is to correct one of the patches to make it put the configuration for
xfree68 on the correct place, this was done on xfree86 but n
33 matches
Mail list logo
