ok - while doing a very quick & light check - at least on Firefox input
window I do not observe any rendering bugs (which have been pretty
simple to reach before).
(Lenovo T61 + git + patch from comment 168)
Thought the performance decrease is noticeable and also the setting for
MAX_FLUSH... bec
I've not yet tested patch from comment 165 - but with regards to Firefox
and Cairo - I'm also seeing errors in i.e. pidgin - where status icons
looks occasionally damaged.
And my rawhide has these related packages:
cairo-1.13.1-0.1.git337ab1f.fc21.x86_64
cairo-gobject-1.13.1-0.1.git337ab1f.fc21
Ok - seem(In reply to comment #170)
> Created attachment 92288 [details]
> bug
>
> f23ab963c4f4ada2051588dfc85264aa2798dbf7 + that patch and I'm seeing
> corruption. Using google-chrome and letters in url bar or window title bar
> sometimes get corrupted and then get fixed.
>
> Also seeing the pr
Update after some new commits:
4c7b183fd21b461f9f18662c3b9d9732b6bef13d + Always patch - now gives me
broken text lines in Thunderbird window.
And it's now enough just to move the mouse over text and the text is
changing and actually never renders correctly some letters.
Checking back f23ab963c
Created attachment 92240
Text with errors
Recently I'm noticing somewhat more 'weird' behavior - it might be
related to my temporal usage of night releases of Mozilla (since rawhide
version got somewhat broken)
What is weird in this image is - the text was badly rendered AND it
remained visible e
(In reply to comment #160)
> Typical, it appeared stable through my firefox testing, but if you try
> reverting b7565a26401e283df94b68019e8093f8104428f4, I expect the corruptions
> to disappear again.
Yep - correct revert of this commit make MAX_VERTEX 1 again producing
correct rendering - even t
(In reply to comment #160)
> Typical, it appeared stable through my firefox testing, but if you try
> reverting b7565a26401e283df94b68019e8093f8104428f4, I expect the corruptions
> to disappear again.
Yep - correct revert of this commit make MAX_VERTEX 1 again producing
correct rendering - even t
bad news - now I'm in fact able to spot badly rendered characters in
Firefox also with MAX 1
So something went wrong
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1098334
Title:
[gen4 sna] Fo
Created attachment 91613
Grabbed snapshot with patch from comment 157
As could be seen - yes - with little effort I'm able to capture broken
characters with given patch compiled in.
The only needed thing is to start to edit the dialog in the Firefox and
start to add/remove random characters over
I think nice illustration could be - that while before with MAX 9 it
seemed like i.e. gnome-terminal running top was not really rendering
broken characters - it now seems to show a lot of messed characters.
On the other hand - MAX 1 seems to be now more fluent then before - so
except for some dra
(In reply to comment #153)
> (In reply to comment #145)
> > Created attachment 91383 [details]
> > gedit in openbox with 2.99.907 GM45 SNA
> >
> > I am finding that GM45 SNA seems unusable with 2.99.907 - git bisect pointed
> > to the bad commit as:
> > 9289e2c56b7f0cc78c5123691ad96611f0e04bed is
bad news - now I'm in fact able to spot badly rendered characters in
Firefox also with MAX 1
So something went wrong
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1098489
Title:
[gen4] Corrup
I think nice illustration could be - that while before with MAX 9 it
seemed like i.e. gnome-terminal running top was not really rendering
broken characters - it now seems to show a lot of messed characters.
On the other hand - MAX 1 seems to be now more fluent then before - so
except for some dra
Created attachment 91613
Grabbed snapshot with patch from comment 157
As could be seen - yes - with little effort I'm able to capture broken
characters with given patch compiled in.
The only needed thing is to start to edit the dialog in the Firefox and
start to add/remove random characters over
(In reply to comment #153)
> (In reply to comment #145)
> > Created attachment 91383 [details]
> > gedit in openbox with 2.99.907 GM45 SNA
> >
> > I am finding that GM45 SNA seems unusable with 2.99.907 - git bisect pointed
> > to the bad commit as:
> > 9289e2c56b7f0cc78c5123691ad96611f0e04bed is
(In reply to comment #136)
> The issue that the VUE (which is a memory slot used by the GPU for a vertex
> entry) are reused by a second thread before the first thread is complete,
> causing the first thread to generate invalid texture coordinates and corrupt
> rendering. That is a hardware read-wr
(In reply to comment #107)
> The quick answer is that if ever see it with MAX_FLUSH_VERTICES set to 1,
> then it is a different issue. Please do be aware that all current kernels
> since 3.7 do have a coherency issue, the fix will not arrive before 3.10.1
> (outside of drm-intel trees).
Could you
Well here is just another one -
$ ./basic-copyarea
Opened connection to :0 for testing.
Testing setting of single pixels (root): passed [1 iterations x 4096]
Testing area sets (root): passed [1 iterations x 4096]
Testing area fills (root, using pixmap source): passed [1 iterations x 4096]
Testing
Well I'm curious how this explains this - I've taken current git -
changed the value to '44' - and I'm typing this text. I could see a lot of
errors during text typing - but these errors seems to be somehow limited only
to certain regions of shown text.
It's not destroyed everywhere - only in
Well I could add here output of some tests:
i.e.:
$ ./render-composite-solid
Opened connection to :0 for testing.
Testing setting of single pixels (root): passed [1 iterations x 4096]
Testing area sets (root): passed [1 iterations x 4096]
Testing area fills (root): passed [1 iterations x 4096]
Te
(In reply to comment #99)
> (In reply to comment #97)
> > (In reply to comment #96)
> > > (In reply to comment #93)
> > > > The bad part is - while before I've been getting 3.7Mchar/s in x11perf
> > > > -aa10text - now it's like 1.3Mchar/s so significantly slower.
> > But as I said before - if th
Just to add some more comment on MAX_FLUSH_VERTICES - when set to valu
96 - it gives the highest throughput on x11perf -aa10text 3.7MChar/s -
using any higher value doesn't make any different (so the max seems to
be somewhere between <64-96]
Also when this 3.7MChar is rendered - the parallel m
Maybe this bug could be more easily tracked down when the amount of
vertices is actually much higher - since in this case it seems to crash
almost immediatelly.
I understand there is some 'maximum queue' size GPU could handle - but
the engine should be able to track size of all commands and not ou
I've been looking at drm-intel-next-queued/drm-intel-fixes - there are
quite a few patches - but also a lot of reverts recently - so I'm
pretty much confused what is actually the solution for gma965 in T61.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Created attachment 82127
Scroll with intel_gpu_top
I've captured video when problem appears and when doesn't
(Attaching only frame)
Using some past kernel 3.10 b2c311075db578f1433d9b303698491bfa21279a
(as of now - current vanilla)
Using current xf86 tree 5aaab9ea0310d48bb1a1ca20308d1c9721a9de3f
And with 12 - flickering starts to appear as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1098489
Title:
[gen4] Corruption in Chrome omni bar results using Intel SNA
To manage notifications
It could be probably worth to mention - that when I'm flipping between
Firefox tabs I could have scrolling tabs without any issue (and low GPU
usage), while flipping to other tabs and scrolling in them increases GPU
to high levels and visual problems are present.
So in the moment the problem appea
Well I should wait a while before posting a comment about magic value 6.
I'm now observing flickering with value 6 as well.
So yeah - it's more or less time related - and it takes more or less
time until the problem becomes visible.
Also is there explanation with the max value 64 starts to make
(In reply to comment #105)
> Created attachment 82227 [details]
> Snapshot on the issue on characters
>
Yep - that's exactly what I easily observe with gnome-terminal when I increase
max triangles from recent Chris patches to 64 - this is present almost all the
time. And it's very occasional w
(In reply to comment #92)
> Removed an older hack and had to reduce the max further. Bah, humbugs.
OK, this time I'm definitely not able to reproduce the issue so far.
Maybe it will some extra time - hard to say now - but before it has took me
just minutes to get the issue visible.
intel_gpu_top
Created attachment 82128
Scroll with intel_gpu_top and no problems
Quite the same system - except the problem was not visible (restarted X
session).
As could be seen - now during scrolling the GPU has been basically unloaded.
Nothing else the Firefox scroll has been basically done.
I should als
>From what I'm experiencing after driver rebuild - I'd have said - now
it's actually much simpler to trigger that flickering/high GPU usage.
So unless the patch is missing something - than limitation to 16 doesn't
help here on T61.
--
You received this bug notification because you are a member o
(In reply to comment #74)
> I think I've a sort of positive message here
> at least on my T61 - now using upstream git commit
>
> 8f340f90f4b2f269d6308d0bd31fbc2a5f579608
>
> I'm no longer observing corruptions while scrolling Firefox pages.
> So some recent commit is probably behind this change
I'm doing some experiments with MAX_FLUSH_VERTICES.
When set to 64 - even gnome-terminal starts so show weird pixels in some
cases.
Now I'm just playing with value 12 (gives ~2.1Mchars/s) and I'm hunting
for visual problems.
--
You received this bug notification because you are a member of Ubu
Created attachment 82118
Video capture showing flicker on firefox scroll
I've captured at 25FPS some example how the pictures are flickering when
i.e. Firefox windows is being scrolled up/down. In most cases, the
pictures is visible normally when scrolling stops, but in rare case the
picture stays
(In reply to comment #78)
> No hope to solve this and many, many other bugs on gen4 - here and in mesa.
> I suggest to buy new laptop because it doesn't have any sense. Some time ago
> I also thought that it has. Now I have Intel Ivybridge and Nvidia through
> Bumblebee and both runs almost perfect
(In reply to comment #96)
> (In reply to comment #93)
> > The bad part is - while before I've been getting 3.7Mchar/s in x11perf
> > -aa10text - now it's like 1.3Mchar/s so significantly slower.
>
> That's the sacrifice, we have to stop sending commands to the GPU and wait
> for it complete those
Hmm - after doing some more experiments - the high load on GPU seems
to be pretty much the thing which make the problem visible.
Another interesting thing is - it's usually enough to just 'reload' the
very same page in Firefox and the load goes down to ~1% and everything
is ok.
Also the kernel
(In reply to comment #84)
> Yes, that is characteristic of this bug. The internal vertex/texture
> coordinates that are being passed along the GPU pipeline become corrupt (it
> looks like we overflow a small ring buffer). The only effective approach
If it would be plain 'overflow' - than I'd be se
I think I've a sort of positive message here
at least on my T61 - now using upstream git commit
8f340f90f4b2f269d6308d0bd31fbc2a5f579608
I'm no longer observing corruptions while scrolling Firefox pages.
So some recent commit is probably behind this change.
Before I've used 14 days older commit
Maybe this bug could be more easily tracked down when the amount of
vertices is actually much higher - since in this case it seems to crash
almost immediatelly.
I understand there is some 'maximum queue' size GPU could handle - but
the engine should be able to track size of all commands and not ou
Well I'm curious how this explains this - I've taken current git -
changed the value to '44' - and I'm typing this text. I could see a lot of
errors during text typing - but these errors seems to be somehow limited only
to certain regions of shown text.
It's not destroyed everywhere - only in
Just to add some more comment on MAX_FLUSH_VERTICES - when set to valu
96 - it gives the highest throughput on x11perf -aa10text 3.7MChar/s -
using any higher value doesn't make any different (so the max seems to
be somewhere between <64-96]
Also when this 3.7MChar is rendered - the parallel m
(In reply to comment #136)
> The issue that the VUE (which is a memory slot used by the GPU for a vertex
> entry) are reused by a second thread before the first thread is complete,
> causing the first thread to generate invalid texture coordinates and corrupt
> rendering. That is a hardware read-wr
I've been looking at drm-intel-next-queued/drm-intel-fixes - there are
quite a few patches - but also a lot of reverts recently - so I'm
pretty much confused what is actually the solution for gma965 in T61.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
(In reply to comment #107)
> The quick answer is that if ever see it with MAX_FLUSH_VERTICES set to 1,
> then it is a different issue. Please do be aware that all current kernels
> since 3.7 do have a coherency issue, the fix will not arrive before 3.10.1
> (outside of drm-intel trees).
Could you
Created attachment 82127
Scroll with intel_gpu_top
I've captured video when problem appears and when doesn't
(Attaching only frame)
Using some past kernel 3.10 b2c311075db578f1433d9b303698491bfa21279a
(as of now - current vanilla)
Using current xf86 tree 5aaab9ea0310d48bb1a1ca20308d1c9721a9de3f
Created attachment 82118
Video capture showing flicker on firefox scroll
I've captured at 25FPS some example how the pictures are flickering when
i.e. Firefox windows is being scrolled up/down. In most cases, the
pictures is visible normally when scrolling stops, but in rare case the
picture stays
Well I should wait a while before posting a comment about magic value 6.
I'm now observing flickering with value 6 as well.
So yeah - it's more or less time related - and it takes more or less
time until the problem becomes visible.
Also is there explanation with the max value 64 starts to make
(In reply to comment #105)
> Created attachment 82227 [details]
> Snapshot on the issue on characters
>
Yep - that's exactly what I easily observe with gnome-terminal when I increase
max triangles from recent Chris patches to 64 - this is present almost all the
time. And it's very occasional w
(In reply to comment #99)
> (In reply to comment #97)
> > (In reply to comment #96)
> > > (In reply to comment #93)
> > > > The bad part is - while before I've been getting 3.7Mchar/s in x11perf
> > > > -aa10text - now it's like 1.3Mchar/s so significantly slower.
> > But as I said before - if th
And with 12 - flickering starts to appear as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1098334
Title:
[gen4 sna] Font corruption in Chromium tab bar
To manage notifications about this bug
>From what I'm experiencing after driver rebuild - I'd have said - now
it's actually much simpler to trigger that flickering/high GPU usage.
So unless the patch is missing something - than limitation to 16 doesn't
help here on T61.
--
You received this bug notification because you are a member o
I'm doing some experiments with MAX_FLUSH_VERTICES.
When set to 64 - even gnome-terminal starts so show weird pixels in some
cases.
Now I'm just playing with value 12 (gives ~2.1Mchars/s) and I'm hunting
for visual problems.
--
You received this bug notification because you are a member of Ubu
(In reply to comment #96)
> (In reply to comment #93)
> > The bad part is - while before I've been getting 3.7Mchar/s in x11perf
> > -aa10text - now it's like 1.3Mchar/s so significantly slower.
>
> That's the sacrifice, we have to stop sending commands to the GPU and wait
> for it complete those
It could be probably worth to mention - that when I'm flipping between
Firefox tabs I could have scrolling tabs without any issue (and low GPU
usage), while flipping to other tabs and scrolling in them increases GPU
to high levels and visual problems are present.
So in the moment the problem appea
Hmm - after doing some more experiments - the high load on GPU seems
to be pretty much the thing which make the problem visible.
Another interesting thing is - it's usually enough to just 'reload' the
very same page in Firefox and the load goes down to ~1% and everything
is ok.
Also the kernel
(In reply to comment #84)
> Yes, that is characteristic of this bug. The internal vertex/texture
> coordinates that are being passed along the GPU pipeline become corrupt (it
> looks like we overflow a small ring buffer). The only effective approach
If it would be plain 'overflow' - than I'd be se
Created attachment 82128
Scroll with intel_gpu_top and no problems
Quite the same system - except the problem was not visible (restarted X
session).
As could be seen - now during scrolling the GPU has been basically unloaded.
Nothing else the Firefox scroll has been basically done.
I should als
(In reply to comment #92)
> Removed an older hack and had to reduce the max further. Bah, humbugs.
OK, this time I'm definitely not able to reproduce the issue so far.
Maybe it will some extra time - hard to say now - but before it has took me
just minutes to get the issue visible.
intel_gpu_top
(In reply to comment #78)
> No hope to solve this and many, many other bugs on gen4 - here and in mesa.
> I suggest to buy new laptop because it doesn't have any sense. Some time ago
> I also thought that it has. Now I have Intel Ivybridge and Nvidia through
> Bumblebee and both runs almost perfect
(In reply to comment #74)
> I think I've a sort of positive message here
> at least on my T61 - now using upstream git commit
>
> 8f340f90f4b2f269d6308d0bd31fbc2a5f579608
>
> I'm no longer observing corruptions while scrolling Firefox pages.
> So some recent commit is probably behind this change
I think I've a sort of positive message here
at least on my T61 - now using upstream git commit
8f340f90f4b2f269d6308d0bd31fbc2a5f579608
I'm no longer observing corruptions while scrolling Firefox pages.
So some recent commit is probably behind this change.
Before I've used 14 days older commit
I assume missing LVs are just not activated ?
Have you tried vgchange -ay
Aventually you may post output from lvdisaplay.
Also - I'd add here comment to usage of lvdisplay & awk. There is failry
simplier way: lvs -o help
-> lvs --noheadings -o lv_name
--
lvm /dev broken after upgrade
h
For better diagnostic - please try to use 'blockdev --getsize64
/all/your/involved/devices'
The show the output from pvs/vgs
Also note lvm support both type of units G/Gi
Without these information this bug report is not really useful.
lvm tools doesn't definitely randomly overallocates spac
Looks like a 'famous' udev issue problem - currently it's still being
resolved. There is no clear way, how to prevent 'random' device open
from udev rules. 'watch' rule is usually the main source of troubles.
udev rules needs to be changed...
--
lvremove fails
https://bugs.launchpad.net/bugs/53
Yes, man page is going to be updated in upstream version of LVM (>=
2.02.68)
As for now - without --resizefs the man page clearly tells this:
"Be careful when reducing a logical volume's size, because data
in the reduced part is lost!!! You should therefore ensure that any
filesystem on
Note - leaked message is basically harmless - it only reports that it
was executed from environment which left more opened descriptors than
stdin/out/err - this may present security problem - that's why lvm tool
report this issue. So effectively it means the problem is in the
executing shelll whic
68 matches
Mail list logo
