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

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

i951 Xv playback uneven

Hi, with the drm-intel-nightly I am currently running, I am also seeing some quite noticable stuttering in Xv playback. It's particularly obvious in stuff like rolling credits. It's not directly a performance problem, as the effect can be seen even in "stop motion" (i.e., frame by frame) playback:

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

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: [...] pin

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

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:i

Re: blank screen on boot with i915/DRM_FBDEV_EMULATION

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

blank screen on boot with i915/DRM_FBDEV_EMULATION

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 wi

Re: [PATCH v2] vlan: don't deliver frames for unknown vlans to protocols

Hi, > But I wonder if it breaks things, since you do the assignment so late > we no longer handle the case where the VLAN device's MAC address > matches the packet MAC address and the top-level device's does not. > > That's handled by logic in vlan_do_receive() which checks for > PACKET_OTHERHOST

[PATCH v2] vlan: don't deliver frames for unknown vlans to protocols

t. Signed-off-by: Florian Zumbiehl --- NOTE: This was tested on 3.5.4, but massaged to apply on a recent stable head--in any case this should be carefully reviewed by someone who knows the code well, in case that wasn't obvious anyhow. This version completely avoids any new state that c

[PATCH] vlan: don't deliver frames for unknown vlans to protocols

t. Signed-off-by: Florian Zumbiehl --- NOTE: This was tested on 3.5.4, but massaged to apply on a recent stable head--in any case this should be carefully reviewed by someone who knows the code well, in case that wasn't obvious anyhow. diff --git a/include/linux/if_vlan.h b/include/linux/

[PATCH] drm/savage: re-add busmaster enable, regression fix

466e69b8b03b8c1987367912782bc12988ad8794 dropped busmaster enable from the global drm code and moved it to the individual drivers, but missed the savage driver. So, this re-adds busmaster enable to the savage driver, fixing the regression. Signed-off-by: Florian Zumbiehl diff --git a/drivers