* Linux 5.10-rc4 @ 2020-11-16 0:59 Linus Torvalds 2020-11-18 12:12 ` David Laight 0 siblings, 1 reply; 22+ messages in thread From: Linus Torvalds @ 2020-11-16 0:59 UTC (permalink / raw) To: Linux Kernel Mailing List We're getting to the point in the rc series where I start hoping for things to calm down. 5.10 hasn't calmed down yet, and there's a fair amount of small noise all over the place. Nothing that makes me particularly worried, and honestly, with about a third of the patch being various selftest updates and fixes some of that noise is certainly welcome, but I'm hoping next week will start seeing less actual changes. Anyway, if you ignore the Documentation, tooling and selftest changes, about half of this is various minor driver updates (really all over the place), with the rest being a mix of architecture (arm64 and x86), filesystem fixes, and minor core kernel and vm changes. All looks good, and nothing makes me go "uhhuh, 5.10 looks iffy". So go test, let's get this all solid and calmed down, and this will hopefully be one of those regular boring releases even if it's certainly not been on the smaller side... Linus --- Aaron Lewis (3): selftests: kvm: Fix the segment descriptor layout to match the actual layout selftests: kvm: Clear uc so UCALL_NONE is being properly reported selftests: kvm: Add exception handling to selftests Al Viro (1): don't dump the threads that had been already exiting when zapped. Alexander A. Klimov (1): tools/power turbostat: Replace HTTP links with HTTPS ones: TURBOSTAT UTILITY Alexander Kapshuk (1): drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depth Alexander Lobakin (4): virtio: virtio_console: fix DMA memory allocation for rproc serial ethtool: netlink: add missing netdev_features_change() call net: udp: fix UDP header access on Fast/frag0 UDP GRO net: udp: fix IP header access and skb lookup on Fast/frag0 UDP GRO Alexander Monakov (1): tools/power turbostat: Build with _FILE_OFFSET_BITS=64 Alexander Usyskin (1): mei: protect mei_cl_mtu from null dereference Anand Jain (1): btrfs: dev-replace: fail mount if we don't have replace item with target device Andra Paraschiv (1): nitro_enclaves: Fixup type and simplify logic of the poll mask setup Andrew Jeffery (1): ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template Andrew Jones (9): KVM: arm64: Don't hide ID registers from userspace KVM: arm64: Consolidate REG_HIDDEN_GUEST/USER KVM: arm64: Check RAZ visibility in ID register accessors KVM: arm64: Remove AA64ZFR0_EL1 accessors KVM: selftests: Add aarch64 get-reg-list test KVM: selftests: Add blessed SVE registers to get-reg-list KVM: selftests: Drop pointless vm_create wrapper KVM: selftests: Make the per vcpu memory size global KVM: selftests: Make the number of vcpus global Andrey Konovalov (1): MAINTAINERS: add usb raw gadget entry Andrii Nakryiko (2): selftest/bpf: Fix profiler test using CO-RE relocation for enums bpf: Add struct bpf_redir_neigh forward declaration to BPF helper defs Andy Shevchenko (7): pinctrl: intel: Fix 2 kOhm bias which is 833 Ohm pinctrl: intel: Set default bias in case no particular value given pinctrl: mcp23s08: Use full chunk of memory for regmap configuration pinctrl: mcp23s08: Print error message when regmap init fails Documentation: firmware-guide: gpio-properties: Fix factual mistakes Documentation: firmware-guide: gpio-properties: active_low only for GpioIo() Documentation: firmware-guide: gpio-properties: Clarify initial output state Anshuman Khandual (1): arm64/mm: Validate hotplug range before creating linear mapping Antti Laakso (1): tools/power turbostat: Remove empty columns for Jacobsville Ard Biesheuvel (1): bpf: Don't rely on GCC __attribute__((optimize)) to disable GCSE Arnaud de Turckheim (3): gpio: pcie-idio-24: Fix irq mask when masking gpio: pcie-idio-24: Fix IRQ Enable Register value gpio: pcie-idio-24: Enable PEX8311 interrupts Arnd Bergmann (6): asm-generic: percpu: avoid Wshadow warning bpf: Fix -Wshadow warnings clk: define to_clk_regmap() as inline function habanalabs: fix kernel pointer type firmware: xilinx: fix out-of-bounds access perf/x86/intel/uncore: Fix Add BW copypasta Arvind Sankar (1): compiler.h: fix barrier_data() on clang Aya Levin (1): net/mlx5e: Fix VXLAN synchronization after function reload Babu Moger (2): KVM: x86: Introduce cr3_lm_rsvd_bits in kvm_vcpu_arch KVM: SVM: Update cr3_lm_rsvd_bits for AMD SEV guests Ben Gardon (5): KVM: selftests: Factor code out of demand_paging_test KVM: selftests: Remove address rounding in guest code KVM: selftests: Simplify demand_paging_test with timespec_diff_now KVM: selftests: Add wrfract to common guest code KVM: selftests: Introduce the dirty log perf test Ben Skeggs (1): drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50 Bhawanpreet Lakha (1): drm/amd/display: Add missing pflip irq Billy Tsai (2): gpio: aspeed: fix ast2600 bank properties pinctrl: aspeed: Fix GPI only function problem. Bjorn Andersson (1): pinctrl: qcom: sm8250: Specify PDC map Bob Peterson (2): Revert "gfs2: Ignore journal log writes for jdata holes" gfs2: Fix case in which ail writes are done to jdata holes Boqun Feng (1): lockdep: Avoid to modify chain keys in validate_chain() Brad Campbell (1): hwmon: (applesmc) Re-work SMC comms Can Guo (2): scsi: ufs: Fix unbalanced scsi_block_reqs_cnt caused by ufshcd_hold() scsi: ufs: Try to save power mode change and UIC cmd completion timeout Casey Bowman (1): thunderbolt: Add uaccess dependency to debugfs interface Chao Yu (1): MAINTAINERS: add missing file in ext4 entry Chen Yu (3): tools/power turbostat: Make the energy variable to be 64 bit tools/power turbostat: Introduce functions to accumulate RAPL consumption tools/power turbostat: Enable accumulate RAPL display Chen Zhou (1): selinux: Fix error return code in sel_ib_pkey_sid_slow() Chris Brandt (1): usb: cdc-acm: Add DISABLE_ECHO for Renesas USB Download mode Chris Wilson (1): drm/i915/gem: Pull phys pread/pwrite implementations to the backend Christoph Hellwig (4): swiotlb: remove the tbl_dma_addr argument to swiotlb_tbl_map_single nbd: fix a block_device refcount leak in nbd_release xfs: fix a missing unlock on error in xfs_fs_map_blocks block: add a return value to set_capacity_revalidate_and_notify Christophe Leroy (1): panic: don't dump stack twice on warn Chuck Lever (4): NFSD: NFSv3 PATHCONF Reply is improperly formed SUNRPC: Fix general protection fault in trace_rpc_xdr_overflow() NFSD: MKNOD should return NFSERR_BADTYPE instead of NFSERR_INVAL NFS: Fix listxattr receive buffer size Coiby Xu (2): pinctrl: amd: fix incorrect way to disable debounce filter pinctrl: amd: use higher precision for 512 RtcClk Colin Ian King (1): sched/debug: Fix memory corruption caused by multiple small reads of flags Dai Ngo (2): NFSD: Fix use-after-free warning when doing inter-server copy NFSD: fix missing refcount in nfsd4_copy by nfsd4_do_async_copy Damien Le Moal (1): gpio: sifive: Fix SiFive gpio probe Dan Carpenter (7): hwmon: (pmbus/max20730) use scnprintf() instead of snprintf() btrfs: clean up NULL checks in qgroup_unreserve_range() net/sunrpc: return 0 on attempt to write to "transports" ext4: silence an uninitialized variable warning net/sunrpc: fix useless comparison in proc_do_xprt() futex: Don't enable IRQs unconditionally in put_pi_state() i40e, xsk: uninitialized variable in i40e_clean_rx_irq_zc() Darrick J. Wong (7): xfs: fix flags argument to rmap lookup when converting shared file rmaps xfs: set the unwritten bit in rmap lookup flags in xchk_bmap_get_rmapextents xfs: fix rmap key and record comparison functions xfs: fix brainos in the refcount scrubber's rmap fragment processor vfs: remove lockdep bogosity in __sb_start_write vfs: separate __sb_start_write into blocking and non-blocking helpers vfs: move __sb_{start,end}_write* to fs.h David Arcari (1): tools/power turbostat: Fix output formatting for ACPI CST enumeration David Edmondson (1): KVM: x86: clflushopt should be treated as a no-op by emulation David Howells (1): afs: Fix afs_write_end() when called with copied == 0 [ver #3] David Sterba (1): btrfs: scrub: update message regarding read-only status David Verbeiren (1): bpf: Zero-fill re-used per-cpu map element Dennis Zhou (1): percpu: convert flexible array initializers to use struct_size() Dinghao Liu (1): btrfs: ref-verify: fix memory leak in btrfs_ref_tree_mod Dmitry Baryshkov (1): mailmap: fix entry for Dmitry Baryshkov/Eremin-Solenikov Doug Smythies (1): tools/power turbostat: Always print idle in the system configuration header Eric Biggers (2): fscrypt: remove reachable WARN in fscrypt_setup_iv_ino_lblk_32_key() fscrypt: fix inline encryption not used on new files Evan Nimmo (1): of/address: Fix of_node memory leak in of_dma_is_coherent Flavio Suligoi (1): Documentation: ACPI: fix spelling mistakes Gao Xiang (2): erofs: derive atime instead of leaving it empty erofs: fix setting up pcluster for temporary pages Gavin Shan (1): KVM: arm64: Fix build error in user_mem_abort() Geert Uytterhoeven (1): Revert "usb: musb: convert to devm_platform_ioremap_resource_byname" Hans de Goede (1): ACPI: button: Add DMI quirk for Medion Akoya E2228T Harshad Shirwadkar (23): ext4: describe fast_commit feature flags ext4: mark fc ineligible if inode gets evictied due to mem pressure ext4: drop redundant calls ext4_fc_track_range ext4: fixup ext4_fc_track_* functions' signature jbd2: rename j_maxlen to j_total_len and add jbd2_journal_max_txn_bufs ext4: clean up the JBD2 API that initializes fast commits jbd2: drop jbd2_fc_init documentation jbd2: don't use state lock during commit path jbd2: don't pass tid to jbd2_fc_end_commit_fallback() jbd2: add todo for a fast commit performance optimization jbd2: don't touch buffer state until it is filled jbd2: don't read journal->j_commit_sequence without taking a lock ext4: dedpulicate the code to wait on inode that's being committed ext4: fix code documentatioon ext4: mark buf dirty before submitting fast commit buffer ext4: remove unnecessary fast commit calls from ext4_file_mmap ext4: fix inode dirty check in case of fast commits ext4: disable fast commit with data journalling ext4: issue fsdev cache flush before starting fast commit ext4: make s_mount_flags modifications atomic jbd2: don't start fast commit on aborted journal ext4: cleanup fast commit mount options ext4: handle dax mount option collision Heikki Krogerus (1): usb: typec: ucsi: Report power supply changes Heiner Kallweit (3): r8169: fix potential skb double free in an error path r8169: disable hw csum for short packets on all chip versions net: phy: realtek: support paged operations on RTL8201CP Helge Deller (1): nfsroot: Default mount option should ask for built-in NFS version Ian Rogers (3): tools, bpftool: Avoid array index warnings. tools, bpftool: Remove two unused variables. libbpf, hashmap: Fix undefined behavior in hash_bits J. Bruce Fields (1): NFSv4.2: fix failure to unregister shrinker Jakub Kicinski (1): net: switch to the kernel.org patchwork instance Jason Gunthorpe (1): mm/gup: use unpin_user_pages() in __gup_longterm_locked() Jens Axboe (1): io_uring: round-up cq size before comparing with rounded sq size Jia He (1): gpio: dwapb: Fix missing conversion to GPIO-lib-based IRQ-chip Jianqun Xu (2): pinctrl: rockchip: enable gpio pclk for rockchip_gpio_to_irq pinctrl: rockchip: create irq mapping in gpio_to_irq Jing Xiangfeng (1): thunderbolt: Add the missed ida_simple_remove() in ring_request_msix() Jiri Slaby (1): x86/platform/uv: Drop last traces of uv_flush_tlb_others John Garry (1): ACPI: scan: Fix acpi_dma_configure_id() kerneldoc name Jonathan Neuschäfer (1): docs: networking: phy: s/2.5 times faster/2.5 times as fast/ Josef Bacik (2): btrfs: print the block rsv type when we fail our reservation btrfs: fix min reserved size calculation in merge_reloc_root Joseph Qi (1): ext4: unlock xattr_sem properly in ext4_inline_data_truncate() KP Singh (1): bpf: Update verification logic for LSM programs Kaixu Xia (1): ext4: correctly report "not supported" for {usr,grp}jquota when !CONFIG_QUOTA Kent Gibson (6): gpio: uapi: fix kernel-doc warnings gpio: uapi: comment consistency gpio: uapi: kernel-doc formatting improvements gpio: uapi: remove whitespace gpio: uapi: clarify the meaning of 'empty' char arrays gpiolib: fix sysfs when cdev is not selected Kim Phillips (1): tools/power turbostat: Support AMD Family 19h Konrad Dybcio (4): arm64: Add MIDR value for KRYO2XX gold/silver CPU cores arm64: kpti: Add KRYO2XX gold/silver CPU cores to kpti safelist arm64: proton-pack: Add KRYO2XX silver CPUs to spectre-v2 safe-list arm64: cpu_errata: Apply Erratum 845719 to KRYO2XX Silver Laurent Dufour (1): mm/slub: fix panic in slab_alloc_node() Len Brown (7): tools/power turbostat: Print /dev/cpu_dma_latency tools/power turbostat: Support additional CPU model numbers tools/power turbostat: Skip pc8, pc9, pc10 columns, if they are disabled tools/power turbostat: adjust for temperature offset tools/power turbostat: harden against cpu hotplug powercap: restrict energy meter to root access tools/power turbostat: update version number Li RongQing (1): KVM: x86/mmu: fix counting of rmap entries in pte_list_add Linus Torvalds (1): Linux 5.10-rc4 Linus Walleij (1): drm/mcde: Fix unbalanced regulator Lorenz Bauer (1): tools/bpftool: Fix attaching flow dissector Lyude Paul (1): drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere Magnus Karlsson (3): xsk: Fix possible memory leak at socket close libbpf: Fix null dereference in xsk_socket__delete libbpf: Fix possible use after free in xsk_socket__delete Mao Wenan (1): net: Update window_clamp if SOCK_RCVBUF is set Maor Dickman (1): net/mlx5e: Fix modify header actions memory leak Maor Gottlieb (1): net/mlx5: Fix deletion of duplicate rules Marc Kleine-Budde (3): dt-bindings: can: fsl,flexcan.yaml: fix fsl,stop-mode dt-bindings: can: fsl,flexcan.yaml: fix compatible for i.MX35 and i.MX53 dt-bindings: clock: imx5: fix example Marc Zyngier (3): KVM: arm64: Allow setting of ID_AA64PFR0_EL1.CSV2 from userspace KVM: arm64: Unify trap handlers injecting an UNDEF KVM: arm64: Handle SCXTNUM_ELx traps Martin Schiller (1): net/x25: Fix null-ptr-deref in x25_connect Martin Willi (1): vrf: Fix fast path output packet handling with async Netfilter rules Masami Hiramatsu (1): bootconfig: Extend the magic check range to the preceding 3 bytes Matteo Croce (2): Revert "kernel/reboot.c: convert simple_strtoul to kstrtoint" reboot: fix overflow parsing reboot cpu number Matthew Auld (1): drm/i915/gem: Allow backends to override pread implementation Matthew Wilcox (Oracle) (1): btrfs: fix potential overflow in cluster_pages_for_defrag on 32bit arch Maulik Shah (1): pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback Maxim Levitsky (1): KVM: x86: use positive error values for msr emulation that causes #GP Maxim Mikityanskiy (2): net/mlx5e: Use spin_lock_bh for async_icosq_lock net/mlx5e: Fix incorrect access of RCU-protected xdp_prog Maximilian Luz (1): ACPI: Fix whitespace inconsistencies Michael Walle (1): arm64: dts: fsl-ls1028a-kontron-sl28: specify in-band mode for ENETC Mika Westerberg (3): thunderbolt: Fix memory leak if ida_simple_get() fails in enumerate_services() thunderbolt: Only configure USB4 wake for lane 0 adapters thunderbolt: Add support for Intel Tiger Lake-H Mike Kravetz (1): hugetlbfs: fix anon huge page migration race Mike Travis (1): x86/platform/uv: Fix copied UV5 output archtype Muchun Song (1): mm: memcontrol: fix missing wakeup polling thread Naveen Krishna Chatradhi (1): hwmon: (amd_energy) modify the visibility of the counters Nicholas Piggin (1): mm/vmscan: fix NR_ISOLATED_FILE corruption on 64-bit Nick Desaulniers (1): ACPI: GED: fix -Wformat Nishanth Menon (1): drm: bridge: cdns: Kconfig: Switch over dependency to ARCH_K3 Oded Gabbay (1): habanalabs/gaudi: mask WDT error in QMAN Ofir Bitton (1): habanalabs/gaudi: move coresight mmu config Olaf Hering (1): video: hyperv_fb: include vmalloc.h Oliver Herms (1): IPv6: Set SIT tunnel hard_header_len to zero Oliver Upton (4): kvm: x86: reads of restricted pv msrs should also result in #GP kvm: x86: ensure pv_cpuid.features is initialized when enabling cap kvm: x86: request masterclock update any time guest uses different msr selftests: kvm: test enforcement of paravirtual cpuid features Ondřej Lysoněk (1): tools/power x86_energy_perf_policy: Input/output error in a VM Pankaj Gupta (1): KVM: x86: handle MSR_IA32_DEBUGCTLMSR with report_ignored_msrs Paolo Abeni (1): mptcp: provide rmem[0] limit Paolo Bonzini (2): KVM: selftests: allow two iterations of dirty_log_perf_test kvm: mmu: fix is_tdp_mmu_check when the TDP MMU is not in use Parav Pandit (2): net/mlx5: E-switch, Avoid extack error log for disabled vport devlink: Avoid overwriting port attributes of registered port Paul Barker (1): hwmon: (pwm-fan) Fix RPM calculation Paul Cercueil (1): pinctrl: ingenic: Fix invalid SSI pins Paul Moore (1): netlabel: fix our progress tracking in netlbl_unlabel_staticlist() Peng Fan (1): clk: imx8m: fix bus critical clk registration Peter Xu (4): KVM: Documentation: Update entry for KVM_X86_SET_MSR_FILTER KVM: Documentation: Update entry for KVM_CAP_ENFORCE_PV_CPUID KVM: selftests: Always clear dirty bitmap after iteration KVM: selftests: Use a single binary for dirty/clear log test Peter Zijlstra (10): perf: Reduce stack usage of perf_output_begin() perf/x86: Reduce stack usage for x86_pmu::drain_pebs() perf: Fix get_recursion_context() perf: Optimize get_recursion_context() perf/arch: Remove perf_sample_data::regs_user_copy perf/x86: Make dummy_iregs static perf: Simplify group_sched_out() perf: Simplify group_sched_in() perf: Fix event multiplexing for exclusive groups perf: Tweak perf_event_attr::exclusive semantics Petr Vorel (1): loop: Fix occasional uevent drop Prarit Bhargava (1): tools/power turbostat: Use sched_getcpu() instead of hardcoded cpu 0 Qinglang Miao (1): scsi: ufshcd: Fix missing destroy_workqueue() Rafael Antognolli (1): tools/power turbostat: Add a new GFXAMHz column that exposes gt_act_freq_mhz. Rafael J. Wysocki (4): cpufreq: Introduce governor flags cpufreq: Introduce CPUFREQ_GOV_STRICT_TARGET cpufreq: Add strict_target to struct cpufreq_policy cpufreq: intel_pstate: Take CPUFREQ_GOV_STRICT_TARGET into account Randy Dunlap (1): bpf: BPF_PRELOAD depends on BPF_SYSCALL Richard Weinberger (1): um: Call pgtable_pmd_page_dtor() in __pmd_free_tlb() Robert Hancock (1): hwmon: (pmbus) Add mutex locking for sysfs reads Rohit Maheshwari (12): cxgb4/ch_ktls: decrypted bit is not enough ch_ktls: Correction in finding correct length ch_ktls: Update cheksum information cxgb4/ch_ktls: creating skbs causes panic ch_ktls: Correction in trimmed_len calculation ch_ktls: missing handling of header alone ch_ktls: Correction in middle record handling ch_ktls: packet handling prior to start marker ch_ktls: don't free skb before sending FIN ch_ktls/cxgb4: handle partial tag alone SKBs ch_ktls: tcb update fails sometimes ch_ktls: stop the txq if reaches threshold Roman Li (1): drm/amdgpu: add ta firmware load for green-sardine Sagi Grimberg (1): nvme: fix incorrect behavior when BLKROSET is called by the user Samuel Thibault (3): speakup: Fix var_id_t values and thus keymap speakup: Fix clearing selection in safe context speakup ttyio: Do not schedule() in ttyio_in_nowait Santosh Sivaraj (1): kernel/watchdog: fix watchdog_allowed_mask not used warning Shin'ichiro Kawasaki (1): uio: Fix use-after-free in uio_unregister_device() Slawomir Laba (1): i40e: Fix MAC address setting for a VF via Host/VM Srinivas Pandruvada (1): ACPI: DPTF: Support Alder Lake Stefano Brivio (1): tunnels: Fix off-by-one in lower MTU bounds for ICMP/ICMPv6 replies Stefano Stabellini (1): swiotlb: fix "x86: Don't panic if can not alloc buffer for swiotlb" Stephane Eranian (1): perf/x86/intel: Make anythread filter support conditional Sven Van Asbroeck (3): lan743x: correctly handle chips with internal PHY lan743x: fix "BUG: invalid wait context" when setting rx mode lan743x: fix use of uninitialized variable Theodore Ts'o (3): ext4: fix sparse warnings in fast_commit code jbd2: fix up sparse warnings in checkpoint code Revert "ext4: fix superblock checksum calculation race" Thomas Gleixner (1): iommu/vt-d: Cure VF irqdomain hickup Thomas Zimmermann (1): drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[] Tianci.Yin (1): drm/amdgpu: enable DCN for navi10 headless SKU Toke Høiland-Jørgensen (1): samples/bpf: Set rlimit for memlock to infinity in all samples Tony Lindgren (1): Revert "Revert "gpio: omap: Fix lost edge wake-up interrupts"" Tony Nguyen (1): MAINTAINERS: Update repositories for Intel Ethernet Drivers Trond Myklebust (2): NFS: Remove unnecessary inode locking in nfs_llseek_dir() NFS: Remove unnecessary inode lock in nfs_fsync_dir() Ursula Braun (2): net/af_iucv: fix null pointer dereference on shutdown MAINTAINERS: remove Ursula Braun as s390 network maintainer Vadym Kochan (1): net: marvell: prestera: fix compilation with CONFIG_BRIDGE=m Venkata Sandeep Dhanalakota (1): drm/i915: Correctly set SFC capability for video engines Vincent Guittot (2): sched/fair: Ensure tasks spreading in LLC during LB sched/fair: Prefer prev cpu in asymmetric wakeup path Vinicius Costa Gomes (1): igc: Fix returning wrong statistics Vlad Buslov (2): net/mlx5e: Protect encap route dev from concurrent release selftest: fix flower terse dump tests Wang Hai (2): tipc: fix memory leak in tipc_topsrv_start() cosa: Add missing kfree in error path of cosa_write Wengang Wang (1): ocfs2: initialize ip_next_orphan Will Deacon (4): arm64: errata: Fix handling of 1418040 with late CPU onlining arm64: kexec_file: Fix sparse warning arm64: psci: Avoid printing in cpu_psci_cpu_die() arm64: smp: Tell RCU about CPUs that fail to come online Wolfram Sang (3): mmc: tmio: when resetting, reset DMA controller, too mmc: tmio: bring tuning HW to a sane state with MMC_POWER_OFF Revert "mmc: renesas_sdhi: workaround a regression when reinserting SD cards" Yangbo Lu (1): mmc: sdhci-of-esdhc: Handle pulse width detection erratum for more SoCs Yoshihiro Shimoda (1): mmc: renesas_sdhi_core: Add missing tmio_mmc_host_free() at remove Zhang Qilong (2): gfs2: fix possible reference leak in gfs2_check_blk_type xhci: hisilicon: fix refercence leak in xhci_histb_probe Zi Yan (2): mm/compaction: count pages and stop correctly during page isolation mm/compaction: stop isolation if too many pages are isolated and we have pages to migrate zhangxiaoxu (1): net: dsa: mv88e6xxx: Fix memleak in mv88e6xxx_region_atu_snapshot ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Linux 5.10-rc4 2020-11-16 0:59 Linux 5.10-rc4 Linus Torvalds @ 2020-11-18 12:12 ` David Laight 2020-11-18 18:10 ` Linus Torvalds 0 siblings, 1 reply; 22+ messages in thread From: David Laight @ 2020-11-18 12:12 UTC (permalink / raw) To: 'Linus Torvalds', Linux Kernel Mailing List From: Linus Torvalds > Sent: 16 November 2020 00:59 > > All looks good, and nothing makes me go "uhhuh, 5.10 looks iffy". So > go test, let's get this all solid and calmed down, and this will > hopefully be one of those regular boring releases even if it's > certainly not been on the smaller side... I've got the 'splat' below during boot. This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. User space is Ubuntu 20.04. Additionally the X display has all the colours and alignment slightly messed up. 5.9.0 was ok. I'm just guessing the two issues are related. David [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 87 18 06 [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 [ 20.988047] Call Trace: [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] [ 21.079401] __x64_sys_ioctl+0x91/0xc0 [ 21.083167] do_syscall_64+0x38/0x90 [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 21.091813] RIP: 0033:0x7f5b3cf1350b [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48 [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 2020-11-18 12:12 ` David Laight @ 2020-11-18 18:10 ` Linus Torvalds 0 siblings, 0 replies; 22+ messages in thread From: Linus Torvalds @ 2020-11-18 18:10 UTC (permalink / raw) To: David Laight, Thomas Zimmermann Cc: Linux Kernel Mailing List, Daniel Vetter, Dave Airlie, dri-devel On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > I've got the 'splat' below during boot. > This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > User space is Ubuntu 20.04. > > Additionally the X display has all the colours and alignment slightly > messed up. > 5.9.0 was ok. > I'm just guessing the two issues are related. Sounds likely. But it would be lovely if you could bisect when exactly the problem(s) started to both verify that, and just to pinpoint the exact change.. I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: Program display mode in CRTC's atomic_enable" which looks relevant in that it's right in that call-chain. Did some initialization perhaps get overlooked? And Dave and Daniel and the drm list cc'd as well.. Full splat left quoted below for new people and list. Linus > [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit > [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 > [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 > [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 87 18 06 > [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 > [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 > [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 > [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 > [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 > [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 > [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 > [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 > [ 20.988047] Call Trace: > [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] > [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] > [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] > [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] > [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] > [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] > [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] > [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] > [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] > [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] > [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] > [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 > [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] > [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] > [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] > [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > [ 21.079401] __x64_sys_ioctl+0x91/0xc0 > [ 21.083167] do_syscall_64+0x38/0x90 > [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 21.091813] RIP: 0033:0x7f5b3cf1350b > [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48 > [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b > [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 > [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 > [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 > [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 @ 2020-11-18 18:10 ` Linus Torvalds 0 siblings, 0 replies; 22+ messages in thread From: Linus Torvalds @ 2020-11-18 18:10 UTC (permalink / raw) To: David Laight, Thomas Zimmermann Cc: Daniel Vetter, Linux Kernel Mailing List, dri-devel, Dave Airlie On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > I've got the 'splat' below during boot. > This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > User space is Ubuntu 20.04. > > Additionally the X display has all the colours and alignment slightly > messed up. > 5.9.0 was ok. > I'm just guessing the two issues are related. Sounds likely. But it would be lovely if you could bisect when exactly the problem(s) started to both verify that, and just to pinpoint the exact change.. I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: Program display mode in CRTC's atomic_enable" which looks relevant in that it's right in that call-chain. Did some initialization perhaps get overlooked? And Dave and Daniel and the drm list cc'd as well.. Full splat left quoted below for new people and list. Linus > [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit > [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 > [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 > [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 87 18 06 > [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 > [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 > [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 > [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 > [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 > [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 > [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 > [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 > [ 20.988047] Call Trace: > [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] > [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] > [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] > [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] > [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] > [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] > [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] > [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] > [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] > [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] > [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] > [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 > [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] > [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] > [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] > [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > [ 21.079401] __x64_sys_ioctl+0x91/0xc0 > [ 21.083167] do_syscall_64+0x38/0x90 > [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 21.091813] RIP: 0033:0x7f5b3cf1350b > [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48 > [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b > [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 > [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 > [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 > [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Linux 5.10-rc4 2020-11-18 18:10 ` Linus Torvalds @ 2020-11-18 19:00 ` David Laight -1 siblings, 0 replies; 22+ messages in thread From: David Laight @ 2020-11-18 19:00 UTC (permalink / raw) To: 'Linus Torvalds', Thomas Zimmermann Cc: Linux Kernel Mailing List, Daniel Vetter, Dave Airlie, dri-devel From: Linus Torvalds > Sent: 18 November 2020 18:11 > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > > > I've got the 'splat' below during boot. > > This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > User space is Ubuntu 20.04. > > > > Additionally the X display has all the colours and alignment slightly > > messed up. > > 5.9.0 was ok. > > I'm just guessing the two issues are related. > > Sounds likely. But it would be lovely if you could bisect when > exactly the problem(s) started to both verify that, and just to > pinpoint the exact change.. I'm working on it - have been all afternoon. (I'm on holiday and it is raining...) 5.10-rc1 fails, so it is something in the merge window. I suspect I'll just hit the pull of the drm changes. The bisect suddenly build a 5.9-rc5+ kernel! So I'm retesting a good/bad pair with likely dates and will restart it. Annoyingly the test system defaults to booting the highest version kernel - not the one I've just build; I may have given it a wrong answer. The builds also all take 20 minutes; so the bisect is slow. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Linux 5.10-rc4 @ 2020-11-18 19:00 ` David Laight 0 siblings, 0 replies; 22+ messages in thread From: David Laight @ 2020-11-18 19:00 UTC (permalink / raw) To: 'Linus Torvalds', Thomas Zimmermann Cc: Daniel Vetter, Linux Kernel Mailing List, dri-devel, Dave Airlie From: Linus Torvalds > Sent: 18 November 2020 18:11 > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > > > I've got the 'splat' below during boot. > > This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > User space is Ubuntu 20.04. > > > > Additionally the X display has all the colours and alignment slightly > > messed up. > > 5.9.0 was ok. > > I'm just guessing the two issues are related. > > Sounds likely. But it would be lovely if you could bisect when > exactly the problem(s) started to both verify that, and just to > pinpoint the exact change.. I'm working on it - have been all afternoon. (I'm on holiday and it is raining...) 5.10-rc1 fails, so it is something in the merge window. I suspect I'll just hit the pull of the drm changes. The bisect suddenly build a 5.9-rc5+ kernel! So I'm retesting a good/bad pair with likely dates and will restart it. Annoyingly the test system defaults to booting the highest version kernel - not the one I've just build; I may have given it a wrong answer. The builds also all take 20 minutes; so the bisect is slow. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 2020-11-18 18:10 ` Linus Torvalds @ 2020-11-18 19:36 ` Thomas Zimmermann -1 siblings, 0 replies; 22+ messages in thread From: Thomas Zimmermann @ 2020-11-18 19:36 UTC (permalink / raw) To: Linus Torvalds, David Laight Cc: Linux Kernel Mailing List, Daniel Vetter, Dave Airlie, dri-devel, Christian König, Huang, Ray [-- Attachment #1.1.1: Type: text/plain, Size: 6048 bytes --] Hi Am 18.11.20 um 19:10 schrieb Linus Torvalds: > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: >> >> I've got the 'splat' below during boot. >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. >> User space is Ubuntu 20.04. >> >> Additionally the X display has all the colours and alignment slightly >> messed up. >> 5.9.0 was ok. >> I'm just guessing the two issues are related. > > Sounds likely. But it would be lovely if you could bisect when > exactly the problem(s) started to both verify that, and just to > pinpoint the exact change.. > > I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: > Program display mode in CRTC's atomic_enable" which looks relevant in > that it's right in that call-chain. > > Did some initialization perhaps get overlooked? > > And Dave and Daniel and the drm list cc'd as well.. > > Full splat left quoted below for new people and list. > > Linus > >> [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] That line is at [1], which comes from 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") But the patch was merged in 5.9-rc1, so it's probably something else. We've had a lot of TTM-related changes recently, so my best guess is that it's something in TTM with BO initialization. From some grepping, it looks like we have to call ttm_bo_mem_space() to fill mm_node (i.e., the pointer that causes the warning). But I cannot find where vram helpers do this. Maybe that's a good starting point. I'm adding the TTM devs to cc. Best regards Thomas [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_helper.c?h=v5.10-rc4#n284 >> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit >> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 >> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 >> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] >> [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 87 18 06 >> [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 >> [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 >> [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 >> [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 >> [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 >> [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 >> [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 >> [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 >> [ 20.988047] Call Trace: >> [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] >> [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] >> [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] >> [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] >> [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] >> [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] >> [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] >> [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] >> [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] >> [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] >> [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] >> [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 >> [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] >> [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] >> [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] >> [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] >> [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] >> [ 21.079401] __x64_sys_ioctl+0x91/0xc0 >> [ 21.083167] do_syscall_64+0x38/0x90 >> [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> [ 21.091813] RIP: 0033:0x7f5b3cf1350b >> [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48 >> [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 >> [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b >> [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 >> [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 >> [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 >> [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.1.2: OpenPGP_0x680DC11D530B7A23.asc --] [-- Type: application/pgp-keys, Size: 7535 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 @ 2020-11-18 19:36 ` Thomas Zimmermann 0 siblings, 0 replies; 22+ messages in thread From: Thomas Zimmermann @ 2020-11-18 19:36 UTC (permalink / raw) To: Linus Torvalds, David Laight Cc: Daniel Vetter, Linux Kernel Mailing List, dri-devel, Huang, Ray, Dave Airlie, Christian König [-- Attachment #1.1.1.1: Type: text/plain, Size: 6048 bytes --] Hi Am 18.11.20 um 19:10 schrieb Linus Torvalds: > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: >> >> I've got the 'splat' below during boot. >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. >> User space is Ubuntu 20.04. >> >> Additionally the X display has all the colours and alignment slightly >> messed up. >> 5.9.0 was ok. >> I'm just guessing the two issues are related. > > Sounds likely. But it would be lovely if you could bisect when > exactly the problem(s) started to both verify that, and just to > pinpoint the exact change.. > > I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: > Program display mode in CRTC's atomic_enable" which looks relevant in > that it's right in that call-chain. > > Did some initialization perhaps get overlooked? > > And Dave and Daniel and the drm list cc'd as well.. > > Full splat left quoted below for new people and list. > > Linus > >> [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] That line is at [1], which comes from 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") But the patch was merged in 5.9-rc1, so it's probably something else. We've had a lot of TTM-related changes recently, so my best guess is that it's something in TTM with BO initialization. From some grepping, it looks like we have to call ttm_bo_mem_space() to fill mm_node (i.e., the pointer that causes the warning). But I cannot find where vram helpers do this. Maybe that's a good starting point. I'm adding the TTM devs to cc. Best regards Thomas [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_helper.c?h=v5.10-rc4#n284 >> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit >> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 >> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 >> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] >> [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 87 18 06 >> [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 >> [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 >> [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 >> [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 >> [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 >> [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 >> [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 >> [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 >> [ 20.988047] Call Trace: >> [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] >> [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] >> [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] >> [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] >> [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] >> [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] >> [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] >> [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] >> [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] >> [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] >> [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] >> [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 >> [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] >> [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] >> [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] >> [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] >> [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] >> [ 21.079401] __x64_sys_ioctl+0x91/0xc0 >> [ 21.083167] do_syscall_64+0x38/0x90 >> [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> [ 21.091813] RIP: 0033:0x7f5b3cf1350b >> [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48 >> [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 >> [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b >> [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 >> [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 >> [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 >> [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.1.1.2: OpenPGP_0x680DC11D530B7A23.asc --] [-- Type: application/pgp-keys, Size: 7535 bytes --] [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Linux 5.10-rc4 2020-11-18 19:36 ` Thomas Zimmermann @ 2020-11-18 22:01 ` David Laight -1 siblings, 0 replies; 22+ messages in thread From: David Laight @ 2020-11-18 22:01 UTC (permalink / raw) To: 'Thomas Zimmermann', Linus Torvalds Cc: Linux Kernel Mailing List, Daniel Vetter, Dave Airlie, dri-devel, Christian König, Huang, Ray From: Thomas Zimmermann > Sent: 18 November 2020 19:37 > > Hi > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > >> > >> I've got the 'splat' below during boot. > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > >> User space is Ubuntu 20.04. > >> > >> Additionally the X display has all the colours and alignment slightly > >> messed up. > >> 5.9.0 was ok. > >> I'm just guessing the two issues are related. > > > > Sounds likely. But it would be lovely if you could bisect when > > exactly the problem(s) started to both verify that, and just to > > pinpoint the exact change.. I don't quite understand what 'git bisect' did. I was bisecting between v5.9 and v5.10-rc1 but it suddenly started generating v5.9.0-rc5+ kernels. The identified commit was 13a8f46d803 drm/ttm: move ghost object created. (retyped - hope it is right). But the diff to that last 'good' commit is massive. So I don't know if that is anywhere near right. David > > > > I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: > > Program display mode in CRTC's atomic_enable" which looks relevant in > > that it's right in that call-chain. > > > > Did some initialization perhaps get overlooked? > > > > And Dave and Daniel and the drm list cc'd as well.. > > > > Full splat left quoted below for new people and list. > > > > Linus > > > >> [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 > drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > > That line is at [1], which comes from > > 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") > > But the patch was merged in 5.9-rc1, so it's probably something else. > > We've had a lot of TTM-related changes recently, so my best guess is > that it's something in TTM with BO initialization. > > From some grepping, it looks like we have to call ttm_bo_mem_space() to > fill mm_node (i.e., the pointer that causes the warning). But I cannot > find where vram helpers do this. Maybe that's a good starting point. > > I'm adding the TTM devs to cc. > > Best regards > Thomas > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h > elper.c?h=v5.10-rc4#n284 > > > >> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua > ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf > ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs > blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor > async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper > syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd > ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit > >> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 > >> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 > >> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > >> [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d > 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 > 48 8b 87 18 06 > >> [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 > >> [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 > >> [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 > >> [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 > >> [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 > >> [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 > >> [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 > >> [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > >> [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 > >> [ 20.988047] Call Trace: > >> [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] > >> [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] > >> [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] > >> [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] > >> [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] > >> [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] > >> [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] > >> [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] > >> [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] > >> [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] > >> [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] > >> [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 > >> [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > >> [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] > >> [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] > >> [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] > >> [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > >> [ 21.079401] __x64_sys_ioctl+0x91/0xc0 > >> [ 21.083167] do_syscall_64+0x38/0x90 > >> [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >> [ 21.091813] RIP: 0033:0x7f5b3cf1350b > >> [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 > 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 > d8 64 89 01 48 > >> [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > >> [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b > >> [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 > >> [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 > >> [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 > >> [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Linux 5.10-rc4 @ 2020-11-18 22:01 ` David Laight 0 siblings, 0 replies; 22+ messages in thread From: David Laight @ 2020-11-18 22:01 UTC (permalink / raw) To: 'Thomas Zimmermann', Linus Torvalds Cc: Daniel Vetter, Linux Kernel Mailing List, dri-devel, Huang, Ray, Dave Airlie, Christian König From: Thomas Zimmermann > Sent: 18 November 2020 19:37 > > Hi > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > >> > >> I've got the 'splat' below during boot. > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > >> User space is Ubuntu 20.04. > >> > >> Additionally the X display has all the colours and alignment slightly > >> messed up. > >> 5.9.0 was ok. > >> I'm just guessing the two issues are related. > > > > Sounds likely. But it would be lovely if you could bisect when > > exactly the problem(s) started to both verify that, and just to > > pinpoint the exact change.. I don't quite understand what 'git bisect' did. I was bisecting between v5.9 and v5.10-rc1 but it suddenly started generating v5.9.0-rc5+ kernels. The identified commit was 13a8f46d803 drm/ttm: move ghost object created. (retyped - hope it is right). But the diff to that last 'good' commit is massive. So I don't know if that is anywhere near right. David > > > > I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: > > Program display mode in CRTC's atomic_enable" which looks relevant in > > that it's right in that call-chain. > > > > Did some initialization perhaps get overlooked? > > > > And Dave and Daniel and the drm list cc'd as well.. > > > > Full splat left quoted below for new people and list. > > > > Linus > > > >> [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 > drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > > That line is at [1], which comes from > > 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") > > But the patch was merged in 5.9-rc1, so it's probably something else. > > We've had a lot of TTM-related changes recently, so my best guess is > that it's something in TTM with BO initialization. > > From some grepping, it looks like we have to call ttm_bo_mem_space() to > fill mm_node (i.e., the pointer that causes the warning). But I cannot > find where vram helpers do this. Maybe that's a good starting point. > > I'm adding the TTM devs to cc. > > Best regards > Thomas > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h > elper.c?h=v5.10-rc4#n284 > > > >> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua > ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf > ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs > blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor > async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper > syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd > ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit > >> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 > >> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 > >> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > >> [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d > 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 > 48 8b 87 18 06 > >> [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 > >> [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 > >> [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 > >> [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 > >> [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 > >> [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 > >> [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 > >> [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > >> [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 > >> [ 20.988047] Call Trace: > >> [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] > >> [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] > >> [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] > >> [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] > >> [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] > >> [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] > >> [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] > >> [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] > >> [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] > >> [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] > >> [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] > >> [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 > >> [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > >> [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] > >> [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] > >> [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] > >> [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > >> [ 21.079401] __x64_sys_ioctl+0x91/0xc0 > >> [ 21.083167] do_syscall_64+0x38/0x90 > >> [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >> [ 21.091813] RIP: 0033:0x7f5b3cf1350b > >> [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 > 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 > d8 64 89 01 48 > >> [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > >> [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b > >> [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 > >> [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 > >> [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 > >> [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 2020-11-18 22:01 ` David Laight @ 2020-11-18 22:15 ` Daniel Vetter -1 siblings, 0 replies; 22+ messages in thread From: Daniel Vetter @ 2020-11-18 22:15 UTC (permalink / raw) To: David Laight Cc: Thomas Zimmermann, Linus Torvalds, Linux Kernel Mailing List, Dave Airlie, dri-devel, Christian König, Huang, Ray On Wed, Nov 18, 2020 at 11:01 PM David Laight <David.Laight@aculab.com> wrote: > > From: Thomas Zimmermann > > Sent: 18 November 2020 19:37 > > > > Hi > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > >> > > >> I've got the 'splat' below during boot. > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > >> User space is Ubuntu 20.04. > > >> > > >> Additionally the X display has all the colours and alignment slightly > > >> messed up. > > >> 5.9.0 was ok. > > >> I'm just guessing the two issues are related. > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > exactly the problem(s) started to both verify that, and just to > > > pinpoint the exact change.. > > I don't quite understand what 'git bisect' did. > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > generating v5.9.0-rc5+ kernels. We queue up patches for -rc1 way before the previous kernel is released, so this is normal. > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > (retyped - hope it is right). > But the diff to that last 'good' commit is massive. Yeah that's also normal for non-linear history. If you want to double-check, re-test the parent of that commit (which is 2ee476f77ffe ("drm/ttm: add a simple assign mem to bo wrapper")), which should work, and then the bad commit. Also is this the first bad commit for both the splat and the screen corruption issues? > So I don't know if that is anywhere near right. Thomas guessed it could be a ttm change, you hit one, and it looks like it could be the culprit. Now I guess it's up to Dave. Also adding Christian, in case he has an idea. -Daniel > > David > > > > > > > I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: > > > Program display mode in CRTC's atomic_enable" which looks relevant in > > > that it's right in that call-chain. > > > > > > Did some initialization perhaps get overlooked? > > > > > > And Dave and Daniel and the drm list cc'd as well.. > > > > > > Full splat left quoted below for new people and list. > > > > > > Linus > > > > > >> [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 > > drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > > > > That line is at [1], which comes from > > > > 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") > > > > But the patch was merged in 5.9-rc1, so it's probably something else. > > > > We've had a lot of TTM-related changes recently, so my best guess is > > that it's something in TTM with BO initialization. > > > > From some grepping, it looks like we have to call ttm_bo_mem_space() to > > fill mm_node (i.e., the pointer that causes the warning). But I cannot > > find where vram helpers do this. Maybe that's a good starting point. > > > > I'm adding the TTM devs to cc. > > > > Best regards > > Thomas > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h > > elper.c?h=v5.10-rc4#n284 > > > > > > >> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua > > ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf > > ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs > > blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor > > async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper > > syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul > > ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd > > ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit > > >> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 > > >> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 > > >> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > > >> [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d > > 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 > > 48 8b 87 18 06 > > >> [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 > > >> [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 > > >> [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 > > >> [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 > > >> [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 > > >> [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 > > >> [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 > > >> [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > >> [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 > > >> [ 20.988047] Call Trace: > > >> [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] > > >> [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] > > >> [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] > > >> [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] > > >> [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] > > >> [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] > > >> [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] > > >> [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] > > >> [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] > > >> [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] > > >> [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] > > >> [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 > > >> [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > > >> [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] > > >> [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] > > >> [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] > > >> [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > > >> [ 21.079401] __x64_sys_ioctl+0x91/0xc0 > > >> [ 21.083167] do_syscall_64+0x38/0x90 > > >> [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > >> [ 21.091813] RIP: 0033:0x7f5b3cf1350b > > >> [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 > > 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 > > d8 64 89 01 48 > > >> [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > > >> [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b > > >> [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 > > >> [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 > > >> [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 > > >> [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 > > > > -- > > Thomas Zimmermann > > Graphics Driver Developer > > SUSE Software Solutions Germany GmbH > > Maxfeldstr. 5, 90409 Nürnberg, Germany > > (HRB 36809, AG Nürnberg) > > Geschäftsführer: Felix Imendörffer > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 @ 2020-11-18 22:15 ` Daniel Vetter 0 siblings, 0 replies; 22+ messages in thread From: Daniel Vetter @ 2020-11-18 22:15 UTC (permalink / raw) To: David Laight Cc: Linux Kernel Mailing List, dri-devel, Huang, Ray, Thomas Zimmermann, Dave Airlie, Linus Torvalds, Christian König On Wed, Nov 18, 2020 at 11:01 PM David Laight <David.Laight@aculab.com> wrote: > > From: Thomas Zimmermann > > Sent: 18 November 2020 19:37 > > > > Hi > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > >> > > >> I've got the 'splat' below during boot. > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > >> User space is Ubuntu 20.04. > > >> > > >> Additionally the X display has all the colours and alignment slightly > > >> messed up. > > >> 5.9.0 was ok. > > >> I'm just guessing the two issues are related. > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > exactly the problem(s) started to both verify that, and just to > > > pinpoint the exact change.. > > I don't quite understand what 'git bisect' did. > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > generating v5.9.0-rc5+ kernels. We queue up patches for -rc1 way before the previous kernel is released, so this is normal. > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > (retyped - hope it is right). > But the diff to that last 'good' commit is massive. Yeah that's also normal for non-linear history. If you want to double-check, re-test the parent of that commit (which is 2ee476f77ffe ("drm/ttm: add a simple assign mem to bo wrapper")), which should work, and then the bad commit. Also is this the first bad commit for both the splat and the screen corruption issues? > So I don't know if that is anywhere near right. Thomas guessed it could be a ttm change, you hit one, and it looks like it could be the culprit. Now I guess it's up to Dave. Also adding Christian, in case he has an idea. -Daniel > > David > > > > > > > I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: > > > Program display mode in CRTC's atomic_enable" which looks relevant in > > > that it's right in that call-chain. > > > > > > Did some initialization perhaps get overlooked? > > > > > > And Dave and Daniel and the drm list cc'd as well.. > > > > > > Full splat left quoted below for new people and list. > > > > > > Linus > > > > > >> [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 > > drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > > > > That line is at [1], which comes from > > > > 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") > > > > But the patch was merged in 5.9-rc1, so it's probably something else. > > > > We've had a lot of TTM-related changes recently, so my best guess is > > that it's something in TTM with BO initialization. > > > > From some grepping, it looks like we have to call ttm_bo_mem_space() to > > fill mm_node (i.e., the pointer that causes the warning). But I cannot > > find where vram helpers do this. Maybe that's a good starting point. > > > > I'm adding the TTM devs to cc. > > > > Best regards > > Thomas > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h > > elper.c?h=v5.10-rc4#n284 > > > > > > >> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua > > ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf > > ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs > > blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor > > async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper > > syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul > > ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd > > ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit > > >> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 > > >> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 > > >> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > > >> [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d > > 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 > > 48 8b 87 18 06 > > >> [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 > > >> [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 > > >> [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 > > >> [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 > > >> [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 > > >> [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 > > >> [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 > > >> [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > >> [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 > > >> [ 20.988047] Call Trace: > > >> [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] > > >> [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] > > >> [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] > > >> [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] > > >> [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] > > >> [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] > > >> [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] > > >> [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] > > >> [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] > > >> [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] > > >> [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] > > >> [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 > > >> [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > > >> [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] > > >> [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] > > >> [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] > > >> [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > > >> [ 21.079401] __x64_sys_ioctl+0x91/0xc0 > > >> [ 21.083167] do_syscall_64+0x38/0x90 > > >> [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > >> [ 21.091813] RIP: 0033:0x7f5b3cf1350b > > >> [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 > > 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 > > d8 64 89 01 48 > > >> [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > > >> [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b > > >> [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 > > >> [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 > > >> [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 > > >> [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 > > > > -- > > Thomas Zimmermann > > Graphics Driver Developer > > SUSE Software Solutions Germany GmbH > > Maxfeldstr. 5, 90409 Nürnberg, Germany > > (HRB 36809, AG Nürnberg) > > Geschäftsführer: Felix Imendörffer > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 2020-11-18 22:15 ` Daniel Vetter @ 2020-11-18 22:25 ` Dave Airlie -1 siblings, 0 replies; 22+ messages in thread From: Dave Airlie @ 2020-11-18 22:25 UTC (permalink / raw) To: Daniel Vetter Cc: David Laight, Linux Kernel Mailing List, dri-devel, Huang, Ray, Thomas Zimmermann, Dave Airlie, Linus Torvalds, Christian König On Thu, 19 Nov 2020 at 08:15, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > On Wed, Nov 18, 2020 at 11:01 PM David Laight <David.Laight@aculab.com> wrote: > > > > From: Thomas Zimmermann > > > Sent: 18 November 2020 19:37 > > > > > > Hi > > > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > > >> > > > >> I've got the 'splat' below during boot. > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > > >> User space is Ubuntu 20.04. > > > >> > > > >> Additionally the X display has all the colours and alignment slightly > > > >> messed up. > > > >> 5.9.0 was ok. > > > >> I'm just guessing the two issues are related. > > > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > > exactly the problem(s) started to both verify that, and just to > > > > pinpoint the exact change.. > > > > I don't quite understand what 'git bisect' did. > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > > generating v5.9.0-rc5+ kernels. > > We queue up patches for -rc1 way before the previous kernel is > released, so this is normal. > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > > (retyped - hope it is right). > > But the diff to that last 'good' commit is massive. > > Yeah that's also normal for non-linear history. If you want to > double-check, re-test the parent of that commit (which is 2ee476f77ffe > ("drm/ttm: add a simple assign mem to bo wrapper")), which should > work, and then the bad commit. > > Also is this the first bad commit for both the splat and the screen > corruption issues? > > > So I don't know if that is anywhere near right. > > Thomas guessed it could be a ttm change, you hit one, and it looks > like it could be the culprit. Now I guess it's up to Dave. Also adding > Christian, in case he has an idea. I'd be mildly surprised if it's that commit, since it just refactors what looks to me to be two identical code pieces into one instance (within the scope of me screwing that up, but reading it I can't see it). I'll dig into this today. Dave. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 @ 2020-11-18 22:25 ` Dave Airlie 0 siblings, 0 replies; 22+ messages in thread From: Dave Airlie @ 2020-11-18 22:25 UTC (permalink / raw) To: Daniel Vetter Cc: Huang, Ray, Linux Kernel Mailing List, dri-devel, David Laight, Thomas Zimmermann, Dave Airlie, Linus Torvalds, Christian König On Thu, 19 Nov 2020 at 08:15, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > On Wed, Nov 18, 2020 at 11:01 PM David Laight <David.Laight@aculab.com> wrote: > > > > From: Thomas Zimmermann > > > Sent: 18 November 2020 19:37 > > > > > > Hi > > > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > > >> > > > >> I've got the 'splat' below during boot. > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > > >> User space is Ubuntu 20.04. > > > >> > > > >> Additionally the X display has all the colours and alignment slightly > > > >> messed up. > > > >> 5.9.0 was ok. > > > >> I'm just guessing the two issues are related. > > > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > > exactly the problem(s) started to both verify that, and just to > > > > pinpoint the exact change.. > > > > I don't quite understand what 'git bisect' did. > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > > generating v5.9.0-rc5+ kernels. > > We queue up patches for -rc1 way before the previous kernel is > released, so this is normal. > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > > (retyped - hope it is right). > > But the diff to that last 'good' commit is massive. > > Yeah that's also normal for non-linear history. If you want to > double-check, re-test the parent of that commit (which is 2ee476f77ffe > ("drm/ttm: add a simple assign mem to bo wrapper")), which should > work, and then the bad commit. > > Also is this the first bad commit for both the splat and the screen > corruption issues? > > > So I don't know if that is anywhere near right. > > Thomas guessed it could be a ttm change, you hit one, and it looks > like it could be the culprit. Now I guess it's up to Dave. Also adding > Christian, in case he has an idea. I'd be mildly surprised if it's that commit, since it just refactors what looks to me to be two identical code pieces into one instance (within the scope of me screwing that up, but reading it I can't see it). I'll dig into this today. Dave. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 2020-11-18 22:25 ` Dave Airlie @ 2020-11-19 1:16 ` Dave Airlie -1 siblings, 0 replies; 22+ messages in thread From: Dave Airlie @ 2020-11-19 1:16 UTC (permalink / raw) To: Daniel Vetter Cc: David Laight, Linux Kernel Mailing List, dri-devel, Huang, Ray, Thomas Zimmermann, Dave Airlie, Linus Torvalds, Christian König On Thu, 19 Nov 2020 at 08:25, Dave Airlie <airlied@gmail.com> wrote: > > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > On Wed, Nov 18, 2020 at 11:01 PM David Laight <David.Laight@aculab.com> wrote: > > > > > > From: Thomas Zimmermann > > > > Sent: 18 November 2020 19:37 > > > > > > > > Hi > > > > > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > > > >> > > > > >> I've got the 'splat' below during boot. > > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > > > >> User space is Ubuntu 20.04. > > > > >> > > > > >> Additionally the X display has all the colours and alignment slightly > > > > >> messed up. > > > > >> 5.9.0 was ok. > > > > >> I'm just guessing the two issues are related. > > > > > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > > > exactly the problem(s) started to both verify that, and just to > > > > > pinpoint the exact change.. > > > > > > I don't quite understand what 'git bisect' did. > > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > > > generating v5.9.0-rc5+ kernels. > > > > We queue up patches for -rc1 way before the previous kernel is > > released, so this is normal. > > > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > > > (retyped - hope it is right). > > > But the diff to that last 'good' commit is massive. > > > > Yeah that's also normal for non-linear history. If you want to > > double-check, re-test the parent of that commit (which is 2ee476f77ffe > > ("drm/ttm: add a simple assign mem to bo wrapper")), which should > > work, and then the bad commit. > > > > Also is this the first bad commit for both the splat and the screen > > corruption issues? > > > > > So I don't know if that is anywhere near right. > > > > Thomas guessed it could be a ttm change, you hit one, and it looks > > like it could be the culprit. Now I guess it's up to Dave. Also adding > > Christian, in case he has an idea. > > I'd be mildly surprised if it's that commit, since it just refactors > what looks to me to be two identical code pieces into one instance > (within the scope of me screwing that up, but reading it I can't see > it). > > I'll dig into this today. https://patchwork.freedesktop.org/patch/401559/ should fix it. We had a report in the rc1 thread but it got lost in the nouveau stuff as well, I've cc that reporter as well. please test. Dave. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 @ 2020-11-19 1:16 ` Dave Airlie 0 siblings, 0 replies; 22+ messages in thread From: Dave Airlie @ 2020-11-19 1:16 UTC (permalink / raw) To: Daniel Vetter Cc: Huang, Ray, Linux Kernel Mailing List, dri-devel, David Laight, Thomas Zimmermann, Dave Airlie, Linus Torvalds, Christian König On Thu, 19 Nov 2020 at 08:25, Dave Airlie <airlied@gmail.com> wrote: > > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > On Wed, Nov 18, 2020 at 11:01 PM David Laight <David.Laight@aculab.com> wrote: > > > > > > From: Thomas Zimmermann > > > > Sent: 18 November 2020 19:37 > > > > > > > > Hi > > > > > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > > > >> > > > > >> I've got the 'splat' below during boot. > > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > > > >> User space is Ubuntu 20.04. > > > > >> > > > > >> Additionally the X display has all the colours and alignment slightly > > > > >> messed up. > > > > >> 5.9.0 was ok. > > > > >> I'm just guessing the two issues are related. > > > > > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > > > exactly the problem(s) started to both verify that, and just to > > > > > pinpoint the exact change.. > > > > > > I don't quite understand what 'git bisect' did. > > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > > > generating v5.9.0-rc5+ kernels. > > > > We queue up patches for -rc1 way before the previous kernel is > > released, so this is normal. > > > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > > > (retyped - hope it is right). > > > But the diff to that last 'good' commit is massive. > > > > Yeah that's also normal for non-linear history. If you want to > > double-check, re-test the parent of that commit (which is 2ee476f77ffe > > ("drm/ttm: add a simple assign mem to bo wrapper")), which should > > work, and then the bad commit. > > > > Also is this the first bad commit for both the splat and the screen > > corruption issues? > > > > > So I don't know if that is anywhere near right. > > > > Thomas guessed it could be a ttm change, you hit one, and it looks > > like it could be the culprit. Now I guess it's up to Dave. Also adding > > Christian, in case he has an idea. > > I'd be mildly surprised if it's that commit, since it just refactors > what looks to me to be two identical code pieces into one instance > (within the scope of me screwing that up, but reading it I can't see > it). > > I'll dig into this today. https://patchwork.freedesktop.org/patch/401559/ should fix it. We had a report in the rc1 thread but it got lost in the nouveau stuff as well, I've cc that reporter as well. please test. Dave. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Linux 5.10-rc4 2020-11-19 1:16 ` Dave Airlie @ 2020-11-19 9:30 ` David Laight -1 siblings, 0 replies; 22+ messages in thread From: David Laight @ 2020-11-19 9:30 UTC (permalink / raw) To: 'Dave Airlie', Daniel Vetter Cc: Linux Kernel Mailing List, dri-devel, Huang, Ray, Thomas Zimmermann, Dave Airlie, Linus Torvalds, Christian König From: Dave Airlie > Sent: 19 November 2020 01:16 > > On Thu, 19 Nov 2020 at 08:25, Dave Airlie <airlied@gmail.com> wrote: > > > > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > > > On Wed, Nov 18, 2020 at 11:01 PM David Laight <David.Laight@aculab.com> wrote: > > > > > > > > From: Thomas Zimmermann > > > > > Sent: 18 November 2020 19:37 > > > > > > > > > > Hi > > > > > > > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > > > > >> > > > > > >> I've got the 'splat' below during boot. > > > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > > > > >> User space is Ubuntu 20.04. > > > > > >> > > > > > >> Additionally the X display has all the colours and alignment slightly > > > > > >> messed up. > > > > > >> 5.9.0 was ok. > > > > > >> I'm just guessing the two issues are related. > > > > > > > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > > > > exactly the problem(s) started to both verify that, and just to > > > > > > pinpoint the exact change.. > > > > > > > > I don't quite understand what 'git bisect' did. > > > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > > > > generating v5.9.0-rc5+ kernels. > > > > > > We queue up patches for -rc1 way before the previous kernel is > > > released, so this is normal. > > > > > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > > > > (retyped - hope it is right). > > > > But the diff to that last 'good' commit is massive. > > > > > > Yeah that's also normal for non-linear history. If you want to > > > double-check, re-test the parent of that commit (which is 2ee476f77ffe > > > ("drm/ttm: add a simple assign mem to bo wrapper")), which should > > > work, and then the bad commit. > > > > > > Also is this the first bad commit for both the splat and the screen > > > corruption issues? > > > > > > > So I don't know if that is anywhere near right. > > > > > > Thomas guessed it could be a ttm change, you hit one, and it looks > > > like it could be the culprit. Now I guess it's up to Dave. Also adding > > > Christian, in case he has an idea. > > > > I'd be mildly surprised if it's that commit, since it just refactors > > what looks to me to be two identical code pieces into one instance > > (within the scope of me screwing that up, but reading it I can't see > > it). > > > > I'll dig into this today. > > https://patchwork.freedesktop.org/patch/401559/ > > should fix it. Nope, and probably not relevant. pl_flags is 2 or 3 and it is testing for 4. The oldest kernel doesn't generate the 'splat' either. Just the f*cked up display output. I'll put a screenshot (photo) into another email. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Linux 5.10-rc4 @ 2020-11-19 9:30 ` David Laight 0 siblings, 0 replies; 22+ messages in thread From: David Laight @ 2020-11-19 9:30 UTC (permalink / raw) To: 'Dave Airlie', Daniel Vetter Cc: Linux Kernel Mailing List, dri-devel, Huang, Ray, Thomas Zimmermann, Dave Airlie, Linus Torvalds, Christian König From: Dave Airlie > Sent: 19 November 2020 01:16 > > On Thu, 19 Nov 2020 at 08:25, Dave Airlie <airlied@gmail.com> wrote: > > > > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > > > On Wed, Nov 18, 2020 at 11:01 PM David Laight <David.Laight@aculab.com> wrote: > > > > > > > > From: Thomas Zimmermann > > > > > Sent: 18 November 2020 19:37 > > > > > > > > > > Hi > > > > > > > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: > > > > > >> > > > > > >> I've got the 'splat' below during boot. > > > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > > > > >> User space is Ubuntu 20.04. > > > > > >> > > > > > >> Additionally the X display has all the colours and alignment slightly > > > > > >> messed up. > > > > > >> 5.9.0 was ok. > > > > > >> I'm just guessing the two issues are related. > > > > > > > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > > > > exactly the problem(s) started to both verify that, and just to > > > > > > pinpoint the exact change.. > > > > > > > > I don't quite understand what 'git bisect' did. > > > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > > > > generating v5.9.0-rc5+ kernels. > > > > > > We queue up patches for -rc1 way before the previous kernel is > > > released, so this is normal. > > > > > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > > > > (retyped - hope it is right). > > > > But the diff to that last 'good' commit is massive. > > > > > > Yeah that's also normal for non-linear history. If you want to > > > double-check, re-test the parent of that commit (which is 2ee476f77ffe > > > ("drm/ttm: add a simple assign mem to bo wrapper")), which should > > > work, and then the bad commit. > > > > > > Also is this the first bad commit for both the splat and the screen > > > corruption issues? > > > > > > > So I don't know if that is anywhere near right. > > > > > > Thomas guessed it could be a ttm change, you hit one, and it looks > > > like it could be the culprit. Now I guess it's up to Dave. Also adding > > > Christian, in case he has an idea. > > > > I'd be mildly surprised if it's that commit, since it just refactors > > what looks to me to be two identical code pieces into one instance > > (within the scope of me screwing that up, but reading it I can't see > > it). > > > > I'll dig into this today. > > https://patchwork.freedesktop.org/patch/401559/ > > should fix it. Nope, and probably not relevant. pl_flags is 2 or 3 and it is testing for 4. The oldest kernel doesn't generate the 'splat' either. Just the f*cked up display output. I'll put a screenshot (photo) into another email. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Linux 5.10-rc4 2020-11-19 9:30 ` David Laight @ 2020-11-19 9:54 ` David Laight -1 siblings, 0 replies; 22+ messages in thread From: David Laight @ 2020-11-19 9:54 UTC (permalink / raw) To: David Laight, 'Dave Airlie', Daniel Vetter Cc: Linux Kernel Mailing List, dri-devel, Huang, Ray, Thomas Zimmermann, Dave Airlie, Linus Torvalds, Christian König [-- Attachment #1: Type: text/plain, Size: 602 bytes --] From: David Laight <David.Laight@ACULAB.COM> > Sent: 19 November 2020 09:31 > ... > Additionally the X display has all the colours and alignment slightly > messed up. > 5.9.0 was ok. ... > I'll put a screenshot (photo) into another email. An oddity I'd not noticed is that if I let the screensaver blank the screen, when it is re-initialised the colours are ok (a nice? purple). So it might just be some (major) race condition in the startup scripts. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) [-- Attachment #2: 20201119_093830.jpg --] [-- Type: image/jpeg, Size: 3070996 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Linux 5.10-rc4 @ 2020-11-19 9:54 ` David Laight 0 siblings, 0 replies; 22+ messages in thread From: David Laight @ 2020-11-19 9:54 UTC (permalink / raw) To: David Laight, 'Dave Airlie', Daniel Vetter Cc: Linux Kernel Mailing List, dri-devel, Huang, Ray, Thomas Zimmermann, Dave Airlie, Linus Torvalds, Christian König [-- Attachment #1: Type: text/plain, Size: 602 bytes --] From: David Laight <David.Laight@ACULAB.COM> > Sent: 19 November 2020 09:31 > ... > Additionally the X display has all the colours and alignment slightly > messed up. > 5.9.0 was ok. ... > I'll put a screenshot (photo) into another email. An oddity I'd not noticed is that if I let the screensaver blank the screen, when it is re-initialised the colours are ok (a nice? purple). So it might just be some (major) race condition in the startup scripts. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) [-- Attachment #2: 20201119_093830.jpg --] [-- Type: image/jpeg, Size: 3070996 bytes --] [-- Attachment #3: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 2020-11-18 22:01 ` David Laight @ 2020-11-20 8:05 ` Thomas Zimmermann -1 siblings, 0 replies; 22+ messages in thread From: Thomas Zimmermann @ 2020-11-20 8:05 UTC (permalink / raw) To: David Laight, Linus Torvalds Cc: Daniel Vetter, Linux Kernel Mailing List, dri-devel, Huang, Ray, Dave Airlie, Christian König [-- Attachment #1.1.1: Type: text/plain, Size: 7453 bytes --] Hi David Am 18.11.20 um 23:01 schrieb David Laight: > From: Thomas Zimmermann >> Sent: 18 November 2020 19:37 >> >> Hi >> >> Am 18.11.20 um 19:10 schrieb Linus Torvalds: >>> On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: >>>> >>>> I've got the 'splat' below during boot. >>>> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. >>>> User space is Ubuntu 20.04. >>>> >>>> Additionally the X display has all the colours and alignment slightly >>>> messed up. >>>> 5.9.0 was ok. >>>> I'm just guessing the two issues are related. >>> >>> Sounds likely. But it would be lovely if you could bisect when >>> exactly the problem(s) started to both verify that, and just to >>> pinpoint the exact change.. > > I don't quite understand what 'git bisect' did. > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > generating v5.9.0-rc5+ kernels. > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > (retyped - hope it is right). > But the diff to that last 'good' commit is massive. > > So I don't know if that is anywhere near right. Did you try Daniel's suggestion of testing with the direct parent commit? Best regards Thomas > > David > >>> >>> I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: >>> Program display mode in CRTC's atomic_enable" which looks relevant in >>> that it's right in that call-chain. >>> >>> Did some initialization perhaps get overlooked? >>> >>> And Dave and Daniel and the drm list cc'd as well.. >>> >>> Full splat left quoted below for new people and list. >>> >>> Linus >>> >>>> [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 >> drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] >> >> That line is at [1], which comes from >> >> 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") >> >> But the patch was merged in 5.9-rc1, so it's probably something else. >> >> We've had a lot of TTM-related changes recently, so my best guess is >> that it's something in TTM with BO initialization. >> >> From some grepping, it looks like we have to call ttm_bo_mem_space() to >> fill mm_node (i.e., the pointer that causes the warning). But I cannot >> find where vram helpers do this. Maybe that's a good starting point. >> >> I'm adding the TTM devs to cc. >> >> Best regards >> Thomas >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h >> elper.c?h=v5.10-rc4#n284 >> >> >>>> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua >> ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf >> ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs >> blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor >> async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper >> syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul >> ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd >> ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit >>>> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 >>>> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 >>>> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] >>>> [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d >> 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 >> 48 8b 87 18 06 >>>> [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 >>>> [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 >>>> [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 >>>> [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 >>>> [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 >>>> [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 >>>> [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 >>>> [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>> [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 >>>> [ 20.988047] Call Trace: >>>> [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] >>>> [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] >>>> [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] >>>> [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] >>>> [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] >>>> [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] >>>> [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] >>>> [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] >>>> [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] >>>> [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] >>>> [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] >>>> [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 >>>> [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] >>>> [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] >>>> [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] >>>> [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] >>>> [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] >>>> [ 21.079401] __x64_sys_ioctl+0x91/0xc0 >>>> [ 21.083167] do_syscall_64+0x38/0x90 >>>> [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>>> [ 21.091813] RIP: 0033:0x7f5b3cf1350b >>>> [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 >> 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 >> d8 64 89 01 48 >>>> [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 >>>> [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b >>>> [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 >>>> [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 >>>> [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 >>>> [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 >> >> -- >> Thomas Zimmermann >> Graphics Driver Developer >> SUSE Software Solutions Germany GmbH >> Maxfeldstr. 5, 90409 Nürnberg, Germany >> (HRB 36809, AG Nürnberg) >> Geschäftsführer: Felix Imendörffer > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.1.2: OpenPGP_0x680DC11D530B7A23.asc --] [-- Type: application/pgp-keys, Size: 7535 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 5.10-rc4 @ 2020-11-20 8:05 ` Thomas Zimmermann 0 siblings, 0 replies; 22+ messages in thread From: Thomas Zimmermann @ 2020-11-20 8:05 UTC (permalink / raw) To: David Laight, Linus Torvalds Cc: Daniel Vetter, Linux Kernel Mailing List, dri-devel, Huang, Ray, Dave Airlie, Christian König [-- Attachment #1.1.1.1: Type: text/plain, Size: 7453 bytes --] Hi David Am 18.11.20 um 23:01 schrieb David Laight: > From: Thomas Zimmermann >> Sent: 18 November 2020 19:37 >> >> Hi >> >> Am 18.11.20 um 19:10 schrieb Linus Torvalds: >>> On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@aculab.com> wrote: >>>> >>>> I've got the 'splat' below during boot. >>>> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. >>>> User space is Ubuntu 20.04. >>>> >>>> Additionally the X display has all the colours and alignment slightly >>>> messed up. >>>> 5.9.0 was ok. >>>> I'm just guessing the two issues are related. >>> >>> Sounds likely. But it would be lovely if you could bisect when >>> exactly the problem(s) started to both verify that, and just to >>> pinpoint the exact change.. > > I don't quite understand what 'git bisect' did. > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > generating v5.9.0-rc5+ kernels. > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > (retyped - hope it is right). > But the diff to that last 'good' commit is massive. > > So I don't know if that is anywhere near right. Did you try Daniel's suggestion of testing with the direct parent commit? Best regards Thomas > > David > >>> >>> I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: >>> Program display mode in CRTC's atomic_enable" which looks relevant in >>> that it's right in that call-chain. >>> >>> Did some initialization perhaps get overlooked? >>> >>> And Dave and Daniel and the drm list cc'd as well.. >>> >>> Full splat left quoted below for new people and list. >>> >>> Linus >>> >>>> [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 >> drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] >> >> That line is at [1], which comes from >> >> 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") >> >> But the patch was merged in 5.9-rc1, so it's probably something else. >> >> We've had a lot of TTM-related changes recently, so my best guess is >> that it's something in TTM with BO initialization. >> >> From some grepping, it looks like we have to call ttm_bo_mem_space() to >> fill mm_node (i.e., the pointer that causes the warning). But I cannot >> find where vram helpers do this. Maybe that's a good starting point. >> >> I'm adding the TTM devs to cc. >> >> Best regards >> Thomas >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h >> elper.c?h=v5.10-rc4#n284 >> >> >>>> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua >> ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf >> ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs >> blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor >> async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper >> syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul >> ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd >> ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit >>>> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 >>>> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 >>>> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] >>>> [ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d >> 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 >> 48 8b 87 18 06 >>>> [ 20.926100] RSP: 0018:ffff9f59811d3a68 EFLAGS: 00010246 >>>> [ 20.931339] RAX: 0000000000000002 RBX: ffff8b46861e20c0 RCX: ffffffffc032d600 >>>> [ 20.938479] RDX: ffff8b468f47a000 RSI: ffff8b46861e2000 RDI: ffff8b468f9acc00 >>>> [ 20.945622] RBP: ffff9f59811d3a68 R08: 0000000000000040 R09: ffff8b46864ce288 >>>> [ 20.952769] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8b468f47a000 >>>> [ 20.959915] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b468ad2bf00 >>>> [ 20.967057] FS: 00007f5b37ac5cc0(0000) GS:ffff8b49efc00000(0000) knlGS:0000000000000000 >>>> [ 20.975149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>> [ 20.980904] CR2: 00007f5b3d093f00 CR3: 0000000103438000 CR4: 00000000001006f0 >>>> [ 20.988047] Call Trace: >>>> [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] >>>> [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] >>>> [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] >>>> [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] >>>> [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] >>>> [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] >>>> [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] >>>> [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] >>>> [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] >>>> [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] >>>> [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] >>>> [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 >>>> [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] >>>> [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] >>>> [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] >>>> [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] >>>> [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] >>>> [ 21.079401] __x64_sys_ioctl+0x91/0xc0 >>>> [ 21.083167] do_syscall_64+0x38/0x90 >>>> [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>>> [ 21.091813] RIP: 0033:0x7f5b3cf1350b >>>> [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 >> 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 >> d8 64 89 01 48 >>>> [ 21.114154] RSP: 002b:00007ffef1966588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 >>>> [ 21.121730] RAX: ffffffffffffffda RBX: 00007ffef19665c0 RCX: 00007f5b3cf1350b >>>> [ 21.128870] RDX: 00007ffef19665c0 RSI: 00000000c02464bb RDI: 0000000000000009 >>>> [ 21.136013] RBP: 00000000c02464bb R08: 0000000000000040 R09: 0000000000000004 >>>> [ 21.143157] R10: 0000000000000002 R11: 0000000000000246 R12: 0000561ec9d10060 >>>> [ 21.150295] R13: 0000000000000009 R14: 0000561eca2cc9a0 R15: 0000000000000040 >> >> -- >> Thomas Zimmermann >> Graphics Driver Developer >> SUSE Software Solutions Germany GmbH >> Maxfeldstr. 5, 90409 Nürnberg, Germany >> (HRB 36809, AG Nürnberg) >> Geschäftsführer: Felix Imendörffer > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.1.1.2: OpenPGP_0x680DC11D530B7A23.asc --] [-- Type: application/pgp-keys, Size: 7535 bytes --] [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2020-11-20 8:05 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-16 0:59 Linux 5.10-rc4 Linus Torvalds 2020-11-18 12:12 ` David Laight 2020-11-18 18:10 ` Linus Torvalds 2020-11-18 18:10 ` Linus Torvalds 2020-11-18 19:00 ` David Laight 2020-11-18 19:00 ` David Laight 2020-11-18 19:36 ` Thomas Zimmermann 2020-11-18 19:36 ` Thomas Zimmermann 2020-11-18 22:01 ` David Laight 2020-11-18 22:01 ` David Laight 2020-11-18 22:15 ` Daniel Vetter 2020-11-18 22:15 ` Daniel Vetter 2020-11-18 22:25 ` Dave Airlie 2020-11-18 22:25 ` Dave Airlie 2020-11-19 1:16 ` Dave Airlie 2020-11-19 1:16 ` Dave Airlie 2020-11-19 9:30 ` David Laight 2020-11-19 9:30 ` David Laight 2020-11-19 9:54 ` David Laight 2020-11-19 9:54 ` David Laight 2020-11-20 8:05 ` Thomas Zimmermann 2020-11-20 8:05 ` Thomas Zimmermann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.