Re: [Nouveau] [PATCH] drm/nouveau/core: recognise GP107 chipset
I believe what's missing at this point is a mmiotrace of the NVIDIA
driver to make sure that there's nothing different about this GPU. If
you can make one (see https://wiki.ubuntu.com/X/MMIOTracing for a
guide - should end up ~100MB uncompressed), please send a compressed
one to mmio.du...@gmail.com or make available some other way.
On Tue, Feb 14, 2017 at 2:34 PM, Daniel Drake wrote:
> From: Chris Chiu
>
> This new graphics card was failing to initialize with nouveau due to
> an "unknown chipset" error.
>
> Copy the GP106 configuration and rename for GP107/NV137. We don't
> know for certain that this is fully correct, but brief desktop testing
> suggests this is working fine.
>
> Signed-off-by: Chris Chiu
> Signed-off-by: Daniel Drake
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29
> +++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> index fea30d6..d242431 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -2237,6 +2237,34 @@ nv136_chipset = {
> .fifo = gp100_fifo_new,
> };
>
> +static const struct nvkm_device_chip
> +nv137_chipset = {
> + .name = "GP107",
> + .bar = gf100_bar_new,
> + .bios = nvkm_bios_new,
> + .bus = gf100_bus_new,
> + .devinit = gm200_devinit_new,
> + .fb = gp104_fb_new,
> + .fuse = gm107_fuse_new,
> + .gpio = gk104_gpio_new,
> + .i2c = gm200_i2c_new,
> + .ibus = gm200_ibus_new,
> + .imem = nv50_instmem_new,
> + .ltc = gp100_ltc_new,
> + .mc = gp100_mc_new,
> + .mmu = gf100_mmu_new,
> + .pci = gp100_pci_new,
> + .timer = gk20a_timer_new,
> + .top = gk104_top_new,
> + .ce[0] = gp104_ce_new,
> + .ce[1] = gp104_ce_new,
> + .ce[2] = gp104_ce_new,
> + .ce[3] = gp104_ce_new,
> + .disp = gp104_disp_new,
> + .dma = gf119_dma_new,
> + .fifo = gp100_fifo_new,
> +};
> +
> static int
> nvkm_device_event_ctor(struct nvkm_object *object, void *data, u32 size,
>struct nvkm_notify *notify)
> @@ -2673,6 +2701,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
> case 0x130: device->chip = &nv130_chipset; break;
> case 0x134: device->chip = &nv134_chipset; break;
> case 0x136: device->chip = &nv136_chipset; break;
> + case 0x137: device->chip = &nv137_chipset; break;
> default:
> nvdev_error(device, "unknown chipset (%08x)\n",
> boot0);
> goto done;
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 99799] Civilization VI makes nouveau crash on register allocation
https://bugs.freedesktop.org/show_bug.cgi?id=99799 --- Comment #2 from Ilia Mirkin --- OK, so this is a previously-known issue. There's another bug filed about it somewhere... crysis maybe? Anyways, it comes down to a problem with the delete_Instruction() in the spill code. When deleting the instruction (Instruction::~Instruction), it clears out its own ValueDef's (ValueDef::set), which should in turn update the relevant Value's defs lists. However this happens in the middle of RA, which means that various instructions are joined into nodes, and value A's defs list ends up in value B's defs list. Now this is where I get confused - when I change the logic to also remove the ValueDef from val->join, this does not help. Further vexing is the fact that this particular spill shouldn't even be happening in the first place - it's a move between 2 LValues which I'm pretty sure are joined to each other. Valgrind catches the first badness where this happens, which is when building live sets after spilling happens. Need to add more breaks and poke around more. -- 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] NVAC: WARN_ON(nvbo->pin_refcnt > 0);
Hello fellows! Signal finally goes through ION's HDMI, however # chvt from 5 "graphical" to 3 "textual", and then at the very end of reboot, WARN emerges: ... nouveau :01:00.0: DRM: EVO timeout [ cut here ] WARNING: CPU: 1 PID: 701 at drivers/gpu/drm/nouveau/nouveau_bo.c:137 nouveau_bo_del_ttm+0x7f/0x90 [nouveau] Modules linked in: ... nouveau mxm_wmi video i2c_algo_bit ttm drm_kms_helper drm wmi ... CPU: 1 PID: 701 Comm: Xorg Not tainted 4.10.0-0.rc8.git0.1.fc26.x86_64 #1 ... Call Trace: dump_stack+0x63/0x84 __warn+0xcb/0xf0 warn_slowpath_null+0x1d/0x20 nouveau_bo_del_ttm+0x7f/0x90 [nouveau] ttm_bo_release_list+0xd7/0x1e0 [ttm] ttm_bo_release+0x19c/0x250 [ttm] ttm_bo_unref+0x23/0x30 [ttm] nouveau_gem_object_del+0x8f/0xe0 [nouveau] drm_gem_object_free+0x29/0x70 [drm] drm_gem_object_unreference_unlocked+0x34/0x80 [drm] drm_gem_object_handle_unreference_unlocked+0x69/0xc0 [drm] drm_gem_object_release_handle+0x53/0x90 [drm] ? drm_gem_object_handle_unreference_unlocked+0xc0/0xc0 [drm] idr_for_each+0xa4/0x100 ? nouveau_abi16_fini+0x50/0x70 [nouveau] drm_gem_release+0x20/0x30 [drm] drm_release+0x33d/0x390 [drm] __fput+0xdf/0x1e0 fput+0xe/0x10 task_work_run+0x76/0x90 do_exit+0x2d0/0xb70 ? __do_page_fault+0x267/0x4c0 do_group_exit+0x47/0xb0 SyS_exit_group+0x14/0x20 entry_SYSCALL_64_fastpath+0x1a/0xa9 RIP: 0033:0x7fa5510acdd8 RSP: 002b:7fff4a0cb608 EFLAGS: 0246 ORIG_RAX: 00e7 RAX: ffda RBX: 7fa5536839a0 RCX: 7fa5510acdd8 RDX: RSI: 003c RDI: RBP: 7fff4a0cb600 R08: 00e7 R09: fc88 R10: 7fa552bf5d80 R11: 0246 R12: 7fa552bf5d68 R13: 004a R14: R15: 7fff4a0cb2f0 ---[ end trace 53f6d91de8e38281 ]--- Ref. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nouveau_bo.c?id=refs/tags/v4.10-rc8#n137 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
