On Thu 2014-05-15 17:31:54, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina <[email protected]> wrote:
> >> > Note that X do work somehow after resume (I can't switch virtual
> >> > desktops and dialog is stuck on screen, but it is not complete
> >> > failure). I can do ctrl-alt-f1 and get to useful prompt.
> >>
> >> Oops. You were right. It seems it is duplicate after all.
> >>
> >> [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00001020 tail 00000000 start 00003000
> >
> > Pavel, thanks a lot for testing.
> >
> > Adding Daniel and Chris to CC -- we have another incarnation of the bug
> > that is being chased in 76554.
>
> Someone succeeding at a bisect would be awesome ... Note that the only
> key here is the ring init failure in dmesg.
Oh and... the machine has problems comming up after reboot (never seen
those before 3.15). Sometimes, boot will hang with blank screen, and hard
powerdown is needed...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat 2014-06-07 14:06:14, Pavel Machek wrote:
> On Thu 2014-05-15 17:31:54, Daniel Vetter wrote:
> > On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina <[email protected]> wrote:
> > >> > Note that X do work somehow after resume (I can't switch virtual
> > >> > desktops and dialog is stuck on screen, but it is not complete
> > >> > failure). I can do ctrl-alt-f1 and get to useful prompt.
> > >>
> > >> Oops. You were right. It seems it is duplicate after all.
> > >>
> > >> [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00001020 tail 00000000 start 00003000
> > >
> > > Pavel, thanks a lot for testing.
> > >
> > > Adding Daniel and Chris to CC -- we have another incarnation of the bug
> > > that is being chased in 76554.
> >
> > Someone succeeding at a bisect would be awesome ... Note that the only
> > key here is the ring init failure in dmesg.
>
> Oh and... the machine has problems comming up after reboot (never seen
> those before 3.15). Sometimes, boot will hang with blank screen, and hard
> powerdown is needed...
Strange. It seems 3.15 with the patch reverted only boots in 30% or so
cases... And I've seen resume failure, too, so maybe I was just lucky
that it worked for a while.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, Jun 8, 2014 at 1:11 AM, Pavel Machek <[email protected]> wrote:
> Strange. It seems 3.15 with the patch reverted only boots in 30% or so
> cases... And I've seen resume failure, too, so maybe I was just lucky
> that it worked for a while.
git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
the 5th report or so that claims this is the culprit but it's
something else. The above code is definitely not used in i915 so bogus
bisect result.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon 2014-06-09 11:25:20, Daniel Vetter wrote:
> On Sun, Jun 8, 2014 at 1:11 AM, Pavel Machek <[email protected]> wrote:
> > Strange. It seems 3.15 with the patch reverted only boots in 30% or so
> > cases... And I've seen resume failure, too, so maybe I was just lucky
> > that it worked for a while.
>
> git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
> the 5th report or so that claims this is the culprit but it's
> something else. The above code is definitely not used in i915 so bogus
> bisect result.
Note I did not do the bisect, I only attempted revert and test.
And did three boots of successful s2ram.. only to find out that it
does not really fix s2ram, I was just lucky :-(.
Unfortunately, this means my s2ram problem will be tricky/impossible
to bisect :-(.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 9 Jun 2014, Pavel Machek wrote:
> > > Strange. It seems 3.15 with the patch reverted only boots in 30% or so
> > > cases... And I've seen resume failure, too, so maybe I was just lucky
> > > that it worked for a while.
> >
> > git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
> > the 5th report or so that claims this is the culprit but it's
> > something else. The above code is definitely not used in i915 so bogus
> > bisect result.
>
> Note I did not do the bisect, I only attempted revert and test.
>
> And did three boots of successful s2ram.. only to find out that it
> does not really fix s2ram, I was just lucky :-(.
>
> Unfortunately, this means my s2ram problem will be tricky/impossible
> to bisect :-(.
Welcome to the situation I have been in for past several months.
--
Jiri Kosina
SUSE Labs
On Mon 2014-06-09 13:03:31, Jiri Kosina wrote:
> On Mon, 9 Jun 2014, Pavel Machek wrote:
>
> > > > Strange. It seems 3.15 with the patch reverted only boots in 30% or so
> > > > cases... And I've seen resume failure, too, so maybe I was just lucky
> > > > that it worked for a while.
> > >
> > > git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
> > > the 5th report or so that claims this is the culprit but it's
> > > something else. The above code is definitely not used in i915 so bogus
> > > bisect result.
> >
> > Note I did not do the bisect, I only attempted revert and test.
> >
> > And did three boots of successful s2ram.. only to find out that it
> > does not really fix s2ram, I was just lucky :-(.
> >
> > Unfortunately, this means my s2ram problem will be tricky/impossible
> > to bisect :-(.
>
> Welcome to the situation I have been in for past several months.
I attempted to do some analysis. It should be possible to bisect when
tests are not reliable, but it will take time and it will be almost
neccessary to have the bisection automated.
How long does the testing take for you to get to 50% test reliability?
It seems to be one minute here.
Trivial strategy is to repeat each test to get to 99% test
reliability. That should make the test about 2x longer.
There are other strategies possible -- like selecting bisect points
closer to the "bad" end, and tricky "lets compute probabilities for
each point", that work well for some parameter settings. There is
probably even better strategy possible... if you have an idea, you can
try it below.
Monte carlo simulation is attached.
Bisector on reliable bug
-----
1024 versions bug with probability of 0 false success, monte carlo
of 30000 tries
Assume compilation takes 6 minutes and test takes 1 minutes
Average cost 71.0522 minutes
Average tests 9.99793333333
Bisector
-----
1024 versions bug with probability of 0.5 false success, monte carlo
of 30000 tries
Assume compilation takes 6 minutes and test takes 1 minutes
Average cost 143.393933333 minutes
Average tests 44.5374666667
Trisector
-----
1024 versions bug with probability of 0.5 false success, monte carlo
of 30000 tries
Assume compilation takes 6 minutes and test takes 1 minutes
Average cost 160.554 minutes
Average tests 39.9552666667
Strange
-----
1024 versions bug with probability of 0.5 false success, monte carlo
of 3000 tries
Assume compilation takes 6 minutes and test takes 1 minutes
Average cost 246.658 minutes
Average tests 38.412
pavel@amd:~/WWW$
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
I just test-booted 3.16-rc1, and background in X looked just wrong --
very noticeable bands on the background gradient. I thought that maybe
it is just my eyes, but I went back to older kernel, and background is
ok now.
I'm trying to figure out how to ask X what color depth it is using...?
This is thinkpad x60 with Debian 6.0.9.
Any ideas?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat 2014-06-21 22:29:01, Pavel Machek wrote:
> Hi!
>
> I just test-booted 3.16-rc1, and background in X looked just wrong --
> very noticeable bands on the background gradient. I thought that maybe
> it is just my eyes, but I went back to older kernel, and background is
> ok now.
>
> I'm trying to figure out how to ask X what color depth it is using...?
>
> This is thinkpad x60 with Debian 6.0.9.
>
> Any ideas?
Xorg.log does not show anything too suspicious:
diff -u /var/log/Xorg.0.log{,.old} > /tmp/delme
Pavel
--- /var/log/Xorg.0.log 2014-06-21 22:24:15.005229099 +0200
+++ /var/log/Xorg.0.log.old 2014-06-21 22:22:38.275847726 +0200
@@ -3,8 +3,8 @@
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-4-amd64 i686 Debian
-Current Operating System: Linux duo 3.10.0+ #293 SMP Sun Jul 14 22:44:49 CEST 2013 i686
-Kernel command line: BOOT_IMAGE=(hd0,3)/boot/vmlinuz-3.10 root=/dev/sda3 resume=/dev/sda1 psmouse.psmouse_proto=imps psmouse_proto=imps psmouse.proto=imps acpi_sleep=s3_bios,s3_mode no_console_suspend i915.modeset=1 video=inteldrmfb:mode=1024x768 fbcon=scrollback:64k
+Current Operating System: Linux duo 3.16.0-rc1+ #373 SMP Sat Jun 21 20:46:47 CEST 2014 i686
+Kernel command line: BOOT_IMAGE=(hd0,2)/l/linux-good/arch/x86/boot/bzImage root=/dev/sda3 resume=/dev/sda1 psmouse.psmouse_proto=imps psmouse_proto=imps psmouse.proto=imps acpi_sleep=s3_bios,s3_mode no_console_suspend i915.modeset=1 video=inteldrmfb:mode=1024x768 fbcon=scrollback:64k
Build Date: 17 December 2013 08:26:59PM
xorg-server 2:1.7.7-18 (Julien Cristau <[email protected]>)
Current version of pixman: 0.16.4
@@ -13,7 +13,7 @@
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Sat Jun 21 22:23:28 2014
+(==) Log file: "/var/log/Xorg.0.log", Time: Sat Jun 21 21:04:49 2014
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(==) No Layout section. Using the first Screen section.
(==) No screen section available. Using defaults.
@@ -402,10 +402,17 @@
(II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
-(II) intel(0): EDID vendor "LEN", prod id 16384
-(II) intel(0): Printing DDC gathered Modelines:
-(II) intel(0): Modeline "1024x768"x0.0 54.16 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (40.3 kHz)
-(II) intel(0): Modeline "1024x768"x0.0 43.33 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (32.2 kHz)
-(II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
-(II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
-(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
+(II) Power Button: Close
+(II) UnloadModule: "evdev"
+(II) Video Bus: Close
+(II) UnloadModule: "evdev"
+(II) Sleep Button: Close
+(II) UnloadModule: "evdev"
+(II) AT Translated Set 2 keyboard: Close
+(II) UnloadModule: "evdev"
+(II) PS/2 Generic Mouse: Close
+(II) UnloadModule: "evdev"
+(II) ThinkPad Extra Buttons: Close
+(II) UnloadModule: "evdev"
+(II) ACPI Virtual Keyboard Device: Close
+(II) UnloadModule: "evdev"
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat, Jun 21, 2014 at 10:29:01PM +0200, Pavel Machek wrote:
> Hi!
>
> I just test-booted 3.16-rc1, and background in X looked just wrong --
> very noticeable bands on the background gradient. I thought that maybe
> it is just my eyes, but I went back to older kernel, and background is
> ok now.
>
> I'm trying to figure out how to ask X what color depth it is using...?
>
> This is thinkpad x60 with Debian 6.0.9.
>
> Any ideas?
That suggests that the panel dithering changed. Compare intel_reg_dumper
output for both kernels, especially PIPE.CONF.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Am Samstag, 21. Juni 2014, 22:29:01 schrieb Pavel Machek:
> Hi!
>
> I just test-booted 3.16-rc1, and background in X looked just wrong --
> very noticeable bands on the background gradient. I thought that maybe
> it is just my eyes, but I went back to older kernel, and background is
> ok now.
>
> I'm trying to figure out how to ask X what color depth it is using...?
I think:
martin@merkaba:~> xdpyinfo | grep -i "depth of root"
depth of root window: 24 planes
but am not completely sure.
> This is thinkpad x60 with Debian 6.0.9.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
On Sat 2014-06-21 22:06:52, Chris Wilson wrote:
> On Sat, Jun 21, 2014 at 10:29:01PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > I just test-booted 3.16-rc1, and background in X looked just wrong --
> > very noticeable bands on the background gradient. I thought that maybe
> > it is just my eyes, but I went back to older kernel, and background is
> > ok now.
> >
> > I'm trying to figure out how to ask X what color depth it is using...?
> >
> > This is thinkpad x60 with Debian 6.0.9.
> >
> > Any ideas?
>
> That suggests that the panel dithering changed. Compare intel_reg_dumper
> output for both kernels, especially PIPE.CONF.
Hmm, I tried:
root@duo:/sys/power# mount -t debugfs debugfs /sys/kernel/debug
root@duo:/sys/power# intel_gpu_dump
Error opening /sys/kernel/debug/dri/0/i915_ringbuffer_info: No such
file or directory
Perhaps your i915 kernel driver has no support for dumping batchbuffer
data?
(In kernels prior to 2.6.30 this requires manually-applied patches.)
root@duo:/sys/power# ls -al /sys/kernel/debug/dri/0/
bufs i915_gem_gtt i915_pc8_status
clients i915_gem_hws i915_pipe_A_crc
gem_names i915_gem_hws_blt i915_pipe_B_crc
i915_cache_sharing i915_gem_hws_bsd i915_pipe_C_crc
i915_capabilities i915_gem_hws_vebox
i915_power_domain_info
i915_context_status i915_gem_inactive i915_ppgtt_info
i915_cur_wm_latency i915_gem_interrupt
i915_pri_wm_latency
i915_delayfreq_table i915_gem_objects
i915_ring_freq_table
i915_display_crc_ctl i915_gem_pageflip
i915_ring_missed_irq
i915_display_info i915_gem_pinned i915_ring_stop
i915_drpc_info i915_gem_request
i915_ring_test_irq
i915_edp_psr_status i915_gem_seqno
i915_rstdby_delays
i915_emon_status i915_gem_stolen
i915_sink_crc_eDP1
i915_energy_uJ i915_gen6_forcewake_count
i915_spr_wm_latency
i915_error_state i915_gfxec i915_sr_status
i915_fbc_status i915_inttoext_table
i915_swizzle_info
i915_forcewake_user i915_ips_status i915_wedged
i915_frequency_info i915_llc name
i915_gem_active i915_max_freq vm
i915_gem_drop_caches i915_min_freq vma
i915_gem_fence_regs i915_next_seqno
i915_gem_framebuffer i915_opregion
root@duo:/sys/power# intel_gpu_dump --help
Error opening --help: No such file or directory
root@duo:/sys/power# hexdump /sys/kernel/debug/dri/0/i915_pipe_*_crc
hexdump: /sys/kernel/debug/dri/0/i915_pipe_C_crc: No such device
root@duo:/sys/power#
I also tried to download the git tree with intel_gpu_dump, but:
pavel@duo:~/g/intel-gpu-tools$ ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal ${ACLOCAL_FLAGS} -I m4
configure.ac:68: error: must install xorg-macros 1.16 or later before
running autoconf/autogen
configure.ac:68: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: /usr/bin/autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
pavel@duo:~/g/intel-gpu-tools$
Trying to bypass configure script:
pavel@duo:~/g/intel-gpu-tools/tools$ gcc -I ../lib intel_reg_dumper.c
2>&1 | less
In file included from ../lib/drmtest.h:37,
from intel_reg_dumper.c:39:
/usr/include/xf86drm.h:40:17: error: drm.h: No such file or directory
In file included from ../lib/drmtest.h:37,
from intel_reg_dumper.c:39:
/usr/include/xf86drm.h:268: error: expected specifier-qualifier-list
before ‘drm_context_t’
/usr/include/xf86drm.h:281: error: expected specifier-qualifier-list
before ‘drm_handle_t’
/usr/include/xf86drm.h:546: error: expected declaration specifiers or
‘...’ before ‘drm_magic_t’
Is there way to get required info manually?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > > I just test-booted 3.16-rc1, and background in X looked just wrong --
> > > very noticeable bands on the background gradient. I thought that maybe
> > > it is just my eyes, but I went back to older kernel, and background is
> > > ok now.
> > >
> > > I'm trying to figure out how to ask X what color depth it is using...?
> > >
> > > This is thinkpad x60 with Debian 6.0.9.
> > >
> > > Any ideas?
> >
> > That suggests that the panel dithering changed. Compare intel_reg_dumper
> > output for both kernels, especially PIPE.CONF.
intel_reg_dumper has so many dependencies that it is basically
impossible to get working :-(.
Anyway, this seems to be the problem; if I revert it, my colors are
back.
commit 773875bfb6737982903c42d1ee88cf60af80089c
Author: Daniel Vetter <[email protected]>
Date: Mon Jan 27 10:00:30 2014 +0100
drm/i915: Don't set the 8to6 dither flag when not scaling
Apparently we really only need this when the pfit is enabled, at
least
I couldn't dicern any difference here. Furthermore the hacks we
have
to reconstruct this bit is a bit glaring, and probably only works
because we can't move the lvds port to any other pipe than pipe B
on
gen2/3.
So let's just rip this out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77137 (the
LVDS
WARNING log, not the main "VGA can't be turned on" issue).
Signed-off-by: Daniel Vetter <[email protected]>
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon 2014-06-09 13:03:31, Jiri Kosina wrote:
> On Mon, 9 Jun 2014, Pavel Machek wrote:
>
> > > > Strange. It seems 3.15 with the patch reverted only boots in 30% or so
> > > > cases... And I've seen resume failure, too, so maybe I was just lucky
> > > > that it worked for a while.
> > >
> > > git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
> > > the 5th report or so that claims this is the culprit but it's
> > > something else. The above code is definitely not used in i915 so bogus
> > > bisect result.
> >
> > Note I did not do the bisect, I only attempted revert and test.
> >
> > And did three boots of successful s2ram.. only to find out that it
> > does not really fix s2ram, I was just lucky :-(.
> >
> > Unfortunately, this means my s2ram problem will be tricky/impossible
> > to bisect :-(.
>
> Welcome to the situation I have been in for past several months.
Ok, so I have set up machines for ktest / autobisect, and found out that 3.16-rc1 no
longer has that problem. Oh well, bisect would not be fun, anyway...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, 26 Jun 2014, Pavel Machek wrote:
> Ok, so I have set up machines for ktest / autobisect, and found out that
> 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun,
> anyway...
I am still seeing the problem with 3.16-rc2.
--
Jiri Kosina
SUSE Labs
On Fri, Jun 27, 2014 at 03:37:16PM +0200, Jiri Kosina wrote:
> On Thu, 26 Jun 2014, Pavel Machek wrote:
>
> > Ok, so I have set up machines for ktest / autobisect, and found out that
> > 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun,
> > anyway...
>
> I am still seeing the problem with 3.16-rc2.
I'm confused now. Is the bisect result
commit 773875bfb6737982903c42d1ee88cf60af80089c
Author: Daniel Vetter <[email protected]>
Date: Mon Jan 27 10:00:30 2014 +0100
drm/i915: Don't set the 8to6 dither flag when not scaling
now the culprit or not? Or do we have 2 different bugs at hand here?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon 2014-07-07 10:39:08, Daniel Vetter wrote:
> On Fri, Jun 27, 2014 at 03:37:16PM +0200, Jiri Kosina wrote:
> > On Thu, 26 Jun 2014, Pavel Machek wrote:
> >
> > > Ok, so I have set up machines for ktest / autobisect, and found out that
> > > 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun,
> > > anyway...
> >
> > I am still seeing the problem with 3.16-rc2.
>
> I'm confused now. Is the bisect result
>
> commit 773875bfb6737982903c42d1ee88cf60af80089c
> Author: Daniel Vetter <[email protected]>
> Date: Mon Jan 27 10:00:30 2014 +0100
>
> drm/i915: Don't set the 8to6 dither flag when not scaling
>
> now the culprit or not? Or do we have 2 different bugs at hand here?
Three different issues, it seems. Two ring initialization problems,
one went away in 3.16 (for me), second did not (suspend for jikos),
third -- trivial issue with 8to6 dither.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, 11 Jul 2014, Pavel Machek wrote:
> > > > Ok, so I have set up machines for ktest / autobisect, and found out that
> > > > 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun,
> > > > anyway...
> > >
> > > I am still seeing the problem with 3.16-rc2.
> >
> > I'm confused now. Is the bisect result
> >
> > commit 773875bfb6737982903c42d1ee88cf60af80089c
> > Author: Daniel Vetter <[email protected]>
> > Date: Mon Jan 27 10:00:30 2014 +0100
> >
> > drm/i915: Don't set the 8to6 dither flag when not scaling
> >
> > now the culprit or not? Or do we have 2 different bugs at hand here?
>
> Three different issues, it seems. Two ring initialization problems,
> one went away in 3.16 (for me), second did not (suspend for jikos),
> third -- trivial issue with 8to6 dither.
That's correct assesment.
The ring initialization failure I reported is still there.
--
Jiri Kosina
SUSE Labs