blank screen on boot with i915/DRM_FBDEV_EMULATION

blank screen on boot with i915/DRM_FBDEV_EMULATION

[Florian Zumbiehl]

Hi,

I just compiled a new kernel version 4.4.5, replacing a previous 4.1.9 for
my thinkpad x40, which replaced CONFIG_DRM_I915_FBDEV with
CONFIG_DRM_FBDEV_EMULATION--now, when the i915 and fbcon modules get loaded
during boot, the screen goes blank (with backlight still on), which didn't
happen with the old kernel.

The funny thing is that starting an X server makes text reappear on the
console!? (And the X server also works just fine, as far as I can tell so
far ...)

i915 is loaded with modeset=1 (I remember I had some problem without it
with some earlier kernels, I don't really remember the details anymore
...).

Any hints what to try? Any further information that could be useful?

Regards, Florian

Re: blank screen on boot with i915/DRM_FBDEV_EMULATION

[Daniel Vetter]

On Sat, Mar 26, 2016 at 12:21:23PM +0100, Florian Zumbiehl wrote:
> Hi,
> 
> I just compiled a new kernel version 4.4.5, replacing a previous 4.1.9 for
> my thinkpad x40, which replaced CONFIG_DRM_I915_FBDEV with
> CONFIG_DRM_FBDEV_EMULATION--now, when the i915 and fbcon modules get loaded
> during boot, the screen goes blank (with backlight still on), which didn't
> happen with the old kernel.
> 
> The funny thing is that starting an X server makes text reappear on the
> console!? (And the X server also works just fine, as far as I can tell so
> far ...)
> 
> i915 is loaded with modeset=1 (I remember I had some problem without it
> with some earlier kernels, I don't really remember the details anymore
> ...).
> 
> Any hints what to try? Any further information that could be useful?

FBDEV_EMULATION vs. I915_FBDEV is probably a read herring, more likely is
that for some odd reason the very first modeset fails. Once X has
resurrect the screen, can you then switch to fbcon? Also please check in
/sys/class/vtconsole whether the fbdev driver is loaded and bound (check
the name and bind files). And make sure there's that dmesg still says it
initialized the "inteldrmfb" driver.

If that all indicates fbcon is running properly, then it's time to bisect
what exactly broke the initial modeset for your system.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: blank screen on boot with i915/DRM_FBDEV_EMULATION

[Daniel Vetter]

On Sat, Mar 26, 2016 at 12:21:23PM +0100, Florian Zumbiehl wrote:
> Hi,
> 
> I just compiled a new kernel version 4.4.5, replacing a previous 4.1.9 for
> my thinkpad x40, which replaced CONFIG_DRM_I915_FBDEV with
> CONFIG_DRM_FBDEV_EMULATION--now, when the i915 and fbcon modules get loaded
> during boot, the screen goes blank (with backlight still on), which didn't
> happen with the old kernel.
> 
> The funny thing is that starting an X server makes text reappear on the
> console!? (And the X server also works just fine, as far as I can tell so
> far ...)
> 
> i915 is loaded with modeset=1 (I remember I had some problem without it
> with some earlier kernels, I don't really remember the details anymore
> ...).
> 
> Any hints what to try? Any further information that could be useful?

FBDEV_EMULATION vs. I915_FBDEV is probably a read herring, more likely is
that for some odd reason the very first modeset fails. Once X has
resurrect the screen, can you then switch to fbcon? Also please check in
/sys/class/vtconsole whether the fbdev driver is loaded and bound (check
the name and bind files). And make sure there's that dmesg still says it
initialized the "inteldrmfb" driver.

If that all indicates fbcon is running properly, then it's time to bisect
what exactly broke the initial modeset for your system.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: blank screen on boot with i915/DRM_FBDEV_EMULATION

[Florian Zumbiehl]

Hi,

> FBDEV_EMULATION vs. I915_FBDEV is probably a read herring, more likely is
> that for some odd reason the very first modeset fails. Once X has
> resurrect the screen, can you then switch to fbcon? Also please check in
> /sys/class/vtconsole whether the fbdev driver is loaded and bound (check
> the name and bind files). And make sure there's that dmesg still says it
> initialized the "inteldrmfb" driver.

Trying to collect that information actually solved the problem: fbcon
didn't actually get loaded during boot, only the graphics drivers, which
caused the screen to go blank, loading fbcon happened only when starting
the X server ... seems weird to me, but I guess there is some non-obvious
logic behind that, and in any case it seems to be a change in behaviour.
Well, thanks for the pointer anyway, I guess! ;-)

Now, while at it: I also have a bunch of WARN_ONs and ERRORs happening (the
former primarily when an Xv window disappears from the screen, it seems,
the latter primarily during boot), which don't seem to have any immediate
negative effects at the surface, like this:

| [   14.815467] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
| [   14.815642] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe B underrun
| [   14.815806] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
| [   14.823686] [drm] initialized overlay support
| [   14.873165] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

| [ 2520.457732] WARNING: CPU: 0 PID: 3193 at drivers/gpu/drm/i915/i915_gem.c:4508 i915_gem_free_object+0x277/0x280 [i915]()
| [ 2520.457736] WARN_ON(obj->frontbuffer_bits)

Also, I have occasional X server crashes (every few weeks or so) which
started with 4.1.9, I think (I had 3.11.0 before that), and I had some kind
of problem with Xv not working anymore until reboot with 4.1.9 which hasn't
happened with 4.4.5 yet ... do you think any of those would be worth
further investigation? If so, any suggestions as to how to split it all
into separate issues/how to go about it?

Regards, Florian

Re: blank screen on boot with i915/DRM_FBDEV_EMULATION

[Florian Zumbiehl]

Hi,

> FBDEV_EMULATION vs. I915_FBDEV is probably a read herring, more likely is
> that for some odd reason the very first modeset fails. Once X has
> resurrect the screen, can you then switch to fbcon? Also please check in
> /sys/class/vtconsole whether the fbdev driver is loaded and bound (check
> the name and bind files). And make sure there's that dmesg still says it
> initialized the "inteldrmfb" driver.

Trying to collect that information actually solved the problem: fbcon
didn't actually get loaded during boot, only the graphics drivers, which
caused the screen to go blank, loading fbcon happened only when starting
the X server ... seems weird to me, but I guess there is some non-obvious
logic behind that, and in any case it seems to be a change in behaviour.
Well, thanks for the pointer anyway, I guess! ;-)

Now, while at it: I also have a bunch of WARN_ONs and ERRORs happening (the
former primarily when an Xv window disappears from the screen, it seems,
the latter primarily during boot), which don't seem to have any immediate
negative effects at the surface, like this:

| [   14.815467] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
| [   14.815642] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe B underrun
| [   14.815806] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
| [   14.823686] [drm] initialized overlay support
| [   14.873165] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

| [ 2520.457732] WARNING: CPU: 0 PID: 3193 at drivers/gpu/drm/i915/i915_gem.c:4508 i915_gem_free_object+0x277/0x280 [i915]()
| [ 2520.457736] WARN_ON(obj->frontbuffer_bits)

Also, I have occasional X server crashes (every few weeks or so) which
started with 4.1.9, I think (I had 3.11.0 before that), and I had some kind
of problem with Xv not working anymore until reboot with 4.1.9 which hasn't
happened with 4.4.5 yet ... do you think any of those would be worth
further investigation? If so, any suggestions as to how to split it all
into separate issues/how to go about it?

Regards, Florian
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] blank screen on boot with i915/DRM_FBDEV_EMULATION

[Daniel Vetter]

On Tue, Mar 29, 2016 at 06:44:57PM +0200, Florian Zumbiehl wrote:
> Hi,
> 
> > FBDEV_EMULATION vs. I915_FBDEV is probably a read herring, more likely is
> > that for some odd reason the very first modeset fails. Once X has
> > resurrect the screen, can you then switch to fbcon? Also please check in
> > /sys/class/vtconsole whether the fbdev driver is loaded and bound (check
> > the name and bind files). And make sure there's that dmesg still says it
> > initialized the "inteldrmfb" driver.
> 
> Trying to collect that information actually solved the problem: fbcon
> didn't actually get loaded during boot, only the graphics drivers, which
> caused the screen to go blank, loading fbcon happened only when starting
> the X server ... seems weird to me, but I guess there is some non-obvious
> logic behind that, and in any case it seems to be a change in behaviour.
> Well, thanks for the pointer anyway, I guess! ;-)
> 
> Now, while at it: I also have a bunch of WARN_ONs and ERRORs happening (the
> former primarily when an Xv window disappears from the screen, it seems,
> the latter primarily during boot), which don't seem to have any immediate
> negative effects at the surface, like this:
> 
> | [   14.815467] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> | [   14.815642] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe B underrun
> | [   14.815806] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> | [   14.823686] [drm] initialized overlay support
> | [   14.873165] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

We've fixed piles of those in recent kernels, but didn't backport all the
fixes (since usually it's a silent failure, but it can correlate with
black screens).
 
> | [ 2520.457732] WARNING: CPU: 0 PID: 3193 at drivers/gpu/drm/i915/i915_gem.c:4508 i915_gem_free_object+0x277/0x280 [i915]()
> | [ 2520.457736] WARN_ON(obj->frontbuffer_bits)

Hm, this one should be fixed, and the patches should all be correctly
marked for stable. Either there's a backlog somewhere, or we failed.

Would be great if you can test a drm-intel-nightly build (or 4.6-rc1) for
either and confirm that they're gone. And for the later we really should
hunt down the bugfix if it's stuck.

> Also, I have occasional X server crashes (every few weeks or so) which
> started with 4.1.9, I think (I had 3.11.0 before that), and I had some kind
> of problem with Xv not working anymore until reboot with 4.1.9 which hasn't
> happened with 4.4.5 yet ... do you think any of those would be worth
> further investigation? If so, any suggestions as to how to split it all
> into separate issues/how to go about it?

No idea about X stuff, not my expertise ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: blank screen on boot with i915/DRM_FBDEV_EMULATION

[Daniel Vetter]

On Tue, Mar 29, 2016 at 06:44:57PM +0200, Florian Zumbiehl wrote:
> Hi,
> 
> > FBDEV_EMULATION vs. I915_FBDEV is probably a read herring, more likely is
> > that for some odd reason the very first modeset fails. Once X has
> > resurrect the screen, can you then switch to fbcon? Also please check in
> > /sys/class/vtconsole whether the fbdev driver is loaded and bound (check
> > the name and bind files). And make sure there's that dmesg still says it
> > initialized the "inteldrmfb" driver.
> 
> Trying to collect that information actually solved the problem: fbcon
> didn't actually get loaded during boot, only the graphics drivers, which
> caused the screen to go blank, loading fbcon happened only when starting
> the X server ... seems weird to me, but I guess there is some non-obvious
> logic behind that, and in any case it seems to be a change in behaviour.
> Well, thanks for the pointer anyway, I guess! ;-)
> 
> Now, while at it: I also have a bunch of WARN_ONs and ERRORs happening (the
> former primarily when an Xv window disappears from the screen, it seems,
> the latter primarily during boot), which don't seem to have any immediate
> negative effects at the surface, like this:
> 
> | [   14.815467] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> | [   14.815642] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe B underrun
> | [   14.815806] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> | [   14.823686] [drm] initialized overlay support
> | [   14.873165] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

We've fixed piles of those in recent kernels, but didn't backport all the
fixes (since usually it's a silent failure, but it can correlate with
black screens).
 
> | [ 2520.457732] WARNING: CPU: 0 PID: 3193 at drivers/gpu/drm/i915/i915_gem.c:4508 i915_gem_free_object+0x277/0x280 [i915]()
> | [ 2520.457736] WARN_ON(obj->frontbuffer_bits)

Hm, this one should be fixed, and the patches should all be correctly
marked for stable. Either there's a backlog somewhere, or we failed.

Would be great if you can test a drm-intel-nightly build (or 4.6-rc1) for
either and confirm that they're gone. And for the later we really should
hunt down the bugfix if it's stuck.

> Also, I have occasional X server crashes (every few weeks or so) which
> started with 4.1.9, I think (I had 3.11.0 before that), and I had some kind
> of problem with Xv not working anymore until reboot with 4.1.9 which hasn't
> happened with 4.4.5 yet ... do you think any of those would be worth
> further investigation? If so, any suggestions as to how to split it all
> into separate issues/how to go about it?

No idea about X stuff, not my expertise ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Florian Zumbiehl]

Hi,

> We've fixed piles of those in recent kernels, but didn't backport all the
> fixes (since usually it's a silent failure, but it can correlate with
> black screens).

Not quite completely, it seems ...

I have built drm-intel-nightly (f261f82359), and I'm getting this:

| [   15.855007] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
| [   15.855007] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe B underrun
| [   15.855007] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
| [   15.863175] [drm] RC6 disabled, disabling runtime PM support
| [   15.863543] [drm] initialized overlay support
| [   15.933338] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
| [   15.997130] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
| [   16.061856] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
| [   16.725274] [drm] Initialized i915 1.6.0 20160330 for 0000:00:02.0 on minor 0
| [   16.805727] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

> > | [ 2520.457732] WARNING: CPU: 0 PID: 3193 at drivers/gpu/drm/i915/i915_gem.c:4508 i915_gem_free_object+0x277/0x280 [i915]()
> > | [ 2520.457736] WARN_ON(obj->frontbuffer_bits)
> 
> Hm, this one should be fixed, and the patches should all be correctly
> marked for stable. Either there's a backlog somewhere, or we failed.
> 
> Would be great if you can test a drm-intel-nightly build (or 4.6-rc1) for
> either and confirm that they're gone. And for the later we really should
> hunt down the bugfix if it's stuck.

| [  141.999803] ------------[ cut here ]------------
| [  141.999916] WARNING: CPU: 0 PID: 3349 at drivers/gpu/drm/i915/i915_gem.c:4568 i915_gem_free_object+0x25f/0x270 [i915]
| [  141.999923] WARN_ON(obj->frontbuffer_bits)
| [  141.999928] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_CT iptable_raw xt_nat xt_tcpudp xt_addrtype iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables dummy tun nfsd exportfs nfs lockd grace sunrpc ipv6 fbcon bitblit softcursor font loop mousedev i915 i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_intel8x0 drm snd_ac97_codec ac97_bus i2c_core snd_pcm_oss fb snd_mixer_oss fbdev snd_pcm ipw2200 snd_timer snd libipw soundcore lib80211 nsc_ircc thinkpad_acpi cfg80211 pcmcia psmouse sdhci_pci irda uhci_hcd ehci_pci sdhci crc_ccitt ehci_hcd serio_raw e1000 mmc_core nvram evdev usbcore parport_pc yenta_socket hwmon parport pcmcia_rsrc video usb_common pcmcia_core backlight ac battery acpi_cpufreq intel_agp processor button intel_gtt agpgart twofish_generic twofish_i586 twofish_common xts gf128mul dm_crypt dm_mod thermal
| [  142.000114] CPU: 0 PID: 3349 Comm: Xorg Not tainted 4.6.0-rc1+ #1
| [  142.000120] Hardware name: IBM 23716JG/23716JG, BIOS 1UETD3WW (2.08 ) 12/21/2006
| [  142.000127]  c11b8f7a c1037247 f8dea59b c0051dc4 00000d15 f8dda000 000011d8 f8d3ff2f
| [  142.000141]  f8d3ff2f 000011d8 f3ef1dcc f3ef1e30 f3ef1dcc f3ef1dc0 c1037309 00000009
| [  142.000154]  00000000 c0051dac f8dea59b c0051dc4 f8d3ff2f f8dda000 000011d8 f8dea59b
| [  142.000168] Call Trace:
| [  142.000185]  [<c11b8f7a>] ? dump_stack+0xa/0x20
| [  142.000197]  [<c1037247>] ? __warn+0xe7/0x100
| [  142.000269]  [<f8d3ff2f>] ? i915_gem_free_object+0x25f/0x270 [i915]
| [  142.000337]  [<f8d3ff2f>] ? i915_gem_free_object+0x25f/0x270 [i915]
| [  142.000347]  [<c1037309>] ? warn_slowpath_fmt+0x39/0x40
| [  142.000416]  [<f8d3ff2f>] ? i915_gem_free_object+0x25f/0x270 [i915]
| [  142.000452]  [<f892ed83>] ? drm_gem_object_free+0x23/0x40 [drm]
| [  142.000478]  [<f892f58f>] ? drm_gem_object_handle_unreference_unlocked+0xcf/0xe0 [drm]
| [  142.000504]  [<f892f5e7>] ? drm_gem_object_release_handle+0x47/0x90 [drm]
| [  142.000529]  [<f892f67e>] ? drm_gem_handle_delete+0x4e/0x80 [drm]
| [  142.000554]  [<f892f8d0>] ? drm_gem_handle_create+0x30/0x30 [drm]
| [  142.000580]  [<f89302c0>] ? drm_ioctl+0x230/0x570 [drm]
| [  142.000606]  [<f892f8d0>] ? drm_gem_handle_create+0x30/0x30 [drm]
| [  142.000618]  [<c10b34a3>] ? unmap_page_range+0x433/0x530
| [  142.000627]  [<c11be1c3>] ? __rb_erase_color+0xf3/0x250
| [  142.000637]  [<c10b7116>] ? unlink_file_vma+0x36/0x70
| [  142.000645]  [<c10b1db9>] ? tlb_finish_mmu+0x9/0x30
| [  142.000671]  [<f8930090>] ? drm_ioctl_permit+0x80/0x80 [drm]
| [  142.000682]  [<c10e7250>] ? do_vfs_ioctl+0x80/0x6a0
| [  142.000690]  [<c11bf570>] ? timerqueue_del+0x20/0x70
| [  142.000699]  [<c10cbde5>] ? kmem_cache_free+0x95/0xa0
| [  142.000708]  [<c10b6d0e>] ? remove_vma+0x3e/0x50
| [  142.000717]  [<c10b9019>] ? do_munmap+0x219/0x2d0
| [  142.000726]  [<c10e78b3>] ? SyS_ioctl+0x43/0x80
| [  142.000735]  [<c1001272>] ? do_fast_syscall_32+0x82/0x110
| [  142.000745]  [<c134644f>] ? sysenter_past_esp+0x40/0x6a
| [  142.000777] ---[ end trace c0ddddf77cdb5434 ]---

Each time an Xv window disappears from view--sometimes with slight
variations in the stacktrace. Do you need full debug info or a bunch more
stacktraces or is this enough to get an idea?

> > Also, I have occasional X server crashes (every few weeks or so) which
> > started with 4.1.9, I think (I had 3.11.0 before that), and I had some kind
> > of problem with Xv not working anymore until reboot with 4.1.9 which hasn't
> > happened with 4.4.5 yet ... do you think any of those would be worth
> > further investigation? If so, any suggestions as to how to split it all
> > into separate issues/how to go about it?
> 
> No idea about X stuff, not my expertise ;-)

Well, I would guess that something that persists until reboot smells like a
kernel/driver bug? Also, IIRC, there was no (major) X server upgrade
between 3.11.0 and 4.1.9, so chances are that's a kernel/driver bug as well
;-)

Regards, Florian

i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Florian Zumbiehl]

Hi,

> We've fixed piles of those in recent kernels, but didn't backport all the
> fixes (since usually it's a silent failure, but it can correlate with
> black screens).

Not quite completely, it seems ...

I have built drm-intel-nightly (f261f82359), and I'm getting this:

| [   15.855007] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
| [   15.855007] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe B underrun
| [   15.855007] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
| [   15.863175] [drm] RC6 disabled, disabling runtime PM support
| [   15.863543] [drm] initialized overlay support
| [   15.933338] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
| [   15.997130] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
| [   16.061856] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
| [   16.725274] [drm] Initialized i915 1.6.0 20160330 for 0000:00:02.0 on minor 0
| [   16.805727] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

> > | [ 2520.457732] WARNING: CPU: 0 PID: 3193 at drivers/gpu/drm/i915/i915_gem.c:4508 i915_gem_free_object+0x277/0x280 [i915]()
> > | [ 2520.457736] WARN_ON(obj->frontbuffer_bits)
> 
> Hm, this one should be fixed, and the patches should all be correctly
> marked for stable. Either there's a backlog somewhere, or we failed.
> 
> Would be great if you can test a drm-intel-nightly build (or 4.6-rc1) for
> either and confirm that they're gone. And for the later we really should
> hunt down the bugfix if it's stuck.

| [  141.999803] ------------[ cut here ]------------
| [  141.999916] WARNING: CPU: 0 PID: 3349 at drivers/gpu/drm/i915/i915_gem.c:4568 i915_gem_free_object+0x25f/0x270 [i915]
| [  141.999923] WARN_ON(obj->frontbuffer_bits)
| [  141.999928] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_CT iptable_raw xt_nat xt_tcpudp xt_addrtype iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables dummy tun nfsd exportfs nfs lockd grace sunrpc ipv6 fbcon bitblit softcursor font loop mousedev i915 i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_intel8x0 drm snd_ac97_codec ac97_bus i2c_core snd_pcm_oss fb snd_mixer_oss fbdev snd_pcm ipw2200 snd_timer snd libipw soundcore lib80211 nsc_ircc thinkpad_acpi cfg80211 pcmcia psmouse sdhci_pci irda uhci_hcd ehci_pci sdhci crc_ccitt ehci_hcd serio_raw e1000 mmc_core nvram evdev usbcore parport_pc yenta_socket hwmon parport pcmcia_rsrc video usb_common pcmcia_core backlight ac battery acpi_cpufreq intel_agp processor button intel_gtt agpgart twofish_generic twofish_i586 twofish_common xts gf128mul dm_crypt dm_mod thermal
| [  142.000114] CPU: 0 PID: 3349 Comm: Xorg Not tainted 4.6.0-rc1+ #1
| [  142.000120] Hardware name: IBM 23716JG/23716JG, BIOS 1UETD3WW (2.08 ) 12/21/2006
| [  142.000127]  c11b8f7a c1037247 f8dea59b c0051dc4 00000d15 f8dda000 000011d8 f8d3ff2f
| [  142.000141]  f8d3ff2f 000011d8 f3ef1dcc f3ef1e30 f3ef1dcc f3ef1dc0 c1037309 00000009
| [  142.000154]  00000000 c0051dac f8dea59b c0051dc4 f8d3ff2f f8dda000 000011d8 f8dea59b
| [  142.000168] Call Trace:
| [  142.000185]  [<c11b8f7a>] ? dump_stack+0xa/0x20
| [  142.000197]  [<c1037247>] ? __warn+0xe7/0x100
| [  142.000269]  [<f8d3ff2f>] ? i915_gem_free_object+0x25f/0x270 [i915]
| [  142.000337]  [<f8d3ff2f>] ? i915_gem_free_object+0x25f/0x270 [i915]
| [  142.000347]  [<c1037309>] ? warn_slowpath_fmt+0x39/0x40
| [  142.000416]  [<f8d3ff2f>] ? i915_gem_free_object+0x25f/0x270 [i915]
| [  142.000452]  [<f892ed83>] ? drm_gem_object_free+0x23/0x40 [drm]
| [  142.000478]  [<f892f58f>] ? drm_gem_object_handle_unreference_unlocked+0xcf/0xe0 [drm]
| [  142.000504]  [<f892f5e7>] ? drm_gem_object_release_handle+0x47/0x90 [drm]
| [  142.000529]  [<f892f67e>] ? drm_gem_handle_delete+0x4e/0x80 [drm]
| [  142.000554]  [<f892f8d0>] ? drm_gem_handle_create+0x30/0x30 [drm]
| [  142.000580]  [<f89302c0>] ? drm_ioctl+0x230/0x570 [drm]
| [  142.000606]  [<f892f8d0>] ? drm_gem_handle_create+0x30/0x30 [drm]
| [  142.000618]  [<c10b34a3>] ? unmap_page_range+0x433/0x530
| [  142.000627]  [<c11be1c3>] ? __rb_erase_color+0xf3/0x250
| [  142.000637]  [<c10b7116>] ? unlink_file_vma+0x36/0x70
| [  142.000645]  [<c10b1db9>] ? tlb_finish_mmu+0x9/0x30
| [  142.000671]  [<f8930090>] ? drm_ioctl_permit+0x80/0x80 [drm]
| [  142.000682]  [<c10e7250>] ? do_vfs_ioctl+0x80/0x6a0
| [  142.000690]  [<c11bf570>] ? timerqueue_del+0x20/0x70
| [  142.000699]  [<c10cbde5>] ? kmem_cache_free+0x95/0xa0
| [  142.000708]  [<c10b6d0e>] ? remove_vma+0x3e/0x50
| [  142.000717]  [<c10b9019>] ? do_munmap+0x219/0x2d0
| [  142.000726]  [<c10e78b3>] ? SyS_ioctl+0x43/0x80
| [  142.000735]  [<c1001272>] ? do_fast_syscall_32+0x82/0x110
| [  142.000745]  [<c134644f>] ? sysenter_past_esp+0x40/0x6a
| [  142.000777] ---[ end trace c0ddddf77cdb5434 ]---

Each time an Xv window disappears from view--sometimes with slight
variations in the stacktrace. Do you need full debug info or a bunch more
stacktraces or is this enough to get an idea?

> > Also, I have occasional X server crashes (every few weeks or so) which
> > started with 4.1.9, I think (I had 3.11.0 before that), and I had some kind
> > of problem with Xv not working anymore until reboot with 4.1.9 which hasn't
> > happened with 4.4.5 yet ... do you think any of those would be worth
> > further investigation? If so, any suggestions as to how to split it all
> > into separate issues/how to go about it?
> 
> No idea about X stuff, not my expertise ;-)

Well, I would guess that something that persists until reboot smells like a
kernel/driver bug? Also, IIRC, there was no (major) X server upgrade
between 3.11.0 and 4.1.9, so chances are that's a kernel/driver bug as well
;-)

Regards, Florian
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Florian Zumbiehl]

Hi,

> > We've fixed piles of those in recent kernels, but didn't backport all the
> > fixes (since usually it's a silent failure, but it can correlate with
> > black screens).
> 
> Not quite completely, it seems ...
> 
> I have built drm-intel-nightly (f261f82359), and I'm getting this:
[...]

ping?

Regards, Florian

Re: i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Florian Zumbiehl]

Hi,

> > We've fixed piles of those in recent kernels, but didn't backport all the
> > fixes (since usually it's a silent failure, but it can correlate with
> > black screens).
> 
> Not quite completely, it seems ...
> 
> I have built drm-intel-nightly (f261f82359), and I'm getting this:
[...]

ping?

Regards, Florian
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Marius Vlad]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

Florian, if you're using drm-intel-nigthly submit a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI, with DRM/intel
as component. This way we can track some kind of progress/regress. The FIFO
underruns should've have been fixed, but maybe there's something related
to your platform.

On Tue, Apr 12, 2016 at 03:23:08AM +0200, Florian Zumbiehl wrote:
> Hi,
> 
> > > We've fixed piles of those in recent kernels, but didn't backport all the
> > > fixes (since usually it's a silent failure, but it can correlate with
> > > black screens).
> > 
> > Not quite completely, it seems ...
> > 
> > I have built drm-intel-nightly (f261f82359), and I'm getting this:
> [...]
> 
> ping?
> 
> Regards, Florian
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Marius Vlad]

[-- Attachment #1.1: Type: text/plain, Size: 905 bytes --]

Florian, if you're using drm-intel-nigthly submit a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI, with DRM/intel
as component. This way we can track some kind of progress/regress. The FIFO
underruns should've have been fixed, but maybe there's something related
to your platform.

On Tue, Apr 12, 2016 at 03:23:08AM +0200, Florian Zumbiehl wrote:
> Hi,
> 
> > > We've fixed piles of those in recent kernels, but didn't backport all the
> > > fixes (since usually it's a silent failure, but it can correlate with
> > > black screens).
> > 
> > Not quite completely, it seems ...
> > 
> > I have built drm-intel-nightly (f261f82359), and I'm getting this:
> [...]
> 
> ping?
> 
> Regards, Florian
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Florian Zumbiehl]

Hi,

> Florian, if you're using drm-intel-nigthly submit a bug at
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI, with DRM/intel
> as component. This way we can track some kind of progress/regress. The FIFO

Gee ... is there any way without "creating an account"? Having to create
accounts everywhere to be able to communicate with people just sucks. I
mean, do you want to create an account in my todo tracker and use my todo
tracker's web interface to coordinate the bug investigation? Use whatever
software you like for managing your todo lists, but please, don't bother me
with having to use it for you.

> underruns should've have been fixed, but maybe there's something related
> to your platform.

You mean the ones I reported a month ago should be fixed? Should I try a
newer nightly to check?

What about the Xv stuttering?

Regards, Florian

Re: i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Jani Nikula]

On Wed, 27 Apr 2016, Florian Zumbiehl <florz@florz.de> wrote:
>> Florian, if you're using drm-intel-nigthly submit a bug at
>> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI, with DRM/intel
>> as component. This way we can track some kind of progress/regress. The FIFO
>
> Gee ... is there any way without "creating an account"? Having to create
> accounts everywhere to be able to communicate with people just sucks. I
> mean, do you want to create an account in my todo tracker and use my todo
> tracker's web interface to coordinate the bug investigation? Use whatever
> software you like for managing your todo lists, but please, don't bother me
> with having to use it for you.

The Bugzilla at https://bugs.freedesktop.org is our tool of choice for
tracking bugs in drm/i915. It's your choice to not create an account
there, but please, don't expect us to work as a proxy between you and
bugzilla either. It's a much bigger and unscalable inconvenience for us
than it is for you to create that account.

I won't claim your bug will be fixed any faster if you choose to create
an account, but it's much more likely it won't get lost and forgotten in
the never ending stream of emails we all get.

> You mean the ones I reported a month ago should be fixed? Should I try a
> newer nightly to check?

Yes, please.

I'd also like to get a full dmesg from you, with drm.debug=14 module
parameter set, all the way from boot to the problem.

However, personally I find it a bit obnoxious to send big logs by mail
to hundreds or thousands of other people on the lists who really aren't
at all interested in them. Maybe you don't mind bothering them? It's
also not good to hide it away in my private inbox alone, because there
are other developers who will be interested. It has also proven to be
problematic to upload files to pastebins etc. where they expire at some
point in time, usually when we'd like to have a look.

Again, the obvious solution to the above is to file that bug and attach
the dmesg there, at the unfortunate slight inconvenience of you creating
an account there.

Your call.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: i915 ERRORs and WARN_ON()s

[Florian Zumbiehl]

Hi,

> The Bugzilla at https://bugs.freedesktop.org is our tool of choice for
> tracking bugs in drm/i915. It's your choice to not create an account
> there, but please, don't expect us to work as a proxy between you and
> bugzilla either. It's a much bigger and unscalable inconvenience for us
> than it is for you to create that account.

Hu? I don't quite get it. Communicating via email is an unscalable
inconvenience? So, if I asked you to create an account with my todo tracker
instead, would that be more scalable and convenient? Using everyone's
software of choice instead of my own most certainly is neither scalable nor
convenient for me at all.

> > You mean the ones I reported a month ago should be fixed? Should I try a
> > newer nightly to check?
> 
> Yes, please.
> 
> I'd also like to get a full dmesg from you, with drm.debug=14 module
> parameter set, all the way from boot to the problem.

http://rain.dyn.florz.de/drm-intel-nightly_1101e5fcc_dmesg.txt

Doesn't look much different than the one from a month ago (except much more
verbose, obviously), unfortunately, and the Xv stuttering also persists.

> However, personally I find it a bit obnoxious to send big logs by mail
> to hundreds or thousands of other people on the lists who really aren't
> at all interested in them. Maybe you don't mind bothering them? It's
> also not good to hide it away in my private inbox alone, because there
> are other developers who will be interested. It has also proven to be
> problematic to upload files to pastebins etc. where they expire at some
> point in time, usually when we'd like to have a look.
> 
> Again, the obvious solution to the above is to file that bug and attach
> the dmesg there, at the unfortunate slight inconvenience of you creating
> an account there.

The obvious solution is to have a bug tracker that interfaces to email? I
mean, it's essentially a messaging system with per-thread group membership
(plus some management functionality that's mostly irrelevant to me), just
with its own account system and user interface instead of a standardized
SMTP interface so I can use the MUA of my choice. It's like if I were to
ask you to write replies to me into a web form I host somewhere instead of
using the reply function of your MUA, plus you'd first have to create an
account, of course.

Regards, Florian
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 ERRORs and WARN_ON()s

[David Weinehall]

On Fri, Apr 29, 2016 at 04:27:08AM +0200, Florian Zumbiehl wrote:
> Hi,
> 
> > The Bugzilla at https://bugs.freedesktop.org is our tool of choice for
> > tracking bugs in drm/i915. It's your choice to not create an account
> > there, but please, don't expect us to work as a proxy between you and
> > bugzilla either. It's a much bigger and unscalable inconvenience for us
> > than it is for you to create that account.
> 
> Hu? I don't quite get it. Communicating via email is an unscalable
> inconvenience? So, if I asked you to create an account with my todo tracker
> instead, would that be more scalable and convenient? Using everyone's
> software of choice instead of my own most certainly is neither scalable nor
> convenient for me at all.

I think you're missing the point here. First of all, your bug report
isn't the only bug report. If all bug reports were posted here rather
than reported in our bug tracker, it would definitely be more likely
that some bugs would get lost. It works for small projects with a low
influx of bug reports, but it's less convenient for larger projects.
This is the scalability factor.

Second of all, convenience. Your convenience, while of course a
consideration, isn't the primary concern. The convenience of the
developers is.  You're reporting one bug, but the developers here
have to keep track of, and fix, hundreds (and that's on top of
new features, support for new platforms, test cases, and performance
improvements).

If we were asking for support for software you develop, you'd obviously
be the one to set the rules (and yes, that includes your TODO tracker,
closed forums or what not). Reporting bugs in a bug tracking system
isn't exactly a novelty. Rather the opposite.


Kind regards, David Weinehall
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 ERRORs and WARN_ON()s

[Florian Zumbiehl]

Hi,

> > Hu? I don't quite get it. Communicating via email is an unscalable
> > inconvenience? So, if I asked you to create an account with my todo tracker
> > instead, would that be more scalable and convenient? Using everyone's
> > software of choice instead of my own most certainly is neither scalable nor
> > convenient for me at all.
> 
> I think you're missing the point here. First of all, your bug report
> isn't the only bug report. If all bug reports were posted here rather
> than reported in our bug tracker, it would definitely be more likely
> that some bugs would get lost. It works for small projects with a low
> influx of bug reports, but it's less convenient for larger projects.
> This is the scalability factor.

Did you actually read the email you are replying to completely? If you did,
you should know what I think a solution that's scalable and convenient for
both sides would look like, and that it does not consist of you filtering
bug reports from the mailing lists, so why are you arguing against a
position that I obviously don't hold?

> Second of all, convenience. Your convenience, while of course a
> consideration, isn't the primary concern. The convenience of the
> developers is.  You're reporting one bug, but the developers here
> have to keep track of, and fix, hundreds (and that's on top of
> new features, support for new platforms, test cases, and performance
> improvements).

What do you suppose I do all day long? I get up, report a bug to you, and
then twiddle my thumbs for the rest of the day? Believe it or not, but
reporting bugs to you and helping with the debugging isn't the only thing I
do either.

So, what your argument boils down to is, if I may paraphrase, "our time is
more valuable than your time, therefore, you should waste your time so we
don't have to waste ours" (ignoring the fact that you actually wouldn't
have to). I must say, I am not convinced.

> If we were asking for support for software you develop, you'd obviously
> be the one to set the rules (and yes, that includes your TODO tracker,

That's not actually how that works. While I am obviously free to set any
rules I like as to how I engage with people, those don't actually compel
anyone to obey them. Rather, people who have bugs to report are just as
free to set any rules they like as to how to engage with people, including
people they report bugs to. If the two sets of rules are not compatible,
the bug simply won't get reported/fixed.

> closed forums or what not). Reporting bugs in a bug tracking system
> isn't exactly a novelty. Rather the opposite.

As mentioned above, I explained in the email that you replied to that I
don't object to bug tracking systems, so that's kindof a straw man. But
also, against someone pointing out "That's inefficient and a bit unfair
because <...>!", "But that's how we've always done it!" isn't really a
useful argument, is it?

Regards, Florian
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: i915 ERRORs and WARN_ON()s

[Daniel Vetter]

Hi Florian,

I fully understand your frustration with all this - you have a bug and
it's annoying and creating bugzilla accounts all over the internet is
indeed not a good way to do things. Unfortunately bugzilla is the
standard, and we don't have the manpower to write our own, nor do the
freedesktop.org admins (who's infrastructure we're using, and who are
all volunteers) have time to transition to other systems.

Also we're positively flooded in bug reports and patch mails (100-200
mails/day on intel-gfx, probably 100 new bugs/months in bugzilla), and
we do expect reporters to e.g. be able to install from source, provide
logs and tons of other things. If creating an account is too much
work, then it's much better to file with someone else who takes care
of the triaging for you (distro or similar), or hire a contractor to
fix your problem for you (there are tons). Bug reports on the m-l that
aren't resolved immediately by pointing at an existing patch are
pretty much guaranteed to get lost.

Again, I fully understand your frustration, but please also take into
account the constraints on our side.

I expect that the technical discussion on the bug itself will continue
in bugzilla. And of course if you want to improve this, help with bug
triaging or anything else then that's very much welcome, but
complaining that there's not an endless supply of free labour that
makes everything work perfectly on both sides is not productive.

Thanks a lot,

Daniel, drm/i915 maintainer


On Sun, May 1, 2016 at 2:11 AM, Florian Zumbiehl <florz@florz.de> wrote:
> Hi,
>
>> > Hu? I don't quite get it. Communicating via email is an unscalable
>> > inconvenience? So, if I asked you to create an account with my todo tracker
>> > instead, would that be more scalable and convenient? Using everyone's
>> > software of choice instead of my own most certainly is neither scalable nor
>> > convenient for me at all.
>>
>> I think you're missing the point here. First of all, your bug report
>> isn't the only bug report. If all bug reports were posted here rather
>> than reported in our bug tracker, it would definitely be more likely
>> that some bugs would get lost. It works for small projects with a low
>> influx of bug reports, but it's less convenient for larger projects.
>> This is the scalability factor.
>
> Did you actually read the email you are replying to completely? If you did,
> you should know what I think a solution that's scalable and convenient for
> both sides would look like, and that it does not consist of you filtering
> bug reports from the mailing lists, so why are you arguing against a
> position that I obviously don't hold?
>
>> Second of all, convenience. Your convenience, while of course a
>> consideration, isn't the primary concern. The convenience of the
>> developers is.  You're reporting one bug, but the developers here
>> have to keep track of, and fix, hundreds (and that's on top of
>> new features, support for new platforms, test cases, and performance
>> improvements).
>
> What do you suppose I do all day long? I get up, report a bug to you, and
> then twiddle my thumbs for the rest of the day? Believe it or not, but
> reporting bugs to you and helping with the debugging isn't the only thing I
> do either.
>
> So, what your argument boils down to is, if I may paraphrase, "our time is
> more valuable than your time, therefore, you should waste your time so we
> don't have to waste ours" (ignoring the fact that you actually wouldn't
> have to). I must say, I am not convinced.
>
>> If we were asking for support for software you develop, you'd obviously
>> be the one to set the rules (and yes, that includes your TODO tracker,
>
> That's not actually how that works. While I am obviously free to set any
> rules I like as to how I engage with people, those don't actually compel
> anyone to obey them. Rather, people who have bugs to report are just as
> free to set any rules they like as to how to engage with people, including
> people they report bugs to. If the two sets of rules are not compatible,
> the bug simply won't get reported/fixed.
>
>> closed forums or what not). Reporting bugs in a bug tracking system
>> isn't exactly a novelty. Rather the opposite.
>
> As mentioned above, I explained in the email that you replied to that I
> don't object to bug tracking systems, so that's kindof a straw man. But
> also, against someone pointing out "That's inefficient and a bit unfair
> because <...>!", "But that's how we've always done it!" isn't really a
> useful argument, is it?
>
> Regards, Florian
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: i915 ERRORs and WARN_ON()s

[Florian Zumbiehl]

Hi,

> I fully understand your frustration with all this - you have a bug and
> it's annoying and creating bugzilla accounts all over the internet is
> indeed not a good way to do things. Unfortunately bugzilla is the
> standard, and we don't have the manpower to write our own, nor do the
> freedesktop.org admins (who's infrastructure we're using, and who are
> all volunteers) have time to transition to other systems.

I mean, no clue about the funding situation, but how about Intel throwing
some money at this?

> Also we're positively flooded in bug reports and patch mails (100-200
> mails/day on intel-gfx, probably 100 new bugs/months in bugzilla), and
> we do expect reporters to e.g. be able to install from source, provide
> logs and tons of other things. If creating an account is too much
> work, then it's much better to file with someone else who takes care
> of the triaging for you (distro or similar), or hire a contractor to
> fix your problem for you (there are tons). Bug reports on the m-l that
> aren't resolved immediately by pointing at an existing patch are
> pretty much guaranteed to get lost.
> 
> Again, I fully understand your frustration, but please also take into
> account the constraints on our side.

Well, you asked that I try the nightly tree because you thought that bug
should be fixed. So I did, not knowing what I was signing up for. I guess
I'll just forget about it then.

> I expect that the technical discussion on the bug itself will continue
> in bugzilla. And of course if you want to improve this, help with bug
> triaging or anything else then that's very much welcome, but
> complaining that there's not an endless supply of free labour that
> makes everything work perfectly on both sides is not productive.

I'm more getting the impression that it's systematically broken with no
incentive to fix it as it's somebody else's problem?

Regards, Florian
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx