It's a day early, but tomorrow ends up being inconvenient for me due
to being on the road most of the day, so here you are. These days most
people send me their pull requests and patches during the week, so
it's not like I expect that a Sunday release would have made much of a
difference. And it's also not like I didn't have enough changes for
making a rc2 release.
Anyway, enough excuses. 3.16-rc2 is out, and contains the usual
assortment of fixes all over the map. The most unusual part at this
point is how the sparc changes stand out (at almost 40% of the patch
by bulk), but they are basically all just sparse warning cleanups.
Similarly, some Nouveau drm changes standing out size-wise, but again
those are largely due to small firmware fixes resulting in big
generated changes. The actual real changes are fairly small.
Ignoring those two unusually large changes (in lines), everything else
looks fairly normal. There are driver changes, some tooling updates
(particularly perf), and various other arch updates (arm, s390,
unicore32, x86..). And just misc random stuff all over the place -
rtmutex, btrfs, yadda yadda.
The shortlog is not tiny, but small enough to include here, so you can
see the details there if you care.
Please do go test it out,
Linus
---
Aaron Plattner (1):
cpufreq: unlock when failing cpufreq_update_policy()
Alan Stern (2):
USB: EHCI: avoid BIOS handover on the HASEE E200
USB: usbtest: add a timeout for scatter-gather tests
Alex Deucher (2):
drm/radeon: update mode_valid testing for DP
drm/radeon: improve dvi_mode_valid
Alexander Gordeev (3):
blk-mq: bitmap tag: fix races on shared ::wake_index fields
blk-mq: bitmap tag: fix race on blk_mq_bitmap_tags::wake_cnt
blk-mq: bitmap tag: fix races in bt_get() function
Alexander Mezin (2):
ACPI / battery: use callback for setting up quirks
ACPI / battery: add quirk for Acer Aspire V5-573G
Alexander Shiyan (1):
w1: mxc_w1: Fix incorrect "presence" status
Anssi Hannula (1):
ASoC: fsl_spdif: Fix integer overflow when calculating divisors
Archana Patni (1):
iio: hid-sensors: Get feature report from sensor hub after
changing power state
Ard Biesheuvel (2):
arm64/crypto: fix data corruption bug in GHASH algorithm
arm64/crypto: improve performance of GHASH algorithm
Arnaldo Carvalho de Melo (2):
perf tools: Emit more precise message for missing glibc static library
perf tests: Show the inner make output when an error happens
Arnd Bergmann (11):
ASoC: pxa: add I2C dependencies as needed
regulator: add regulator_can_change_voltage stub
ASoC: MMP audio needs sram support
staging/iio: IIO_SIMPLE_DUMMY_BUFFER neds IIO_BUFFER
cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependency
ARM: omap2: fix am43xx dependency on l2x0 cache
ARM: keystone requires ARM_PATCH_PHYS_VIRT
bus/arm-cci: add dependency on OF && CPU_V7
remoteproc: da8xx: don't select CMA on no-MMU
ARM: samsung: make SAMSUNG_DMADEV optional
staging: comedi: addi_apci_1564: add addi_watchdog dependency
Axel Lin (1):
regulator: ltc3589: Use of_get_child_by_name
Ben Skeggs (8):
drm/gk104/clk: only touch divider for mode we'll be using
drm/gk104/ibus: increase various random timeouts
drm/gf100-/gr: report class data to host on fwmthd failure
drm/gk104/fb/ram: fixups from an earlier search+replace
drm/nouveau/disp/dp: don't touch link config after success
drm/nv50/disp: fix a potential oops in supervisor handling
drm/nouveau/pwr: fix typo in fifo wrap handling
drm/gf117/i2c: no aux channels on this chipset
Benjamin Herrenschmidt (1):
Revert "offb: Add palette hack for little endian"
Boris BREZILLON (3):
i2c: sunxi: add P2WI DT bindings documentation
i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support
i2c: sun6-p2wi: fix call to snprintf
Catalin Marinas (2):
arm64: defconfig update for LTP
arm64: Limit the CMA buffer to 32-bit if ZONE_DMA
Chen Gang (17):
arch/unicore32/kernel/ksyms.c: remove several undefined exported symbols
arch/unicore32/kernel/module.c: use __vmalloc_node_range()
instead of __vmalloc_area()
arch/unicore32/kernel/clock.c: add readl() and writel() for 'PM_' macros
arch/unicore32/mm/alignment.c: include "asm/pgtable.h" to avoid
compiling error
arch/unicore32/include/asm/ptrace.h: add generic definition for
profile_pc()
arch/unicore32/include/asm/io.h: add readl_relaxed() generic definition
drivers/rtc/rtc-puv3.c: use dev_dbg() instead of dev_debug() for
typo issue
drivers/rtc/rtc-puv3.c: remove "&dev->" for typo issue MIME-Version: 1.0
arch/unicore32/kernel/ksyms.c: remove 2 export symbols to avoid
compiling failure
arch: unicore32: kernel: ksyms: remove 'bswapsi2' and 'muldi3'
to avoid compiling failure
drivers: scsi: mvsas: fix compiling issue by adding 'MVS_' for
"enum pci_interrupt_cause"
arch/unicore32/kernel/setup.c: add generic 'screen_info' to
avoid compiling failure
unicore32: include: asm: add missing ')' for PAGE_* macros in pgtable.h
arch:unicore32:mm: add devmem_is_allowed() to support STRICT_DEVMEM
arch: unicore32: ksyms: export additional find_first_*() to
avoid compiling failure
arch: unicore32: ksyms: export 'pm_power_off' to avoid compiling failure.
arch: unicore32: ksyms: export '__cpuc_coherent_kern_range' to
avoid compiling failure
Chew, Chiau Ee (1):
spi/pxa2xx: change default supported DMA burst size to 1
ChiaHao (1):
arm64: Bug fix in stack alignment exception
Chris Mason (1):
Btrfs: fix deadlocks with trylock on tree nodes
Chris Wilson (3):
drm/i915: Disable FBC by default also on Haswell and later
drm/i95: Initialize active ring->pid to -1
drm/i915: Reorder semaphore deadlock check
Christoph Hellwig (3):
block: remove elv_abort_queue and blk_abort_flushes
blk-mq: properly drain stopped queues
blk-mq: merge blk_mq_drain_queue and __blk_mq_drain_queue
Christoph Jaeger (1):
ACPI: use kstrto*() instead of simple_strto*()
Dan Carpenter (4):
i2c: rk3x: add NULL entry to the end of_device_id array
iio: adc: at91: signedness bug in at91_adc_get_trigger_value_by_name()
iio: adc: checking for NULL instead of IS_ERR() in probe
misc: vexpress: fix error handling vexpress_syscfg_regmap_init()
Dan Williams (4):
usb: fix ->update_hub_device() vs hdev->maxchild
usb: improve "not suspended yet" message in hub_suspend()
usb: quiet peer failure warning, disable poweroff
usb: fix hub-port pm_runtime_enable() vs runtime pm transitions
Daniel Vetter (5):
vt: Fix replacement console check when unbinding
vt: Fix up unregistration of vt drivers
vt: Don't ignore unbind errors in vt_unbind
drm/i915: Fixup global gtt cleanup
drm/i915: Kick out vga console
David Vrabel (4):
x86/xen: fix memory setup for PVH dom0
Revert "xen/pvh: Update E820 to work with PVH (v2)"
x86/xen: no need to explicitly register an NMI callback
xen/grant-table: fix suspend for non-PV guests
Denis Carikli (1):
imx-drm: parallel-display: Fix DPMS default state.
Dmitry Torokhov (1):
MAINTAINERS: add entry for VMware Balloon driver
Don Zickus (6):
perf tools: Update mmap2 interface with protection and flag bits
Revert "perf: Disable PERF_RECORD_MMAP2 support"
perf report: Add mem-mode documentation to report command
perf tools: Add cpumode to struct hist_entry
perf tools: Add support to dynamically get cacheline size
perf tools: Add dcacheline sort
Doug Smythies (1):
intel_pstate: Correct rounding in busy calculation
Ezequiel Garcia (2):
ARM: dts: Specify the NAND ECC scheme explicitly on Armada 375 DB board
ARM: dts: Specify the NAND ECC scheme explicitly on Armada 385 DB board
Fabian Frederick (2):
s390/qdio: replace shift loop by ilog2
ACPI / processor replace __attribute__((packed)) by __packed
Fathi Boudra (1):
builddeb: fix missing headers in linux-headers package
Filipe Manana (1):
Btrfs: remove unused wait queue in struct extent_buffer
Frank Rowand (1):
OF: fix of_find_node_by_path() assumption that of_allnodes is root
Fredrik Höglund (1):
drm/radeon: use pixel formats instead of depth/bpp
Greg Kroah-Hartman (1):
Revert "uio: fix vma io range check in mmap"
Gregory CLEMENT (1):
cpuidle: mvebu: Fix the name of the states
Guan Xuetao (1):
UniCore32: Change git tree location information in MAINTAINERS
Guenter Roeck (2):
ASoC: fsl: Fix build problem
of/platform: Fix microblaze build failure
Heiko Carstens (1):
s390: update default configuration
Imre Deak (1):
drm/i915: fix possible refcount leak when resetting forcewake
James Morris (1):
security: add Serge Hallyn as a maintainer
Jani Nikula (1):
drm/i915: set backlight duty cycle after backlight enable for gen4
Jarkko Nikula (1):
ASoC: dapm: Make sure register value is in sync with DAPM kcontrol state
Jason Cooper (1):
ARM: mvebu: DT: fix OpenBlocks AX3-4 RAM size
Jeff Layton (2):
locks: add missing memory barrier in break_deleg
locks: set fl_owner for leases back to current->files
Jens Axboe (2):
null_blk: fix softirq completions for queue_mode == 1
block: blk_max_size_offset() should check ->max_sectors
Jes Sorensen (2):
staging: rtl8723au: Request correct firmware file for A-cut parts
staging: rtl8723au: Reference correct firmwarefiles with MODULE_FIRMWARE()
Jiri Olsa (15):
perf tools: Fix pipe check regression in attr event callback
perf tools: Prettify the tags/TAGS/cscope targets output
perf tools: Cache register accesses for unwind processing
perf tools: Separate dso data related variables
perf tools: Add data_fd into dso object
perf tools: Add global list of opened dso objects
perf tools: Add global count of opened dso objects
perf tools: Cache dso data file descriptor
perf tools: Add file size check and factor dso__data_read_offset
perf tools: Allow to close dso fd in case of open failure
perf tools: Add dso__data_* interface descriptons
perf tests: Spawn child for each test
perf tests: Allow reuse of test_file function
perf tests: Add test for caching dso file descriptors
perf tests: Add test for closing dso objects on EMFILE error
Kees Cook (4):
s390: avoid format strings leaking into names
of: avoid format string parsing in kobject names
PM / hibernate: introduce "nohibernate" boot parameter
x86, kaslr: boot-time selectable with hibernation
Kinglong Mee (1):
NFSD: fix bug for readdir of pseudofs
Konstantin Khlebnikov (1):
epoll: fix use-after-free in eventpoll_release_file
Kuninori Morimoto (1):
ASoC: rsnd: fixup index of src/dst mod when capture
Lars-Peter Clausen (6):
ASoC: sigmadsp: Split regmap and I2C support into separate modules
ALSA: control: Protect user controls against concurrent access
ALSA: control: Fix replacing user controls
ALSA: control: Don't access controls outside of protected regions
ALSA: control: Handle numid overflow
ALSA: control: Make sure that id->index does not overflow
Linus Torvalds (1):
Linux 3.16-rc2
Linus Walleij (1):
ARM: integrator: fix section mismatch problem
Maarten Lankhorst (1):
drm/nouveau/disp: fix oops in destructor with headless cards
Mario Kleiner (3):
drm/radeon: Bypass hw lut's for > 8 bpc framebuffer scanout.
drm/nouveau/kms: reference vblank for crtc during pageflip.
drm/radeon: Use dce5/6 hdmi deep color clock setup also on dce8+
Mario Schuknecht (1):
staging: iio: tsl2x7x_core: fix proximity treshold
Mark Salter (1):
arm64: fix build error in sigcontext.h
Martin Peres (1):
drm/nouveau/doc: update the thermal documentation
Martin Schwidefsky (2):
s390/uaccess: always load the kernel ASCE after task switch
s390/compat: correct ucontext layout for high gprs
Masahiro Yamada (1):
kbuild: fix a typo in a kbuild document
Masami Hiramatsu (5):
perf probe: Improve error message for unknown member of data structure
perf probe: Show error code and description in verbose mode
perf probe: Improve an error message of perf probe --vars mode
perf probe: Improve error messages in --line option
x86/kprobes: Fix build errors and blacklist context_track_user
Mathias Nyman (1):
xhci: Fix sleeping with IRQs disabled in xhci_stop_device()
Matias Bjørling (1):
block: remove WQ_POWER_EFFICIENT from kblockd
Max Schwarz (1):
i2c: rk3x: add driver for Rockchip RK3xxx SoC I2C adapter
Miao Xie (5):
Btrfs: make free space cache write out functions more readable
Btrfs: fix broken free space cache after the system crashed
Btrfs: use bio_endio_nodec instead of open code
Btrfs: fix deadlock when mounting a degraded fs
Btrfs: fix wrong error handle when the device is missing or is
not writeable
Michael Veigel (1):
s390/ap_bus: Make modules parameters visible in sysfs
Michal Marek (3):
deb-pkg: Fix for relative paths
kbuild: Fix tar-pkg with relative $(objtree)
Documentation: Fix DocBook build with relative $(srctree)
Michel Dänzer (2):
Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"
drm/radeon: Fix radeon_irq_kms_pflip_irq_get/put() imbalance
Mika Westerberg (1):
ACPI / LPSS: Take I2C host controllers out of reset
Mike Snitzer (1):
null_blk: fix name and description of 'queue_mode' module parameter
Namhyung Kim (2):
perf script/python: Print array argument as string
perf record: Fix to honor user freq/interval properly
NeilBrown (1):
NFSD: Don't hand out delegations for 30 seconds after recalling them.
Nicolin Chen (1):
ASoC: fsl_spdif: Fix incorrect usage of regmap_read()
Nishanth Menon (1):
regulator: palmas: Fix SMPS list for 0V
Olof Johansson (1):
ARM: exynos: move sysram info to exynos.c
Paul Bolle (1):
arm64: ftrace: Fix comment typo 'CONFIG_FUNCTION_GRAPH_FP_TEST'
Paul Kocialkowski (1):
twl4030-madc: Request processed values in twl4030_get_madc_conversion
Peter Hurley (2):
serial: Fix IGNBRK handling
tty: Correct INPCK handling
Peter Meerwald (2):
iio: Fix two mpl3115 issues in measurement conversion
iio: Fix endianness issue in ak8975_read_axis()
Peter Oberparleiter (1):
s390/sclp_vt220: Enable ASCII console per default
Peter Zijlstra (1):
perf: Pass protection and flags bits through mmap2 interface
Philipp Hachtmann (2):
s390/watchdog: use watchdog API
s390/watchdog: add support for LPAR operation (diag288)
Pierre Moreau (2):
drm/nv50/gr: fix overlap while zeroing zcull regions
drm/nv50/gr: remove an unneeded write while initialising PGRAPH
Qu Wenruo (1):
btrfs: Skip scrubbing removed chunks to avoid -ENOENT.
Rafael J. Wysocki (1):
ACPI / ia64 / sba_iommu: Restore the working initialization ordering
Rob Clark (1):
drm: fix uninitialized acquire_ctx fields (v2)
Rob Herring (3):
ARM: exynos: cleanup kconfig option display
ARM: use menuconfig for sub-arch menus
tty/serial: fix 8250 early console option passing to regular console
Robert Hodaszi (1):
iio: mxs-lradc: fix divider
Sachin Kamat (2):
ARM: EXYNOS: Fix compilation warning
serial: samsung: Fix build error
Sam Ravnborg (67):
sparc32: rename mm/srmmu.h to mm/mm_32.h
sparc32: fix sparse warning in fault_32.c
sparc32: fix sparse warning in init_32.c
sparc32: fix sparse warnings in srmmu.c
sparc32: fix sparse "Should it be static?" in mm/
sparc32: fix sparse warning in traps_32.c
sparc32: fix sparse warnings in sun4m_irq.c and sun4d_irq.c
sparc32: fix sparse warnings in sun4d_irq.c
sparc32: fix sparse warnings in irq_32.c
sparc32: fix sparse warnings in process_32.h
sparc32: fix sparse warnings in signal_32.c
sparc32: fix sparse warnings in ioport.c
sparc32: fix sparse warnings in setup_32.c
sparc32: fix sparse warnings in windows.c
sparc: fix sparse warnings in cpu.c
sparc32: fix sparse warning in devices.c
sparc32: fix sparse warnings in tadpole.c
sparc32: fix sparse warnings in leon_pci_grpci1.c
sparc32: fix sparse warnings in leon_pci_grpci2.c
sparc32: fix sparse warnings in auxio_32.c
sparc32: fix sparse warnings in smp_32.c
sparc32: fix sparse warning in ptrace_32.c
sparc32: fix sparse warnings in unaligned_32.c
sparc: fix sparse warnings in of_device_common.c
sparc32: fix sparse warnings in leon_kernel.c
sparc32: fix sparse warnings in leon_pmc.c
sparc32: fix sparse warnings in sun4m_smp.c
sparc32: fix sparse warnings in sun4d_smp.c
sparc32: fix sparse warnings in leon_smp.c
sparc: move page_to_phys to page.h
sparc32: replace flip_dword() with swab32()
sparc32: introduce asm-generic/io.h
sparc32: clean up io_32.h
sparc32: fix build breakage
sparc32: fix sparse warning in iommu.c
sparc32: fix sparse warning in io-unit.c
sparc32: fix sparse warnings in pcic.c
sparc32: fix sparse warning in auxio_32.c
sparc32: fix sparse warnings in time_32.c
sparc32: fix sparse warnings in sys_sparc_32.c
sparc32: remove cast from output constraints in math asm statements
sparc64: remove cast from output constraints in math asm statements
sparc: fix sparse warning in math_{32,64}
sparc32: drop tadpole specific code
sparc: drop use of extern for prototypes in arch/sparc/include/asm
sparc: drop use of extern for prototypes in arch/sparc/*
sparc64: fix sparse warning in traps_64.c
sparc64: fix sparse warning in process_64.c
sparc64: fix sparse warnings in sys_sparc_64.c + unaligned_64.c
sparc64: fix sparse warning in btext.c
sparc64: fix sparse warning in prom_64.c
sparc64: fix sparse warnings in smp_64.c
sparc64: fix sparse warning in pci.c
sparc64: fix sparse warnings in sys_sparc32.c
sparc64: fix sparse "Should it be static?" warnings in signal32.c
sparc64: clean up compat_sigset_t.seta handling
sparc64: fix sparse warning in tsb.c
sparc64: fix sparse warnings in kprobes.c
sparc64: fix sparse warnings in perf_event.c
sparc: fix sparse warnings in smp_32.c + smp_64.c
sparc64: fix sparse warnings in aes_glue.c
sparc64: fix sparse warnings in init_64.c
sparc64: fix sparse warnings in compat_audit.c
sparc64: fix sparse warning in kgdb_64.c
sparc64: fix sparse warning in kprobes.c
sparc64: fix sparse warning in ftrace.c
sparc64: fix sparse warnings in int_64.c
Sebastian Ott (6):
s390/cio: silence lockdep warning
s390/airq: silence lockdep warning
s390/cio: set device name as early as possible
s390/ccwgroup: obtain extra reference for asynchronous processing
s390/ccwgroup: fix an uninitialized return code
s390/ccwgroup: use ccwgroup_ungroup wrapper
Stanislav Fomichev (1):
perf timechart: Reflow documentation
Stefan Raspl (1):
qdio: Keep device-specific dbf entries
Stephen Boyd (2):
ARM: Remove ARCH_HAS_CPUFREQ config option
unicore32: Remove ARCH_HAS_CPUFREQ config option
Stephen Warren (1):
ARM: multi_v7_defconfig: re-enable SDHCI drivers
Steven Rostedt (2):
tools lib traceevent: Add options to plugins
arm/ftrace: fix ftrace_return_addr() to ftrace_return_address()
Steven Rostedt (Red Hat) (3):
tools lib traceevent: Add flag to not load event plugins
tools lib traceevent: Add options to function plugin
tools lib traceevent: Added support for __get_bitmask() macro
Sudeep Holla (2):
arm64: restore alphabetic order in Kconfig
arm64: add ARCH_HAS_OPP to allow enabling OPP library
Suravee Suthikulpanit (1):
arm64/dma: Removing ARCH_HAS_DMA_GET_REQUIRED_MASK macro
Takashi Iwai (1):
drm/i915, HD-audio: Don't continue probing when nomodeset is given
Theodore Ts'o (1):
random: fix nasty entropy accounting bug
Thierry Reding (1):
regulator: as3722: Make 0 a valid selector
Thomas Gleixner (3):
rtmutex: Handle deadlock detection smarter
rtmutex: Detect changes in the pi lock chain
rtmutex: Plug slow unlock race
Tom O'Rourke (1):
drm/i915/bdw: remove erroneous chv specific workarounds from bdw code
Victor Kamensky (1):
arm64: ptrace: fix empty registers set in prstatus of aarch32 process core
Ville Syrjälä (1):
drm/i915: Avoid div-by-zero when pixel_multiplier is zero
Vinayak Kale (1):
arm64: dts: Add more serial port nodes in APM X-Gene device tree
Wang Shilong (1):
Btrfs: fix NULL pointer crash when running balance and scrub concurrently
Will Deacon (3):
arm64: ptrace: change fs when passing kernel pointer to regset code
arm64: uid16: fix __kernel_old_{gid,uid}_t definitions
arm64: mm: remove broken &= operator from pmd_mknotpresent
Wolfram Sang (1):
i2c: sun6i-p2wi: use proper return value in probe
Yi Zhang (1):
staging: android: timed_output: fix use after free of dev
Am Samstag, den 21.06.2014, 19:22 -1000 schrieb Linus Torvalds:
> It's a day early, but tomorrow ends up being inconvenient for me due
> to being on the road most of the day, so here you are. These days most
> people send me their pull requests and patches during the week, so
> it's not like I expect that a Sunday release would have made much of a
> difference. And it's also not like I didn't have enough changes for
> making a rc2 release.
>
> Anyway, enough excuses. 3.16-rc2 is out, and contains the usual
> assortment of fixes all over the map. The most unusual part at this
> point is how the sparc changes stand out (at almost 40% of the patch
> by bulk), but they are basically all just sparse warning cleanups.
>
> Similarly, some Nouveau drm changes standing out size-wise, but again
> those are largely due to small firmware fixes resulting in big
> generated changes. The actual real changes are fairly small.
>
> Ignoring those two unusually large changes (in lines), everything else
> looks fairly normal. There are driver changes, some tooling updates
> (particularly perf), and various other arch updates (arm, s390,
> unicore32, x86..). And just misc random stuff all over the place -
> rtmutex, btrfs, yadda yadda.
>
> The shortlog is not tiny, but small enough to include here, so you can
> see the details there if you care.
>
> Please do go test it out,
>
the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
X server.
First bad commit is:
# first bad commit: [78f2975eec9faff353a6194e854d3d39907bab68] drm/i915: Move all ring resets before setting the HWS page
commit 78f2975eec9faff353a6194e854d3d39907bab68
Author: Chris Wilson <[email protected]>
Date: Wed Apr 2 16:36:07 2014 +0100
drm/i915: Move all ring resets before setting the HWS page
In commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
Author: Naresh Kumar Kachhi <[email protected]>
Date: Wed Mar 12 16:39:40 2014 +0530
drm/i915: disable rings before HW status page setup
we reordered stopping the rings to do so before we set the HWS register.
However, there is an extra workaround for g45 to reset the rings twice,
and for consistency we should apply that workaround before setting the
HWS to be sure that the rings are truly stopped.
Reference: http://lkml.kernel.org/r/[email protected]
Tested-by: Pavel Machek <[email protected]>
Cc: Naresh Kumar Kachhi <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Jesse Barnes <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Above commit is not revertable anymore on 3.16-rc2 without conflict.
On Tue, 24 Jun 2014, Thomas Meyer <[email protected]> wrote:
> the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> X server.
This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
[1]. Also related [2].
Chris, any fresh ideas?
Thomas, please consider filing a bug against DRM/Intel at [3]. They will
have a better chance of not being forgotten as the mail thread goes
cold.
Thanks,
Jani.
[1] http://thread.gmane.org/gmane.linux.kernel/1700872
[2] https://bugs.freedesktop.org/show_bug.cgi?id=76554
[3] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>
> First bad commit is:
>
> # first bad commit: [78f2975eec9faff353a6194e854d3d39907bab68] drm/i915: Move all ring resets before setting the HWS page
>
> commit 78f2975eec9faff353a6194e854d3d39907bab68
> Author: Chris Wilson <[email protected]>
> Date: Wed Apr 2 16:36:07 2014 +0100
>
> drm/i915: Move all ring resets before setting the HWS page
>
> In commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
> Author: Naresh Kumar Kachhi <[email protected]>
> Date: Wed Mar 12 16:39:40 2014 +0530
>
> drm/i915: disable rings before HW status page setup
>
> we reordered stopping the rings to do so before we set the HWS register.
> However, there is an extra workaround for g45 to reset the rings twice,
> and for consistency we should apply that workaround before setting the
> HWS to be sure that the rings are truly stopped.
>
> Reference: http://lkml.kernel.org/r/[email protected]
> Tested-by: Pavel Machek <[email protected]>
> Cc: Naresh Kumar Kachhi <[email protected]>
> Signed-off-by: Chris Wilson <[email protected]>
> Reviewed-by: Jesse Barnes <[email protected]>
> Signed-off-by: Daniel Vetter <[email protected]>
> Signed-off-by: Jani Nikula <[email protected]>
>
> Above commit is not revertable anymore on 3.16-rc2 without conflict.
>
>
>
> _______________________________________________
> Intel-gfx mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> On Tue, 24 Jun 2014, Thomas Meyer <[email protected]> wrote:
> > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > X server.
>
> This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> [1]. Also related [2].
>
> Chris, any fresh ideas?
Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
everything we know and have tried is there. Which is not much more than
at time of the original incarnation:
commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
Author: Keith Packard <[email protected]>
Date: Tue Oct 14 17:20:35 2008 -0700
i915: Fix up ring initialization to cover G45 oddities
G45 appears quite sensitive to ring initialization register writes,
sometimes leaving the HEAD register with the START register contents. Check
to make sure HEAD is reset correctly when START is written, and fix it up,
screaming loudly.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > On Tue, 24 Jun 2014, Thomas Meyer <[email protected]> wrote:
> > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > > X server.
> >
> > This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> > [1]. Also related [2].
> >
> > Chris, any fresh ideas?
>
> Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
> everything we know and have tried is there. Which is not much more than
> at time of the original incarnation:
>
> commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
> Author: Keith Packard <[email protected]>
> Date: Tue Oct 14 17:20:35 2008 -0700
>
> i915: Fix up ring initialization to cover G45 oddities
>
> G45 appears quite sensitive to ring initialization register writes,
> sometimes leaving the HEAD register with the START register contents. Check
> to make sure HEAD is reset correctly when START is written, and fix it up,
> screaming loudly.
> -Chris
>
Hi,
so why not revert 78f2975eec9faff353a6194e854d3d39907bab68 (drm/i915:
Move all ring resets before setting the HWS page) ?
Without this commit 3.15 is super stable for me. This seems to be also
true for others according to above bug report.
thomas
On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > > On Tue, 24 Jun 2014, Thomas Meyer <[email protected]> wrote:
> > > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > > > X server.
> > >
> > > This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> > > [1]. Also related [2].
> > >
> > > Chris, any fresh ideas?
> >
> > Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
> > everything we know and have tried is there. Which is not much more than
> > at time of the original incarnation:
> >
> > commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
> > Author: Keith Packard <[email protected]>
> > Date: Tue Oct 14 17:20:35 2008 -0700
> >
> > i915: Fix up ring initialization to cover G45 oddities
> >
> > G45 appears quite sensitive to ring initialization register writes,
> > sometimes leaving the HEAD register with the START register contents. Check
> > to make sure HEAD is reset correctly when START is written, and fix it up,
> > screaming loudly.
> > -Chris
> >
>
> Hi,
>
> so why not revert 78f2975eec9faff353a6194e854d3d39907bab68 (drm/i915:
> Move all ring resets before setting the HWS page) ?
Because that patch was in response to a boot time regression.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue 2014-06-24 13:27:37, Chris Wilson wrote:
> On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> > Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> > > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > > > On Tue, 24 Jun 2014, Thomas Meyer <[email protected]> wrote:
> > > > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > > > > X server.
> > > >
> > > > This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> > > > [1]. Also related [2].
> > > >
> > > > Chris, any fresh ideas?
> > >
> > > Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
> > > everything we know and have tried is there. Which is not much more than
> > > at time of the original incarnation:
> > >
> > > commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
> > > Author: Keith Packard <[email protected]>
> > > Date: Tue Oct 14 17:20:35 2008 -0700
> > >
> > > i915: Fix up ring initialization to cover G45 oddities
> > >
> > > G45 appears quite sensitive to ring initialization register writes,
> > > sometimes leaving the HEAD register with the START register contents. Check
> > > to make sure HEAD is reset correctly when START is written, and fix it up,
> > > screaming loudly.
> > > -Chris
> > >
> >
> > Hi,
> >
> > so why not revert 78f2975eec9faff353a6194e854d3d39907bab68 (drm/i915:
> > Move all ring resets before setting the HWS page) ?
>
> Because that patch was in response to a boot time regression.
It seems we are in a fairly ugly "fix one board, it breaks another" iterations, right?
(BTW, if you apply patch to fix this bug, could you Cc me? I have strange feeling
that it will break my setup... Actually, it probably makes sense to Cc all the people
who reported problems with ring initialization...
What patch caused the boot time regression you are talking about? We need to get
list of commits involved in this, and revert the original one...
Jiri Kosina may have the same problem, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Jun 30, 2014 at 12:02:20PM +0200, Pavel Machek wrote:
> On Tue 2014-06-24 13:27:37, Chris Wilson wrote:
> > On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> > > Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> > > > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > > > > On Tue, 24 Jun 2014, Thomas Meyer <[email protected]> wrote:
> > > > > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > > > > > X server.
> > > > >
> > > > > This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> > > > > [1]. Also related [2].
> > > > >
> > > > > Chris, any fresh ideas?
> > > >
> > > > Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
> > > > everything we know and have tried is there. Which is not much more than
> > > > at time of the original incarnation:
> > > >
> > > > commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
> > > > Author: Keith Packard <[email protected]>
> > > > Date: Tue Oct 14 17:20:35 2008 -0700
> > > >
> > > > i915: Fix up ring initialization to cover G45 oddities
> > > >
> > > > G45 appears quite sensitive to ring initialization register writes,
> > > > sometimes leaving the HEAD register with the START register contents. Check
> > > > to make sure HEAD is reset correctly when START is written, and fix it up,
> > > > screaming loudly.
> > > > -Chris
> > > >
> > >
> > > Hi,
> > >
> > > so why not revert 78f2975eec9faff353a6194e854d3d39907bab68 (drm/i915:
> > > Move all ring resets before setting the HWS page) ?
> >
> > Because that patch was in response to a boot time regression.
>
> It seems we are in a fairly ugly "fix one board, it breaks another" iterations, right?
>
> (BTW, if you apply patch to fix this bug, could you Cc me? I have strange feeling
> that it will break my setup... Actually, it probably makes sense to Cc all the people
> who reported problems with ring initialization...
>
> What patch caused the boot time regression you are talking about? We need to get
> list of commits involved in this, and revert the original one...
commit 9991ae787a0c87fe7c783b4b6f4754c3cdbb6213
Author: Chris Wilson <[email protected]>
Date: Wed Apr 2 16:36:07 2014 +0100
drm/i915: Move all ring resets before setting the HWS page
In commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
Author: Naresh Kumar Kachhi <[email protected]>
Date: Wed Mar 12 16:39:40 2014 +0530
drm/i915: disable rings before HW status page setup
we reordered stopping the rings to do so before we set the HWS register.
However, there is an extra workaround for g45 to reset the rings twice,
and for consistency we should apply that workaround before setting the
HWS to be sure that the rings are truly stopped.
Cc: Naresh Kumar Kachhi <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Jesse Barnes <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
Author: Naresh Kumar Kachhi <[email protected]>
Date: Wed Mar 12 16:39:40 2014 +0530
drm/i915: disable rings before HW status page setup
Rings should be idle before issuing sync_flush
(in intel_ring_setup_status_page). This patch moves the ring
disabling before doing the HW status page setup.
Signed-off-by: Naresh Kumar Kachhi <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
--
Chris Wilson, Intel Open Source Technology Centre
Am Montag, den 30.06.2014, 11:09 +0100 schrieb Chris Wilson:
> On Mon, Jun 30, 2014 at 12:02:20PM +0200, Pavel Machek wrote:
> > On Tue 2014-06-24 13:27:37, Chris Wilson wrote:
> > > On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> > > > Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> > > > > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > > > > > On Tue, 24 Jun 2014, Thomas Meyer <[email protected]> wrote:
> > > > > > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > > > > > > X server.
> > > > > >
> > > > > > This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> > > > > > [1]. Also related [2].
> > > > > >
> > > > > > Chris, any fresh ideas?
> > > > >
> > > > > Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
> > > > > everything we know and have tried is there. Which is not much more than
> > > > > at time of the original incarnation:
> > > > >
> > > > > commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
> > > > > Author: Keith Packard <[email protected]>
> > > > > Date: Tue Oct 14 17:20:35 2008 -0700
> > > > >
> > > > > i915: Fix up ring initialization to cover G45 oddities
> > > > >
> > > > > G45 appears quite sensitive to ring initialization register writes,
> > > > > sometimes leaving the HEAD register with the START register contents. Check
> > > > > to make sure HEAD is reset correctly when START is written, and fix it up,
> > > > > screaming loudly.
> > > > > -Chris
> > > > >
> > > >
> > > > Hi,
> > > >
> > > > so why not revert 78f2975eec9faff353a6194e854d3d39907bab68 (drm/i915:
> > > > Move all ring resets before setting the HWS page) ?
> > >
> > > Because that patch was in response to a boot time regression.
> >
> > It seems we are in a fairly ugly "fix one board, it breaks another" iterations, right?
> >
> > (BTW, if you apply patch to fix this bug, could you Cc me? I have strange feeling
> > that it will break my setup... Actually, it probably makes sense to Cc all the people
> > who reported problems with ring initialization...
> >
> > What patch caused the boot time regression you are talking about? We need to get
> > list of commits involved in this, and revert the original one...
>
> commit 9991ae787a0c87fe7c783b4b6f4754c3cdbb6213
> Author: Chris Wilson <[email protected]>
> Date: Wed Apr 2 16:36:07 2014 +0100
>
> drm/i915: Move all ring resets before setting the HWS page
>
> In commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
> Author: Naresh Kumar Kachhi <[email protected]>
> Date: Wed Mar 12 16:39:40 2014 +0530
>
> drm/i915: disable rings before HW status page setup
>
> we reordered stopping the rings to do so before we set the HWS register.
> However, there is an extra workaround for g45 to reset the rings twice,
> and for consistency we should apply that workaround before setting the
> HWS to be sure that the rings are truly stopped.
>
> Cc: Naresh Kumar Kachhi <[email protected]>
> Signed-off-by: Chris Wilson <[email protected]>
> Reviewed-by: Jesse Barnes <[email protected]>
> Signed-off-by: Daniel Vetter <[email protected]>
>
>
> commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
> Author: Naresh Kumar Kachhi <[email protected]>
> Date: Wed Mar 12 16:39:40 2014 +0530
>
> drm/i915: disable rings before HW status page setup
>
> Rings should be idle before issuing sync_flush
> (in intel_ring_setup_status_page). This patch moves the ring
> disabling before doing the HW status page setup.
>
> Signed-off-by: Naresh Kumar Kachhi <[email protected]>
> Reviewed-by: Chris Wilson <[email protected]>
> Signed-off-by: Daniel Vetter <[email protected]>
>
>
Hi,
this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
regression go away on my machine:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 279488a..b896ac8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -459,22 +459,25 @@ static bool stop_ring(struct intel_engine_cs *ring)
{
struct drm_i915_private *dev_priv = to_i915(ring->dev);
- if (!IS_GEN2(ring->dev)) {
- I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
- if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
- DRM_ERROR("%s :timed out trying to stop ring\n", ring->name);
- return false;
- }
- }
-
+// if (!IS_GEN2(ring->dev)) {
+// I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
+// if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
+// DRM_ERROR("%s :timed out trying to stop ring1\n", ring->name);
+// return false;
+// }
+// }
+
+ /* Stop the ring if it's running. */
I915_WRITE_CTL(ring, 0);
I915_WRITE_HEAD(ring, 0);
ring->write_tail(ring, 0);
+ if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000))
+ DRM_ERROR("%s :timed out trying to stop ring2\n", ring->name);
- if (!IS_GEN2(ring->dev)) {
- (void)I915_READ_CTL(ring);
- I915_WRITE_MODE(ring, _MASKED_BIT_DISABLE(STOP_RING));
- }
+// if (!IS_GEN2(ring->dev)) {
+// (void)I915_READ_CTL(ring);
+// I915_WRITE_MODE(ring, _MASKED_BIT_DISABLE(STOP_RING));
+// }
return (I915_READ_HEAD(ring) & HEAD_ADDR) == 0;
}
Chris, any ideas why explicitly stopping the ring before reset, results
in this kind of misbehaviour on my machine on resume from ram?
with kind regards
thomas
On Wed, Jul 02, 2014 at 06:18:41PM +0200, Thomas Meyer wrote:
> Am Montag, den 30.06.2014, 11:09 +0100 schrieb Chris Wilson:
> > On Mon, Jun 30, 2014 at 12:02:20PM +0200, Pavel Machek wrote:
> > > On Tue 2014-06-24 13:27:37, Chris Wilson wrote:
> > > > On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> > > > > Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> > > > > > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > > > > > > On Tue, 24 Jun 2014, Thomas Meyer <[email protected]> wrote:
> > > > > > > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > > > > > > > X server.
> > > > > > >
> > > > > > > This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> > > > > > > [1]. Also related [2].
> > > > > > >
> > > > > > > Chris, any fresh ideas?
> > > > > >
> > > > > > Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
> > > > > > everything we know and have tried is there. Which is not much more than
> > > > > > at time of the original incarnation:
> > > > > >
> > > > > > commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
> > > > > > Author: Keith Packard <[email protected]>
> > > > > > Date: Tue Oct 14 17:20:35 2008 -0700
> > > > > >
> > > > > > i915: Fix up ring initialization to cover G45 oddities
> > > > > >
> > > > > > G45 appears quite sensitive to ring initialization register writes,
> > > > > > sometimes leaving the HEAD register with the START register contents. Check
> > > > > > to make sure HEAD is reset correctly when START is written, and fix it up,
> > > > > > screaming loudly.
> > > > > > -Chris
> > > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > so why not revert 78f2975eec9faff353a6194e854d3d39907bab68 (drm/i915:
> > > > > Move all ring resets before setting the HWS page) ?
> > > >
> > > > Because that patch was in response to a boot time regression.
> > >
> > > It seems we are in a fairly ugly "fix one board, it breaks another" iterations, right?
> > >
> > > (BTW, if you apply patch to fix this bug, could you Cc me? I have strange feeling
> > > that it will break my setup... Actually, it probably makes sense to Cc all the people
> > > who reported problems with ring initialization...
> > >
> > > What patch caused the boot time regression you are talking about? We need to get
> > > list of commits involved in this, and revert the original one...
> >
> > commit 9991ae787a0c87fe7c783b4b6f4754c3cdbb6213
> > Author: Chris Wilson <[email protected]>
> > Date: Wed Apr 2 16:36:07 2014 +0100
> >
> > drm/i915: Move all ring resets before setting the HWS page
> >
> > In commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
> > Author: Naresh Kumar Kachhi <[email protected]>
> > Date: Wed Mar 12 16:39:40 2014 +0530
> >
> > drm/i915: disable rings before HW status page setup
> >
> > we reordered stopping the rings to do so before we set the HWS register.
> > However, there is an extra workaround for g45 to reset the rings twice,
> > and for consistency we should apply that workaround before setting the
> > HWS to be sure that the rings are truly stopped.
> >
> > Cc: Naresh Kumar Kachhi <[email protected]>
> > Signed-off-by: Chris Wilson <[email protected]>
> > Reviewed-by: Jesse Barnes <[email protected]>
> > Signed-off-by: Daniel Vetter <[email protected]>
> >
> >
> > commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
> > Author: Naresh Kumar Kachhi <[email protected]>
> > Date: Wed Mar 12 16:39:40 2014 +0530
> >
> > drm/i915: disable rings before HW status page setup
> >
> > Rings should be idle before issuing sync_flush
> > (in intel_ring_setup_status_page). This patch moves the ring
> > disabling before doing the HW status page setup.
> >
> > Signed-off-by: Naresh Kumar Kachhi <[email protected]>
> > Reviewed-by: Chris Wilson <[email protected]>
> > Signed-off-by: Daniel Vetter <[email protected]>
> >
> >
>
> Hi,
>
> this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
> regression go away on my machine:
Hm, we could conditionalize this hack on IS_G4X ... Chris, thoughts?
-Daniel
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 279488a..b896ac8 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -459,22 +459,25 @@ static bool stop_ring(struct intel_engine_cs *ring)
> {
> struct drm_i915_private *dev_priv = to_i915(ring->dev);
>
> - if (!IS_GEN2(ring->dev)) {
> - I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
> - if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
> - DRM_ERROR("%s :timed out trying to stop ring\n", ring->name);
> - return false;
> - }
> - }
> -
> +// if (!IS_GEN2(ring->dev)) {
> +// I915_WRITE_MODE(ring, _MASKED_BIT_ENABLE(STOP_RING));
> +// if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000)) {
> +// DRM_ERROR("%s :timed out trying to stop ring1\n", ring->name);
> +// return false;
> +// }
> +// }
> +
> + /* Stop the ring if it's running. */
> I915_WRITE_CTL(ring, 0);
> I915_WRITE_HEAD(ring, 0);
> ring->write_tail(ring, 0);
> + if (wait_for_atomic((I915_READ_MODE(ring) & MODE_IDLE) != 0, 1000))
> + DRM_ERROR("%s :timed out trying to stop ring2\n", ring->name);
>
> - if (!IS_GEN2(ring->dev)) {
> - (void)I915_READ_CTL(ring);
> - I915_WRITE_MODE(ring, _MASKED_BIT_DISABLE(STOP_RING));
> - }
> +// if (!IS_GEN2(ring->dev)) {
> +// (void)I915_READ_CTL(ring);
> +// I915_WRITE_MODE(ring, _MASKED_BIT_DISABLE(STOP_RING));
> +// }
>
> return (I915_READ_HEAD(ring) & HEAD_ADDR) == 0;
> }
>
> Chris, any ideas why explicitly stopping the ring before reset, results
> in this kind of misbehaviour on my machine on resume from ram?
>
> with kind regards
> thomas
>
>
> _______________________________________________
> Intel-gfx mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon, 7 Jul 2014, Daniel Vetter wrote:
> > this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
> > regression go away on my machine:
>
> Hm, we could conditionalize this hack on IS_G4X ... Chris, thoughts?
For the record, commenting out the code in stop_ring() the way Thomas did
doesn't fix my problem (the one reported in [1]).
[1] https://bugs.freedesktop.org/show_bug.cgi?id=76554
--
Jiri Kosina
SUSE Labs
On Mon, Jul 07, 2014 at 05:16:13PM +0200, Daniel Vetter wrote:
> On Wed, Jul 02, 2014 at 06:18:41PM +0200, Thomas Meyer wrote:
> > Hi,
> >
> > this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
> > regression go away on my machine:
>
> Hm, we could conditionalize this hack on IS_G4X ... Chris, thoughts?
As different machines favour different w/a, I think the issue is mostly
timing related. It could be sequence of register writes, but we tried
different orders early on. The next experiment I guess would be to
insert small delays between each write to see if that helps. Or to write
each register twice.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Mon, 7 Jul 2014, Chris Wilson wrote:
> > > this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
> > > regression go away on my machine:
> >
> > Hm, we could conditionalize this hack on IS_G4X ... Chris, thoughts?
>
> As different machines favour different w/a, I think the issue is mostly
> timing related. It could be sequence of register writes, but we tried
> different orders early on. The next experiment I guess would be to
> insert small delays between each write to see if that helps. Or to write
> each register twice.
I actually tried to introduce rather large delays between individual
I915_WRITE() calls in the ring initialization sequence a couple weeks ago
already, but it resulted in complete machine lockup (which is worse than
my usual symptoms) during resume. Therefore I probably lack the knowledge
of internal workings of the HW that would allow me to guess what the
reasonable timeout value should be.
Willing to test any patches.
--
Jiri Kosina
SUSE Labs
On Tue, Jul 08, 2014 at 12:15:31AM +0200, Jiri Kosina wrote:
> On Mon, 7 Jul 2014, Chris Wilson wrote:
>
> > > > this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
> > > > regression go away on my machine:
> > >
> > > Hm, we could conditionalize this hack on IS_G4X ... Chris, thoughts?
> >
> > As different machines favour different w/a, I think the issue is mostly
> > timing related. It could be sequence of register writes, but we tried
> > different orders early on. The next experiment I guess would be to
> > insert small delays between each write to see if that helps. Or to write
> > each register twice.
>
> I actually tried to introduce rather large delays between individual
> I915_WRITE() calls in the ring initialization sequence a couple weeks ago
> already, but it resulted in complete machine lockup (which is worse than
> my usual symptoms) during resume. Therefore I probably lack the knowledge
> of internal workings of the HW that would allow me to guess what the
> reasonable timeout value should be.
Have you used msleep or udelay? The latter just spins the cpu and might be
less dangerous.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Jul 08, 2014 at 12:15:31AM +0200, Jiri Kosina wrote:
> On Mon, 7 Jul 2014, Chris Wilson wrote:
>
> > > > this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
> > > > regression go away on my machine:
> > >
> > > Hm, we could conditionalize this hack on IS_G4X ... Chris, thoughts?
> >
> > As different machines favour different w/a, I think the issue is mostly
> > timing related. It could be sequence of register writes, but we tried
> > different orders early on. The next experiment I guess would be to
> > insert small delays between each write to see if that helps. Or to write
> > each register twice.
>
> I actually tried to introduce rather large delays between individual
> I915_WRITE() calls in the ring initialization sequence a couple weeks ago
> already, but it resulted in complete machine lockup (which is worse than
> my usual symptoms) during resume. Therefore I probably lack the knowledge
> of internal workings of the HW that would allow me to guess what the
> reasonable timeout value should be.
>
> Willing to test any patches.
Are you using the extra patches on bug 76554? If not, try
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index e18ed05dc0d5..48326f9628d4 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -526,6 +526,9 @@ static int init_ring_common(struct intel_engine_cs *ring)
((ringbuf->size - PAGE_SIZE) & RING_NR_PAGES)
| RING_VALID);
+ I915_WRITE_HEAD(ring, 0);
+ (void)I915_READ_HEAD(ring);
+
/* If the head is still not zero, the ring is dead */
if (wait_for((I915_READ_CTL(ring) & RING_VALID) != 0 &&
I915_READ_START(ring) == i915_gem_obj_ggtt_offset(obj) &&
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, 8 Jul 2014, Chris Wilson wrote:
> > I actually tried to introduce rather large delays between individual
> > I915_WRITE() calls in the ring initialization sequence a couple weeks ago
> > already, but it resulted in complete machine lockup (which is worse than
> > my usual symptoms) during resume. Therefore I probably lack the knowledge
> > of internal workings of the HW that would allow me to guess what the
> > reasonable timeout value should be.
> >
> > Willing to test any patches.
>
> Are you using the extra patches on bug 76554? If not, try
Just for debugging.
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index e18ed05dc0d5..48326f9628d4 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -526,6 +526,9 @@ static int init_ring_common(struct intel_engine_cs *ring)
> ((ringbuf->size - PAGE_SIZE) & RING_NR_PAGES)
> | RING_VALID);
>
> + I915_WRITE_HEAD(ring, 0);
> + (void)I915_READ_HEAD(ring);
> +
> /* If the head is still not zero, the ring is dead */
> if (wait_for((I915_READ_CTL(ring) & RING_VALID) != 0 &&
> I915_READ_START(ring) == i915_gem_obj_ggtt_offset(obj) &&
Tried on top of current Linus' tree, and no improvement. ring
initialization failure upon resume, and window redrawing hosed.
--
Jiri Kosina
SUSE Labs
On Tue, Jul 08, 2014 at 02:46:57PM +0200, Jiri Kosina wrote:
> On Tue, 8 Jul 2014, Chris Wilson wrote:
>
> > > I actually tried to introduce rather large delays between individual
> > > I915_WRITE() calls in the ring initialization sequence a couple weeks ago
> > > already, but it resulted in complete machine lockup (which is worse than
> > > my usual symptoms) during resume. Therefore I probably lack the knowledge
> > > of internal workings of the HW that would allow me to guess what the
> > > reasonable timeout value should be.
> > >
> > > Willing to test any patches.
> >
> > Are you using the extra patches on bug 76554? If not, try
>
> Just for debugging.
>
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index e18ed05dc0d5..48326f9628d4 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -526,6 +526,9 @@ static int init_ring_common(struct intel_engine_cs *ring)
> > ((ringbuf->size - PAGE_SIZE) & RING_NR_PAGES)
> > | RING_VALID);
> >
> > + I915_WRITE_HEAD(ring, 0);
> > + (void)I915_READ_HEAD(ring);
> > +
> > /* If the head is still not zero, the ring is dead */
> > if (wait_for((I915_READ_CTL(ring) & RING_VALID) != 0 &&
> > I915_READ_START(ring) == i915_gem_obj_ggtt_offset(obj) &&
>
> Tried on top of current Linus' tree, and no improvement. ring
> initialization failure upon resume, and window redrawing hosed.
Which error during ring-init are you hitting?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, 8 Jul 2014, Chris Wilson wrote:
> > Tried on top of current Linus' tree, and no improvement. ring
> > initialization failure upon resume, and window redrawing hosed.
>
> Which error during ring-init are you hitting?
It's still the same I reported in
bugs.freedesktop.org/show_bug.cgi?id=76554
[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 (valid? 1) head 000f645c tail 00000000 start 000e4000 [expected 000e4000]
[drm:__i915_drm_thaw] *ERROR* failed to re-initialize GPU, declaring wedged!
--
Jiri Kosina
SUSE Labs