[Nouveau] [Bug 93458] page allocation failure: order:5, mode:0x240c0c0
https://bugs.freedesktop.org/show_bug.cgi?id=93458 Matt Whitlock changed: What|Removed |Added CC||freedesk...@mattwhitlock.na ||me --- Comment #5 from Matt Whitlock --- I've run into this exact same failure on Linux kernel 4.4.7-gentoo. 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1) systemmonitor: page allocation failure: order:5, mode:0x240c0c0 CPU: 2 PID: 25678 Comm: systemmonitor Not tainted 4.4.7-gentoo #1 Hardware name: /D975XBX2, BIOS BX97520J.86A.2836.2008.0728.1946 07/28/2008 815e2614 0240c0c0 88010005b970 810bbc14 88019381 81a7cbc0 0005 0040 88019381 0240c0c0 Call Trace: [] ? dump_stack+0x46/0x59 [] ? warn_alloc_failed+0xd4/0x120 [] ? __alloc_pages_nodemask+0x16f/0x910 [] ? alloc_kmem_pages+0x17/0x80 [] ? kmalloc_order+0xf/0x40 [] ? nvkm_ramht_new+0x3b/0xe0 [] ? g84_fifo_chan_ctor+0x13a/0x170 [] ? g84_fifo_gpfifo_new+0xb9/0x2e0 [] ? nvkm_udevice_child_get+0x60/0xf0 [] ? nvkm_ioctl_new+0x11d/0x260 [] ? nvkm_udevice_map+0x40/0x40 [] ? nvkm_ioctl+0xf7/0x240 [] ? nvif_object_init+0xb5/0x120 [] ? nouveau_channel_new+0xa8/0x660 [] ? nouveau_abi16_ioctl_channel_alloc+0xd3/0x2d0 [] ? nvkm_client_notify+0x20/0x20 [] ? drm_ioctl+0x119/0x480 [] ? page_add_file_rmap+0x2a/0x50 [] ? nouveau_abi16_ioctl_setparam+0x10/0x10 [] ? nouveau_drm_ioctl+0x5b/0xb0 [] ? do_vfs_ioctl+0x293/0x470 [] ? __do_page_fault+0x169/0x380 [] ? SyS_ioctl+0x36/0x70 [] ? entry_SYSCALL_64_fastpath+0x16/0x6e Mem-Info: active_anon:254439 inactive_anon:246298 isolated_anon:0 active_file:689086 inactive_file:691252 isolated_file:0 unevictable:44 dirty:24538 writeback:0 unstable:0 slab_reclaimable:50180 slab_unreclaimable:9054 mapped:71902 shmem:9819 pagetables:6004 bounce:0 free:28497 free_pcp:31 free_cma:0 DMA free:15828kB min:20kB low:24kB high:28kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15928kB managed:15844kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:16kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes lowmem_reserve[]: 0 3234 7957 7957 DMA32 free:37400kB min:4576kB low:5720kB high:6864kB active_anon:312136kB inactive_anon:457768kB active_file:1151848kB inactive_file:1153596kB unevictable:120kB isolated(anon):0kB isolated(file):0kB present:3389592kB managed:3314852kB mlocked:120kB dirty:26704kB writeback:0kB mapped:122180kB shmem:15400kB slab_reclaimable:81552kB slab_unreclaimable:13116kB kernel_stack:2544kB pagetables:9160kB unstable:0kB bounce:0kB free_pcp:4kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 4722 4722 Normal free:60760kB min:6684kB low:8352kB high:10024kB active_anon:705620kB inactive_anon:527424kB active_file:1604496kB inactive_file:1611412kB unevictable:56kB isolated(anon):0kB isolated(file):0kB present:4980736kB managed:4836224kB mlocked:56kB dirty:71448kB writeback:0kB mapped:165428kB shmem:23876kB slab_reclaimable:119168kB slab_unreclaimable:23084kB kernel_stack:4976kB pagetables:14856kB unstable:0kB bounce:0kB free_pcp:120kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 DMA: 1*4kB (U) 0*8kB 1*16kB (U) 0*32kB 1*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15828kB DMA32: 8708*4kB (UME) 334*8kB (UME) 17*16kB (UME) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 37776kB Normal: 15206*4kB (UME) 3*8kB (U) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 60848kB 1390493 total pagecache pages 276 pages in swap cache Swap cache stats: add 8903, delete 8627, find 314/531 Free swap = 8354200kB Total swap = 8388604kB 2096564 pages RAM 0 pages HighMem/MovableOnly 54834 pages reserved (In reply to Zlatko Calusic from comment #4) > I've had lots of success using the attached patch. 4 days and still running > strong, no page allocation failures. But, some core developer should > probably confirm that using vmalloc instead of kmalloc is ok in that > function. I would venture a guess that the memory allocated for a GPU FIFO buffer needs to be physically continuous, as it will be used for DMA, so using vmalloc is a bad idea that may lead to incorrect pages being read/written by DMA. Aside: Does this bug report belong on this bug tracker, or would it be more appropriate on the kernel bug tracker? This is a problem in the kernel, not in the DDX. -- You are receiving this mail b
[Nouveau] [PATCH] volt/gk104: round up in gk104_volt_set
We always want a equal or higher voltage than the requested ones, otherwise nouveau undervolts. Signed-off-by: Karol Herbst --- drm/nouveau/nvkm/subdev/volt/gk104.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/subdev/volt/gk104.c b/drm/nouveau/nvkm/subdev/volt/gk104.c index 81788c2..9043dc8 100644 --- a/drm/nouveau/nvkm/subdev/volt/gk104.c +++ b/drm/nouveau/nvkm/subdev/volt/gk104.c @@ -57,7 +57,7 @@ gk104_volt_set(struct nvkm_volt *base, u32 uv) /* the blob uses this crystal frequency, let's use it too. */ div = 27648000 / bios->pwm_freq; - duty = (uv - bios->base) * div / bios->pwm_range; + duty = DIV_ROUND_UP((uv - bios->base) * div, bios->pwm_range); nvkm_wr32(device, 0x20340, div); nvkm_wr32(device, 0x20344, 0x8000 | duty); -- 2.8.1 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau/bl: Assign different names to interfaces
On 02:40 PM - Apr 15 2016, Nick Tenney wrote:
> On Fri, Apr 15, 2016 at 11:25 AM, Ilia Mirkin wrote:
>
> > On Fri, Apr 15, 2016 at 11:22 AM, Pierre Moreau
> > wrote:
> > > On 11:06 AM - Apr 15 2016, Ilia Mirkin wrote:
> > >> On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau
> > wrote:
> > >> > Currently, every backlight interface created by Nouveau uses the same
> > name,
> > >> > nv_backlight. This leads to a sysfs warning as it tries to create an
> > already
> > >> > existing folder. This patch adds a incremented number to the name,
> > but keeps
> > >> > the initial name as nv_backlight, to avoid possibly breaking
> > userspace; the
> > >> > second interface will be named nv_backlight1, and so on.
> > >> >
> > >> > Fixes: fdo#86539
> >
> I believe Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86539 is
> the preferred format. I think this is picked up by the mesa release scripts
> or some such.
Ack’ed. I’ll fix that in the v2.
Thanks!
Pierre
>
> > >> > Signed-off-by: Pierre Moreau
> > >> > ---
> > >> > drm/nouveau/nouveau_backlight.c | 35
> > +--
> > >> > 1 file changed, 33 insertions(+), 2 deletions(-)
> > >> >
> > >> > diff --git a/drm/nouveau/nouveau_backlight.c
> > b/drm/nouveau/nouveau_backlight.c
> > >> > index 89eb460..914e2cb 100644
> > >> > --- a/drm/nouveau/nouveau_backlight.c
> > >> > +++ b/drm/nouveau/nouveau_backlight.c
> > >> > @@ -36,6 +36,10 @@
> > >> > #include "nouveau_reg.h"
> > >> > #include "nouveau_encoder.h"
> > >> >
> > >> > +static atomic_t bl_interfaces_nb = { 0 };
> > >>
> > >> static data is initialized to 0, this should be unnecessary.
> > >
> > > I didn’t know that. But on the other hand, I like having it explicit,
> > and it
> > > should not add any overhead.
> >
> > It increases the size of the object file. I believe it's kernel policy
> > to avoid static initializations to 0. (Note that this doesn't hold in
> > regular user applications, just the kernel.)
> >
> > -ilia
> > ___
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94964] New: Tearing with opengl-hq and not with opengl on Gnome with MPV
https://bugs.freedesktop.org/show_bug.cgi?id=94964 Bug ID: 94964 Summary: Tearing with opengl-hq and not with opengl on Gnome with MPV Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: jeremy9...@gmail.com QA Contact: nouveau@lists.freedesktop.org Tearing with opengl-hq and not with opengl on Gnome with MPV Hello, I'm on Fedora 23 with Linux 4.4, Gnome Shell 3.18, MPV 0.17 and Nouveau driver (Nvidia GT430). In windowed mode I have tearing with opengl-hq and not with opengl. In fullscreen mode there is no tearing with both opengl-hq and opengl. Here is the commands to test mpv --no-config --vo=opengl-hq movie.mkv mpv --no-config --vo=opengl movie.mkv With Netrunner 14.2 (KDE - Kubuntu 14.04 derivative), MPV 0.17 and Nvidia proprietary drivers there is no tearing in windowed mode with opengl-hq. I tried Gnome Shell and Plasma 5 on Manjaro too. There is no tearing with Nouveau and Opengl-hq in windowed mode in Plasma 5 but there is stutter and there is tearing with Gnome Shell. Actually there is dropped frames with Nouveau and Opengl-hq in windowed mode in all DE. I opened an issue on MPV github and Wm4, the main MPV dev, said that my GPU (Nvidia GT430) with Nouveau driver is maybe too slow (no reclocking ?). https://github.com/mpv-player/mpv/issues/2501 For me the logical behavior should be like on Plasma 5 with Nouveau, no tearing but if the GPU is not powerful enough the playback have stutter due to the dropped frames. I contacted Rui Matos, a Mutter developper, and he advise me to file a bug here. Here is a summary of our talk to give all the infos I have : Rui : Did you try gnome-shell on this environment (same as Plasma 5)? I supposed it'd still tear. Me : I tried Plasma 5 and Gnome Shell on Manjaro with Nouveau on the same installation. The tearing was present in Gnome Shell but not on Plasma 5. Rui : I'm afraid I can't help with this one, you'll have to file a nouveau bug. Me: Can you confirm that even if the tearing was present in Gnome Shell but not on Plasma 5 on the same install I should file a bug to Nouveau. Rui: Is kwin using opengl compositing? For the comparison to be meaningful you need to compare gnome-shell with kwin with opengl compositing enabled. Me: I just checked to be sure and the opengl compositing is enabled for kwin too. Rui: Ok. I still might be a driver issue that just happens to be triggered by different timings and API usage in mutter vs. kwin. Anyway, I can't really do much without the hardware to test, so it's still better to report it to nouveau. Thank you ! -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 82152] [NVE7] NULL deref when putting card back to sleep after unsuccessful init (HUB_INIT timeout)
https://bugs.freedesktop.org/show_bug.cgi?id=82152 --- Comment #11 from Patrick Burroughs --- Created attachment 122992 --> https://bugs.freedesktop.org/attachment.cgi?id=122992&action=edit dmesg output with errors from successful load With Linux 4.5.0-ARCH, Mesa 11.1.2-3, DRI3, and using modesetting_drv instead of intel_drv for the main display (not sure if that's relevant)... everything works! (If "everything" consists of glxinfo, glxgears, and a few minutes of Darwinia.) I do still get errors in dmesg, though, as attached. I'll be happy to follow along and do whatever digging is necessary to eradicate them, if someone wants to take up that task. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92126] [NVE4] GTX 760 Auto fan speed stays at 10% until temp hits 90C
https://bugs.freedesktop.org/show_bug.cgi?id=92126 --- Comment #5 from Karol Herbst --- Is this bug fixed in recent kernels? (4.5 I think?) -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
