search for: slub

...e thread or time, but I have been >>> signalling it before: >>> >>> 4.9.* kernels do not work well for me any more (and for other people >>> neither, as I know). Last stable kernel was 4.9.13-22. I think I have nailed down the faulty combo. My tests showed, that SLUB allocator does not work well in Xen Dom0, on top of Xen Hypervisor. Id does not work at least on one of my testing servers (old AMD K8 (1 proc, 1 core), only 1 paravirt guest). If kernel with SLUB booted as main (w/o Xen hypervisor), it works well. If booted as Xen hypervisor module - it almost ins...

...nalling it before: >>>>> >>>>> 4.9.* kernels do not work well for me any more (and for other people >>>>> neither, as I know). Last stable kernel was 4.9.13-22. >> >> I think I have nailed down the faulty combo. >> My tests showed, that SLUB allocator does not work well in Xen Dom0, on >> top of Xen Hypervisor. >> Id does not work at least on one of my testing servers (old AMD K8 (1 proc, >> 1 core), only 1 paravirt guest). >> If kernel with SLUB booted as main (w/o Xen hypervisor), it works well. >> If bo...

On Fri, May 14, 2010 at 09:10:57PM +0200, Peter Klar wrote: > As the bug seems to be related to the SLAB allocator, the dump says ''kernel > BUG at mm/slub.c:2969!'', I also recompiled the kernel using the SLAB instead > of SLUB allocator, but this does not make any difference, the behaviour is > the same (beside the dump then reports a bug within slab.c instead of > slub.c). The corresponding register/stack dump from the SLAB cas...

On Fri, May 14, 2010 at 09:10:57PM +0200, Peter Klar wrote: > As the bug seems to be related to the SLAB allocator, the dump says ''kernel > BUG at mm/slub.c:2969!'', I also recompiled the kernel using the SLAB instead > of SLUB allocator, but this does not make any difference, the behaviour is > the same (beside the dump then reports a bug within slab.c instead of > slub.c). The corresponding register/stack dump from the SLAB cas...

...000 [#1] PREEMPT SMP PTI CPU: 13 PID: 3351 Comm: alacritty Tainted: G I 5.8.0-rc5-00191-g086f86c033f9 #53 Hardware name: Gigabyte Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3 Pro-CF, BIOS F5d 11/28/2019 RIP: 0010:kmem_cache_alloc_trace (/home/kas/linux/torvalds/mm/slub.c:272 /home/kas/linux/torvalds/mm/slub.c:278 /home/kas/linux/torvalds/mm/slub.c:292 /home/kas/linux/torvalds/mm/slub.c:2791 /home/kas/linux/torvalds/mm/slub.c:2832 /home/kas/linux/torvalds/mm/slub.c:2849) Code: 8b 51 08 48 89 c8 65 48 03 05 d4 0e ca 70 48 8b 70 08 48 39 f2 75 e7 4c 8b 38 4d 85 ff...

...gt;>>>> >>>>>> 4.9.* kernels do not work well for me any more (and for other people >>>>>> neither, as I know). Last stable kernel was 4.9.13-22. >>> >>> I think I have nailed down the faulty combo. >>> My tests showed, that SLUB allocator does not work well in Xen Dom0, on >>> top of Xen Hypervisor. >>> Id does not work at least on one of my testing servers (old AMD K8 (1 >>> proc, >>> 1 core), only 1 paravirt guest). >>> If kernel with SLUB booted as main (w/o Xen hypervisor),...

https://bugs.freedesktop.org/show_bug.cgi?id=51018 Bug #: 51018 Summary: kernel >=3.4.0: nouveau triggers kernel BUG in slub.c on GTX 560 Ti Classification: Unclassified Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/n...

...T SMP PTI > CPU: 13 PID: 3351 Comm: alacritty Tainted: G I 5.8.0-rc5-00191-g086f86c033f9 #53 > Hardware name: Gigabyte Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3 Pro-CF, BIOS F5d 11/28/2019 > RIP: 0010:kmem_cache_alloc_trace (/home/kas/linux/torvalds/mm/slub.c:272 /home/kas/linux/torvalds/mm/slub.c:278 /home/kas/linux/torvalds/mm/slub.c:292 /home/kas/linux/torvalds/mm/slub.c:2791 /home/kas/linux/torvalds/mm/slub.c:2832 /home/kas/linux/torvalds/mm/slub.c:2849) > Code: 8b 51 08 48 89 c8 65 48 03 05 d4 0e ca 70 48 8b 70 08 48 39 f2 75 e7 4c 8b 38 4d 85...

...gt;>>>> >>>>>> 4.9.* kernels do not work well for me any more (and for other people >>>>>> neither, as I know). Last stable kernel was 4.9.13-22. >>> >>> I think I have nailed down the faulty combo. >>> My tests showed, that SLUB allocator does not work well in Xen Dom0, on >>> top of Xen Hypervisor. >>> Id does not work at least on one of my testing servers (old AMD K8 (1 >>> proc, >>> 1 core), only 1 paravirt guest). >>> If kernel with SLUB booted as main (w/o Xen hypervisor),...

...2539 ioctl 4010630e fff returned -22 > [29175] Random reseed: 2776471322 > [29175] Random reseed: 3086119361 > child 2606 exiting > [29175] Bailing main loop. Exit reason: ctrl-c > [179906.393060] ------------[ cut here ]------------ > [179906.396341] kernel BUG at /build/linux/mm/slub.c:3352! > [179906.399693] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC > [179906.403272] CPU: 0 PID: 29175 Comm: trinity-main Not tainted 3.10.0-rc4 #1 > [179906.407692] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > [179906.411475] task: ffff8800b69e47c0 ti: ffff880092f2e000 task...

Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Tested with Xorg 1.20 modesetting driver, weston at c46c70dac84a4b3030cd05b380f9f410536690fc, gnome & KDE wayland desktops from Ubuntu 18.04, and sway 1.5 Signed-off-by: James Jones <jajones at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 26

...acle.com> --- v2: add a wrapper API for slab destruction to make decoder only work in particular path. fs/btrfs/extent_io.c | 26 ++++++++++++++++++++++++-- fs/btrfs/extent_map.c | 13 ++++++++++++- include/linux/slab.h | 2 ++ include/linux/slab_def.h | 1 + include/linux/slub_def.h | 1 + mm/slab_common.c | 17 ++++++++++++++++- mm/slub.c | 2 ++ 7 files changed, 58 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index bcc8dff..355c7fc 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -...

Hi All, Running into temporary pauses in our VMs which correspond to these errors in dmesg on the dom0: [1721485.352560] SLUB: Unable to allocate memory on node -1 (gfp=0x20) [1721485.352563] cache: kmalloc-2048, object size: 2048, buffer size: 2048, default order: 3, min order: 0 [1721485.352566] node 0: slabs: 81, objs: 1296, free: 0 [1721485.352576] swapper: page allocation failure: order:0, mode:0x4020 [1721485.3...

...[179904.099501] binder: 29175:2539 ioctl 4010630e fff returned -22 [29175] Random reseed: 2776471322 [29175] Random reseed: 3086119361 child 2606 exiting [29175] Bailing main loop. Exit reason: ctrl-c [179906.393060] ------------[ cut here ]------------ [179906.396341] kernel BUG at /build/linux/mm/slub.c:3352! [179906.399693] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC [179906.403272] CPU: 0 PID: 29175 Comm: trinity-main Not tainted 3.10.0-rc4 #1 [179906.407692] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [179906.411475] task: ffff8800b69e47c0 ti: ffff880092f2e000 task.ti: ffff880092f2e00...

...[179904.099501] binder: 29175:2539 ioctl 4010630e fff returned -22 [29175] Random reseed: 2776471322 [29175] Random reseed: 3086119361 child 2606 exiting [29175] Bailing main loop. Exit reason: ctrl-c [179906.393060] ------------[ cut here ]------------ [179906.396341] kernel BUG at /build/linux/mm/slub.c:3352! [179906.399693] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC [179906.403272] CPU: 0 PID: 29175 Comm: trinity-main Not tainted 3.10.0-rc4 #1 [179906.407692] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [179906.411475] task: ffff8800b69e47c0 ti: ffff880092f2e000 task.ti: ffff880092f2e00...

...en >>>> signalling it before: >>>> >>>> 4.9.* kernels do not work well for me any more (and for other people >>>> neither, as I know). Last stable kernel was 4.9.13-22. > > I think I have nailed down the faulty combo. > My tests showed, that SLUB allocator does not work well in Xen Dom0, on > top of Xen Hypervisor. > Id does not work at least on one of my testing servers (old AMD K8 (1 proc, > 1 core), only 1 paravirt guest). > If kernel with SLUB booted as main (w/o Xen hypervisor), it works well. > If booted as Xen hypervis...

On Wed, Jun 05, 2013 at 03:06:33PM +0300, Tommi Rantala wrote: > 2013/6/5 Michael S. Tsirkin <mst at redhat.com>: > > On Tue, Jun 04, 2013 at 09:50:59PM +0300, Tommi Rantala wrote: > >> Hello, > >> > >> Hit this right after killing trinity with Ctrl-C. Was fuzzing > >> v3.10-rc4-0-gd683b96 in a qemu virtual machine as the root user. > >>

2013/6/5 Michael S. Tsirkin <mst at redhat.com>: > On Tue, Jun 04, 2013 at 09:50:59PM +0300, Tommi Rantala wrote: >> Hello, >> >> Hit this right after killing trinity with Ctrl-C. Was fuzzing >> v3.10-rc4-0-gd683b96 in a qemu virtual machine as the root user. >> >> Tommi > > Thanks a lot for the report. If found some bugs when looking > at

2013/6/5 Michael S. Tsirkin <mst at redhat.com>: > On Tue, Jun 04, 2013 at 09:50:59PM +0300, Tommi Rantala wrote: >> Hello, >> >> Hit this right after killing trinity with Ctrl-C. Was fuzzing >> v3.10-rc4-0-gd683b96 in a qemu virtual machine as the root user. >> >> Tommi > > Thanks a lot for the report. If found some bugs when looking > at

On 07/19/2017 04:27 AM, Piotr Gackiewicz wrote: > On Mon, 17 Jul 2017, Johnny Hughes wrote: > >> Are the testing kernels (kernel-4.9.37-29.el7 and kernel-4.9.37-29.el6, >> with the one config file change) working for everyone: >> >> (turn off: CONFIG_IO_STRICT_DEVMEM) > > Hello. > Maybe it's not the most appropriate thread or time, but I have been >