dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 111667] gem_render_copy failing on CCS subtests
by bugzilla-daemon＠freedesktop.org 23 Sep '19

23 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111667 Bug ID: 111667 Summary: gem_render_copy failing on CCS subtests Product: DRI Version: DRI git Hardware: Other OS: Linux (All) Status: NEW Severity: major Priority: not set Component: IGT Assignee: dri-devel(a)lists.freedesktop.org Reporter: mika.kahola(a)intel.com gem_render_copy is failing on CCS subtests on TGL y-tiled-ccs-to-linear y-tiled-ccs-to-x-tiled y-tiled-ccs-to-y-tiled y-tiled-ccs-to-yf-tiled yf-tiled-ccs-to-linear yf-tiled-ccs-to-x-tiled yf-tiled-ccs-to-y-tiled yf-tiled-ccs-to-yf-tiled It seems that at least, rendercopy support for GEN12 is missing from upstream IGT. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[PATCH v1 0/2] Add initial support for slimport anx7625
by Xin Ji 23 Sep '19

23 Sep '19

Hi all, The following series add initial support for the Slimport ANX7625 transmitter, a ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device. This is the first version upload, any mistakes, please let me know, I will fix it in the next series. Thanks, Xin Xin Ji (2): dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver .../bindings/display/bridge/anx7625.yaml | 84 + drivers/gpu/drm/bridge/Makefile | 2 +- drivers/gpu/drm/bridge/analogix/Kconfig | 6 + drivers/gpu/drm/bridge/analogix/Makefile | 1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 2110 ++++++++++++++++++++ drivers/gpu/drm/bridge/analogix/anx7625.h | 405 ++++ 6 files changed, 2607 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7625.yaml create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h -- 2.7.4

1 2

Re: [PATCH v1 2/2] drm/panel: simple: add display timings for logic technologies displays
by Philippe Schenker 23 Sep '19

23 Sep '19

On Fri, 2019-09-20 at 09:54 +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> > > Add display timings for the following 3 display panels manufactured by > Logic Technologies Limited: > > - LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display > 7" Parallel [1] > - LT161010-2NHR e.g. as found in the Toradex Resistive Touch Display > 7" > Parallel [2] > - LT170410-2WHC e.g. as found in the Toradex Capacitive Touch Display > 10.1" LVDS [3] > > Those panels may also be distributed by Endrich Bauelemente Vertriebs > GmbH [4]. > > [1] > https://docs.toradex.com/104497-7-inch-parallel-capacitive-touch-display-80… > [2] > https://docs.toradex.com/104498-7-inch-parallel-resistive-touch-display-800… > [3] > https://docs.toradex.com/105952-10-1-inch-lvds-capacitive-touch-display-128… > [4] > https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30 > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> Reviewed-by: Philippe Schenker <philippe.schenker(a)toradex.com> > > --- > > drivers/gpu/drm/panel/panel-simple.c | 65 > ++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > > diff --git a/drivers/gpu/drm/panel/panel-simple.c > b/drivers/gpu/drm/panel/panel-simple.c > index 28fa6ba7b767..42bd0de25167 100644 > --- a/drivers/gpu/drm/panel/panel-simple.c > +++ b/drivers/gpu/drm/panel/panel-simple.c > @@ -2034,6 +2034,62 @@ static const struct panel_desc lg_lp129qe = { > }, > }; > > +static const struct display_timing logictechno_lt161010_2nh_timing = > { > + .pixelclock = { 26400000, 33300000, 46800000 }, > + .hactive = { 800, 800, 800 }, > + .hfront_porch = { 16, 210, 354 }, > + .hback_porch = { 46, 46, 46 }, > + .hsync_len = { 1, 20, 40 }, > + .vactive = { 480, 480, 480 }, > + .vfront_porch = { 7, 22, 147 }, > + .vback_porch = { 23, 23, 23 }, > + .vsync_len = { 1, 10, 20 }, > + .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW | > + DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE | > + DISPLAY_FLAGS_SYNC_POSEDGE, > +}; > + > +static const struct panel_desc logictechno_lt161010_2nh = { > + .timings = &logictechno_lt161010_2nh_timing, > + .num_timings = 1, > + .size = { > + .width = 154, > + .height = 86, > + }, > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18, > + .bus_flags = DRM_BUS_FLAG_DE_HIGH | > + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE | > + DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE, > +}; > + > +static const struct display_timing logictechno_lt170410_2whc_timing = > { > + .pixelclock = { 68900000, 71100000, 7340000 }, > + .hactive = { 1280, 1280, 1280 }, > + .hfront_porch = { 23, 60, 71 }, > + .hback_porch = { 23, 60, 71 }, > + .hsync_len = { 15, 40, 47 }, > + .vactive = { 800, 800, 800 }, > + .vfront_porch = { 5, 7, 10 }, > + .vback_porch = { 5, 7, 10 }, > + .vsync_len = { 6, 9, 12 }, > + .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW | > + DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE | > + DISPLAY_FLAGS_SYNC_POSEDGE, > +}; > + > +static const struct panel_desc logictechno_lt170410_2whc = { > + .timings = &logictechno_lt170410_2whc_timing, > + .num_timings = 1, > + .size = { > + .width = 217, > + .height = 136, > + }, > + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, > + .bus_flags = DRM_BUS_FLAG_DE_HIGH | > + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE | > + DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE, > +}; > + > static const struct drm_display_mode mitsubishi_aa070mc01_mode = { > .clock = 30400, > .hdisplay = 800, > @@ -3264,6 +3320,15 @@ static const struct of_device_id > platform_of_match[] = { > }, { > .compatible = "lg,lp129qe", > .data = &lg_lp129qe, > + }, { > + .compatible = "logictechno,lt161010-2nhc", > + .data = &logictechno_lt161010_2nh, > + }, { > + .compatible = "logictechno,lt161010-2nhr", > + .data = &logictechno_lt161010_2nh, > + }, { > + .compatible = "logictechno,lt170410-2whc", > + .data = &logictechno_lt170410_2whc, > }, { > .compatible = "mitsubishi,aa070mc01-ca1", > .data = &mitsubishi_aa070mc01,

1 0

Re: [PATCH v1 1/2] dt-bindings: add vendor prefix for logic technologies limited
by Philippe Schenker 23 Sep '19

23 Sep '19

On Fri, 2019-09-20 at 09:54 +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> > > Add vendor prefix for Logic Technologies Limited [1] which is a > Chinese > display manufacturer e.g. distributed by German Endrich Bauelemente > Vertriebs GmbH [2]. > > [1] https://logictechno.com/contact-us/ > [2] > https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30 > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> Reviewed-by: Philippe Schenker <philippe.schenker(a)toradex.com> > > --- > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 967e78c5ec0a..1441146f394f 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -541,6 +541,8 @@ patternProperties: > description: Linear Technology Corporation > "^logicpd,.*": > description: Logic PD, Inc. > + "^logictechno,.*": > + description: Logic Technologies Limited > "^longcheer,.*": > description: Longcheer Technology (Shanghai) Co., Ltd. > "^lsi,.*":

1 0

[PATCH v17 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework
by Brendan Higgins 23 Sep '19

23 Sep '19

## TL;DR This revision addresses comments from Linus[1] and Randy[2], by moving top level `kunit/` directory to `lib/kunit/` and likewise moves top level Kconfig entry under lib/Kconfig.debug, so the KUnit submenu now shows up under the "Kernel Hacking" menu. As a consequence of this, I rewrote patch 06/18 (kbuild: enable building KUnit), and now needs to be re-acked/reviewed. ## Background This patch set proposes KUnit, a lightweight unit testing and mocking framework for the Linux kernel. Unlike Autotest and kselftest, KUnit is a true unit testing framework; it does not require installing the kernel on a test machine or in a VM (however, KUnit still allows you to run tests on test machines or in VMs if you want[3]) and does not require tests to be written in userspace running on a host kernel. Additionally, KUnit is fast: From invocation to completion KUnit can run several dozen tests in about a second. Currently, the entire KUnit test suite for KUnit runs in under a second from the initial invocation (build time excluded). KUnit is heavily inspired by JUnit, Python's unittest.mock, and Googletest/Googlemock for C++. KUnit provides facilities for defining unit test cases, grouping related test cases into test suites, providing common infrastructure for running tests, mocking, spying, and much more. ### What's so special about unit testing? A unit test is supposed to test a single unit of code in isolation, hence the name. There should be no dependencies outside the control of the test; this means no external dependencies, which makes tests orders of magnitudes faster. Likewise, since there are no external dependencies, there are no hoops to jump through to run the tests. Additionally, this makes unit tests deterministic: a failing unit test always indicates a problem. Finally, because unit tests necessarily have finer granularity, they are able to test all code paths easily solving the classic problem of difficulty in exercising error handling code. ### Is KUnit trying to replace other testing frameworks for the kernel? No. Most existing tests for the Linux kernel are end-to-end tests, which have their place. A well tested system has lots of unit tests, a reasonable number of integration tests, and some end-to-end tests. KUnit is just trying to address the unit test space which is currently not being addressed. ### More information on KUnit There is a bunch of documentation near the end of this patch set that describes how to use KUnit and best practices for writing unit tests. For convenience I am hosting the compiled docs here[4]. Additionally for convenience, I have applied these patches to a branch[5]. The repo may be cloned with: git clone https://kunit.googlesource.com/linux This patchset is on the kunit/initial/v5.3/v17 branch. ## History since v15 ### v17 - Addressed comments on 06/19 (lib: enable building KUnit in lib/) from Stephen Boyd by moving KUnit submenu ahead of Runtime Testing submenu. ### v16 - Addressed comments from Linus Torvalds by moving all kunit/ paths to lib/kunit/. - Addressed comments by Randy Dunlap by moving KUnit Kconfig under lib/Kconfig.debug so the KUnit submenu shows up under the "Kernel Hacking" menu. [1] https://www.lkml.org/lkml/2019/9/20/696 [2] https://www.lkml.org/lkml/2019/9/20/738 [3] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni… [4] https://google.github.io/kunit-docs/third_party/kernel/docs/ [5] https://kunit.googlesource.com/linux/+/kunit/initial/v5.3/v17 --- Avinash Kondareddy (1): kunit: test: add tests for KUnit managed resources Brendan Higgins (16): kunit: test: add KUnit test runner core kunit: test: add test resource management API kunit: test: add string_stream a std::stream like string builder kunit: test: add assertion printing library kunit: test: add the concept of expectations lib: enable building KUnit in lib/ kunit: test: add initial tests objtool: add kunit_try_catch_throw to the noreturn list kunit: test: add support for test abort kunit: test: add tests for kunit test abort kunit: test: add the concept of assertions kunit: defconfig: add defconfigs for building KUnit tests Documentation: kunit: add documentation for KUnit MAINTAINERS: add entry for KUnit the unit testing framework MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section kunit: fix failure to build without printk Felix Guo (1): kunit: tool: add Python wrappers for running KUnit tests Iurii Zaikin (1): kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec() Documentation/dev-tools/index.rst | 1 + Documentation/dev-tools/kunit/api/index.rst | 16 + Documentation/dev-tools/kunit/api/test.rst | 11 + Documentation/dev-tools/kunit/faq.rst | 62 + Documentation/dev-tools/kunit/index.rst | 79 + Documentation/dev-tools/kunit/start.rst | 180 ++ Documentation/dev-tools/kunit/usage.rst | 576 +++++++ MAINTAINERS | 13 + arch/um/configs/kunit_defconfig | 3 + include/kunit/assert.h | 356 ++++ include/kunit/string-stream.h | 51 + include/kunit/test.h | 1490 +++++++++++++++++ include/kunit/try-catch.h | 75 + kernel/Makefile | 2 + kernel/sysctl-test.c | 392 +++++ lib/Kconfig.debug | 13 + lib/Makefile | 2 + lib/kunit/Kconfig | 38 + lib/kunit/Makefile | 9 + lib/kunit/assert.c | 141 ++ lib/kunit/example-test.c | 88 + lib/kunit/string-stream-test.c | 52 + lib/kunit/string-stream.c | 217 +++ lib/kunit/test-test.c | 331 ++++ lib/kunit/test.c | 478 ++++++ lib/kunit/try-catch.c | 118 ++ tools/objtool/check.c | 1 + tools/testing/kunit/.gitignore | 3 + tools/testing/kunit/configs/all_tests.config | 3 + tools/testing/kunit/kunit.py | 136 ++ tools/testing/kunit/kunit_config.py | 66 + tools/testing/kunit/kunit_kernel.py | 149 ++ tools/testing/kunit/kunit_parser.py | 310 ++++ tools/testing/kunit/kunit_tool_test.py | 206 +++ .../test_is_test_passed-all_passed.log | 32 + .../test_data/test_is_test_passed-crash.log | 69 + .../test_data/test_is_test_passed-failure.log | 36 + .../test_is_test_passed-no_tests_run.log | 75 + .../test_output_isolated_correctly.log | 106 ++ .../test_data/test_read_from_file.kconfig | 17 + 40 files changed, 6003 insertions(+) create mode 100644 Documentation/dev-tools/kunit/api/index.rst create mode 100644 Documentation/dev-tools/kunit/api/test.rst create mode 100644 Documentation/dev-tools/kunit/faq.rst create mode 100644 Documentation/dev-tools/kunit/index.rst create mode 100644 Documentation/dev-tools/kunit/start.rst create mode 100644 Documentation/dev-tools/kunit/usage.rst create mode 100644 arch/um/configs/kunit_defconfig create mode 100644 include/kunit/assert.h create mode 100644 include/kunit/string-stream.h create mode 100644 include/kunit/test.h create mode 100644 include/kunit/try-catch.h create mode 100644 kernel/sysctl-test.c create mode 100644 lib/kunit/Kconfig create mode 100644 lib/kunit/Makefile create mode 100644 lib/kunit/assert.c create mode 100644 lib/kunit/example-test.c create mode 100644 lib/kunit/string-stream-test.c create mode 100644 lib/kunit/string-stream.c create mode 100644 lib/kunit/test-test.c create mode 100644 lib/kunit/test.c create mode 100644 lib/kunit/try-catch.c create mode 100644 tools/testing/kunit/.gitignore create mode 100644 tools/testing/kunit/configs/all_tests.config create mode 100755 tools/testing/kunit/kunit.py create mode 100644 tools/testing/kunit/kunit_config.py create mode 100644 tools/testing/kunit/kunit_kernel.py create mode 100644 tools/testing/kunit/kunit_parser.py create mode 100755 tools/testing/kunit/kunit_tool_test.py create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-all_passed.log create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-crash.log create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-failure.log create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-no_tests_run.log create mode 100644 tools/testing/kunit/test_data/test_output_isolated_correctly.log create mode 100644 tools/testing/kunit/test_data/test_read_from_file.kconfig -- 2.23.0.351.gc4317032e6-goog

2 21

[PATCH 0/3] drm, fbdev: complete remove_conflicting_pci_framebuffers cleanup.
by Gerd Hoffmann 23 Sep '19

23 Sep '19

Gerd Hoffmann (3): fbdev: drop res_id parameter from remove_conflicting_pci_framebuffers drm: drop resource_id parameter from drm_fb_helper_remove_conflicting_pci_framebuffers drm/i915: switch to drm_fb_helper_remove_conflicting_pci_framebuffers include/drm/drm_fb_helper.h | 6 ++-- include/linux/fb.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/bochs/bochs_drv.c | 2 +- drivers/gpu/drm/cirrus/cirrus.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 41 ++----------------------- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +- drivers/gpu/drm/qxl/qxl_drv.c | 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 1 - drivers/video/fbdev/core/fbmem.c | 17 +++------- 11 files changed, 16 insertions(+), 63 deletions(-) -- 2.18.1

3 10

[Nouveau][PATCH] drm/nouveau: Fix memory leak in nvkm_ram_get()
by Yongxin Liu 23 Sep '19

23 Sep '19

When resuming from ACPI S3, memory leak happens in nvkm_ram_get(). This is because *pmemory points to newly allocated memory without checking and freeing the old memory. Here is the log showing this issue. unreferenced object 0xffffa3b608c6d5c0 (size 64): comm "kworker/u32:30", pid 934, jiffies 4294823520 (age 5000.217s) hex dump (first 32 bytes): 00 fc 4a c0 ff ff ff ff 00 00 00 00 00 00 00 00 ..J............. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000e923bf81>] kmem_cache_alloc_trace+0x181/0x250 [<00000000edb7beaa>] nvkm_ram_get+0xb0/0x1d0 [nouveau] [<000000004ecaa918>] gt215_ram_init+0xc5/0x2f0 [nouveau] [<00000000007ba1a0>] nvkm_ram_init+0x1a/0x20 [nouveau] [<0000000050abf84b>] nvkm_fb_init+0x27/0xe0 [nouveau] [<00000000fae7fedc>] nvkm_subdev_init+0xbc/0x210 [nouveau] [<00000000a67b86e4>] nvkm_device_init+0x12a/0x280 [nouveau] [<00000000c02ac03e>] nvkm_udevice_init+0x48/0x60 [nouveau] [<0000000048f35641>] nvkm_object_init+0x43/0x110 [nouveau] [<00000000c6f92dc0>] nvkm_object_init+0x74/0x110 [nouveau] [<00000000c6f92dc0>] nvkm_object_init+0x74/0x110 [nouveau] [<000000007416951c>] nvkm_client_resume+0xe/0x10 [nouveau] [<00000000c5d31dfd>] nvif_client_resume+0x1d/0x20 [nouveau] [<000000008f3a638f>] nouveau_do_resume+0x2d/0x150 [nouveau] [<00000000df2c2b85>] nouveau_pmops_resume+0x6b/0xa0 [nouveau] [<00000000f44c649d>] pci_pm_resume+0x71/0xb0 Signed-off-by: Yongxin Liu <yongxin.liu(a)windriver.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.c b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.c index b11867f682cb..60be4d811187 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.c @@ -124,6 +124,9 @@ nvkm_ram_get(struct nvkm_device *device, u8 heap, u8 type, u8 rpage, u64 size, nvkm_memory_ctor(&nvkm_vram, &vram->memory); vram->ram = ram; vram->page = page; + + if (*pmemory) + nvkm_memory_unref(pmemory); *pmemory = &vram->memory; mutex_lock(&ram->fb->subdev.mutex); -- 2.14.4

2 1

[Bug 204227] New: Visual artefacts and crash from suspend on amdgpu
by bugzilla-daemon＠bugzilla.kernel.org 23 Sep '19

23 Sep '19

https://bugzilla.kernel.org/show_bug.cgi?id=204227 Bug ID: 204227 Summary: Visual artefacts and crash from suspend on amdgpu Product: Drivers Version: 2.5 Kernel Version: 5.2.1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: dolohow(a)outlook.com Regression: No Created attachment 283823 --> https://bugzilla.kernel.org/attachment.cgi?id=283823&action=edit dmesg After upgrading kernel from 5.1.14 to 5.2.1 I encountered many artifacts during desktop session. Also when going from suspend state, external monitor is green and kernel crashes. See dmesg -- You are receiving this mail because: You are watching the assignee of the bug.

1 15

[PATCH v1 0/2] Free the writeback_job when it with an empty fb
by Lowry Li (Arm Technology China) 23 Sep '19

23 Sep '19

Hi, This serie aims at adding the check and free the writeback_job when it with an empty fb in drm_atomic_connector_check(). Also did some refine in drm_writeback_signal_completion() to clear the fence pointer when writeback job signaled. This patchset is based at the drm-misc-fixes branch. Lowry Li (Arm Technology China) (2): drm: Free the writeback_job when it with an empty fb drm: Clear the fence pointer when writeback job signaled .../drm/arm/display/komeda/komeda_wb_connector.c | 3 +-- drivers/gpu/drm/arm/malidp_mw.c | 4 ++-- drivers/gpu/drm/drm_atomic.c | 13 ++++++++---- drivers/gpu/drm/drm_writeback.c | 23 ++++++++++++++-------- drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 4 ++-- drivers/gpu/drm/vc4/vc4_txp.c | 5 ++--- 6 files changed, 31 insertions(+), 21 deletions(-) -- 1.9.1

4 10

Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903
by Alexander Kapshuk 23 Sep '19

23 Sep '19

To Whom It May Concern Every kernel I have built since 5.3.0-rc2-next-20190730 and up to 5.3.0-rc7-next-20190903 has resulted in the kernel panic described below. The panic occurs early on in the boot process, so no records of it get written on disk. I resourted to taking photos and videos to get the info for debugging. [Kernel panic] Code: 00 48 83 bb f0 00 00 00 00 74 16 48 83 c3 18 b9 17 00 00 00 31 c0 48 89 df f3 48 ab 5b 41 5c 5d c3 4c 89 a3 f0 00 00 00 eb e1 <0f> 0b 0f 1f 40 00 55 48 89 e5 41 54 49 89 d4 53 48 89 f3 e8 7e ff Kernel panic - Not syncing: Attempted to kill init! exitcode=0x0000000b. Top of call stack: __drm_fb_helper_initial_config_and_unlock drm_fb_helper_initial_config <scripts/decodecode <~/tmp/panic_code.txt Code: 00 48 83 bb f0 00 00 00 00 74 16 48 83 c3 18 b9 17 00 00 00 31 c0 48 89 df f3 48 ab 5b 41 5c 5d c3 4c 89 a3 f0 00 00 00 eb e1 <0f> 0b 0f 1f 40 00 55 48 89 e5 41 54 49 89 d4 53 48 89 f3 e8 7e ff All code ======== 0: 00 48 83 add %cl,-0x7d(%rax) 3: bb f0 00 00 00 mov $0xf0,%ebx 8: 00 74 16 48 add %dh,0x48(%rsi,%rdx,1) c: 83 c3 18 add $0x18,%ebx f: b9 17 00 00 00 mov $0x17,%ecx 14: 31 c0 xor %eax,%eax 16: 48 89 df mov %rbx,%rdi 19: f3 48 ab rep stos %rax,%es:(%rdi) 1c: 5b pop %rbx 1d: 41 5c pop %r12 1f: 5d pop %rbp 20: c3 retq 21: 4c 89 a3 f0 00 00 00 mov %r12,0xf0(%rbx) 28: eb e1 jmp 0xb 2a:* 0f 0b ud2 <-- trapping instruction 2c: 0f 1f 40 00 nopl 0x0(%rax) 30: 55 push %rbp 31: 48 89 e5 mov %rsp,%rbp 34: 41 54 push %r12 36: 49 89 d4 mov %rdx,%r12 39: 53 push %rbx 3a: 48 89 f3 mov %rsi,%rbx 3d: e8 .byte 0xe8 3e: 7e ff jle 0x3f Code starting with the faulting instruction =========================================== 0: 0f 0b ud2 2: 0f 1f 40 00 nopl 0x0(%rax) 6: 55 push %rbp 7: 48 89 e5 mov %rsp,%rbp a: 41 54 push %r12 c: 49 89 d4 mov %rdx,%r12 f: 53 push %rbx 10: 48 89 f3 mov %rsi,%rbx 13: e8 .byte 0xe8 14: 7e ff jle 0x15 The panic occurs after the 'Driver supports precise vblank timestamp query.' line gets printed to console: [ 2.858970] Linux agpgart interface v0.103 [ 2.859308] nouveau 0000:01:00.0: NVIDIA G84 (084300a2) [ 2.968950] nouveau 0000:01:00.0: bios: version 60.84.68.00.19 [ 2.989923] nouveau 0000:01:00.0: bios: M0203T not found [ 2.990010] nouveau 0000:01:00.0: bios: M0203E not matched! [ 2.990096] nouveau 0000:01:00.0: fb: 512 MiB DDR2 [ 3.062362] [TTM] Zone kernel: Available graphics memory: 2015014 KiB [ 3.062494] [TTM] Initializing pool allocator [ 3.062581] [TTM] Initializing DMA pool allocator [ 3.062683] nouveau 0000:01:00.0: DRM: VRAM: 512 MiB [ 3.062769] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB [ 3.062859] nouveau 0000:01:00.0: DRM: TMDS table version 2.0 [ 3.062944] nouveau 0000:01:00.0: DRM: DCB version 4.0 [ 3.063030] nouveau 0000:01:00.0: DRM: DCB outp 00: 02000300 00000028 [ 3.063117] nouveau 0000:01:00.0: DRM: DCB outp 01: 01000302 00000030 [ 3.063203] nouveau 0000:01:00.0: DRM: DCB outp 02: 04011310 00000028 [ 3.063290] nouveau 0000:01:00.0: DRM: DCB outp 03: 02011312 00c000b0 [ 3.063377] nouveau 0000:01:00.0: DRM: DCB conn 00: 1030 [ 3.063462] nouveau 0000:01:00.0: DRM: DCB conn 01: 2130 [ 3.065982] nouveau 0000:01:00.0: DRM: MM: using CRYPT for buffer copies [ 3.066622] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 3.066754] [drm] Driver supports precise vblank timestamp query. I was not able to capture the value of RIP for this crash. With drm_kms_helper.fbdev_emulation=0 enabled, as documented in the commentary to function drm_fb_helper_initial_config defined in drivers/gpu/drm/drm_fb_helper.c, I get the following output: RIP: 0010: _raw_spin_lock+0x7/0x20 Code: ba ff 00 00 00 f0 0f b1 17 75 01 c3 55 48 89 e5 e8 23 a2 6d ff 5d c3 66 66 2e 0f 1f 84 00 00 00 00 00 90 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 01 c3 55 89 c6 40 89 e5 e8 e7 8f 6d ff 5d c3 0f 1f <scripts/decodecode <~/tmp/panic_code.txt Code: ba ff 00 00 00 f0 0f b1 17 75 01 c3 55 48 89 e5 e8 23 a2 6d ff 5d c3 66 66 2e 0f 1f 84 00 00 00 00 00 90 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 01 c3 55 89 c6 40 89 e5 e8 e7 8f 6d ff 5d c3 0f 1f All code ======== 0: ba ff 00 00 00 mov $0xff,%edx 5: f0 0f b1 17 lock cmpxchg %edx,(%rdi) 9: 75 01 jne 0xc b: c3 retq c: 55 push %rbp d: 48 89 e5 mov %rsp,%rbp 10: e8 23 a2 6d ff callq 0xffffffffff6da238 15: 5d pop %rbp 16: c3 retq 17: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) 1e: 00 00 00 00 22: 90 nop 23: 31 c0 xor %eax,%eax 25: ba 01 00 00 00 mov $0x1,%edx 2a:* f0 0f b1 17 lock cmpxchg %edx,(%rdi) <-- trapping instruction 2e: 75 01 jne 0x31 30: c3 retq 31: 55 push %rbp 32: 89 c6 mov %eax,%esi 34: 40 89 e5 rex mov %esp,%ebp 37: e8 e7 8f 6d ff callq 0xffffffffff6d9023 3c: 5d pop %rbp 3d: c3 retq 3e: 0f .byte 0xf 3f: 1f (bad) Code starting with the faulting instruction =========================================== 0: f0 0f b1 17 lock cmpxchg %edx,(%rdi) 4: 75 01 jne 0x7 6: c3 retq 7: 55 push %rbp 8: 89 c6 mov %eax,%esi a: 40 89 e5 rex mov %esp,%ebp d: e8 e7 8f 6d ff callq 0xffffffffff6d8ff9 12: 5d pop %rbp 13: c3 retq 14: 0f .byte 0xf 15: 1f (bad) (gdb) list *(_raw_spin_lock+0x7) 0xffffffff81a13b27 is in _raw_spin_lock (./arch/x86/include/asm/atomic.h:200). 195 } 196 197 #define arch_atomic_try_cmpxchg arch_atomic_try_cmpxchg 198 static __always_inline bool arch_atomic_try_cmpxchg(atomic_t *v, int *old, int new) 199 { 200 return try_cmpxchg(&v->counter, old, new); 201 } 202 203 static inline int arch_atomic_xchg(atomic_t *v, int new) 204 { (gdb) disassemble _raw_spin_lock+0x7 Dump of assembler code for function _raw_spin_lock: 0xffffffff81a13b20 <+0>: xor %eax,%eax 0xffffffff81a13b22 <+2>: mov $0x1,%edx 0xffffffff81a13b27 <+7>: lock cmpxchg %edx,(%rdi) 0xffffffff81a13b2b <+11>: jne 0xffffffff81a13b2e <_raw_spin_lock+14> 0xffffffff81a13b2d <+13>: retq 0xffffffff81a13b2e <+14>: push %rbp 0xffffffff81a13b2f <+15>: mov %eax,%esi 0xffffffff81a13b31 <+17>: mov %rsp,%rbp 0xffffffff81a13b34 <+20>: callq 0xffffffff810ecb20 <queued_spin_lock_slowpath> 0xffffffff81a13b39 <+25>: pop %rbp 0xffffffff81a13b3a <+26>: retq End of assembler dump. Any pointers on how to proceed with this would be appreciated. See the files attached for copies of my .config and output of ver_linux.

4 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019