Re: [Nouveau] [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Op 22-08-13 02:10, Ilia Mirkin schreef:
> The code expects non-VRAM mem nodes to have a pages list. If that's not
> set, it will do a null deref down the line. Warn on that condition and
> return an error.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>
> Reported-by: Pasi Kärkkäinen
> Tested-by: Pasi Kärkkäinen
> Signed-off-by: Ilia Mirkin
> Cc: # 3.8+
> ---
>
> I don't exactly understand what's going on, but this is just a
> straightforward way to avoid a null deref that you see happens in the
> bug. I haven't figured out the root cause of this, but it's getting
> well into the "I have no idea how TTM works" space. However this seems
> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> node->pages as a list down, which will be dereferenced by
> nvc0_vm_map_sg. Perhaps the other arguments should make that
> dereferencing not happen, but it definitely was happening here, as you
> can see in the bug.
>
> Ben/Maarten, I'll let you judge whether this check is appropriate,
> since like I hope I was able to convey above, I'm just not really sure :)
Not it really isn't appropriate..
You'd have to call call nouveau_vm_map_sg_table instead, the only place that
doesn't handle that correctly
is where it's not expected to be called.
Here, have a completely untested patch to fix things...
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
{
struct nouveau_framebuffer *nouveau_fb;
struct drm_gem_object *gem;
+ struct nouveau_bo *nvbo;
int ret = -ENOMEM;
gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
if (!gem)
return ERR_PTR(-ENOENT);
+ nvbo = nouveau_gem_object(gem);
+ if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
+ nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
+ " valid_domains=%08x\n", nvbo->valid_domains);
+ ret = -EINVAL;
+ goto err_unref;
+ }
+
nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
if (!nouveau_fb)
goto err_unref;
- ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd,
nouveau_gem_object(gem));
+ ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
if (ret)
goto err;
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 67382] [nouveau, nv50] linux 3.9.7-3.10.3: Xorg won't be available
https://bugs.freedesktop.org/show_bug.cgi?id=67382 --- Comment #32 from Martin Peres --- (In reply to comment #31) > (In reply to comment #30) > > As the days went by. I'm wondering what I should do. Or what's the case with > > this report. > > Is it kind of a problem, that I need to take care myself? E.g. it cannot be > > patched/removed/altered, because this stabilisation is needed and would harm > > other cards? > > > Point is I've asked a few people and no-one seems to have such issue like > you. So I'm suspecting that it's related to the original NV50. With that > said the only person I can think of having such a card to test is the > nouveau/kernel maintainer. Which is quite busy, but hopefully will have a > moment to test. > > Side effect of using the new "fix" is causing a regression on almost all > other cards, and/or the need to increase the delay to a silly value (as it > was before). Hey dude, I have two of them :) One quadro and one geforce. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi Kärkkäinen
> > Tested-by: Pasi Kärkkäinen
> > Signed-off-by: Ilia Mirkin
> > Cc: # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> Not it really isn't appropriate..
>
> You'd have to call call nouveau_vm_map_sg_table instead, the only place that
> doesn't handle that correctly
> is where it's not expected to be called.
>
> Here, have a completely untested patch to fix things...
>
Thanks! I'll give it a try later today..
-- Pasi
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
> {
> struct nouveau_framebuffer *nouveau_fb;
> struct drm_gem_object *gem;
> + struct nouveau_bo *nvbo;
> int ret = -ENOMEM;
>
> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
> if (!gem)
> return ERR_PTR(-ENOENT);
>
> + nvbo = nouveau_gem_object(gem);
> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
> + " valid_domains=%08x\n", nvbo->valid_domains);
> + ret = -EINVAL;
> + goto err_unref;
> + }
> +
> nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
> if (!nouveau_fb)
> goto err_unref;
>
> - ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd,
> nouveau_gem_object(gem));
> + ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
> if (ret)
> goto err;
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 60772] xf86-video-nouveau fails to modprobe nouveau: KMS not enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60772 --- Comment #14 from Honza --- (In reply to comment #13) > (In reply to comment #11) > > Mirkin: You might've overlooked it, but there IS patch in the message you > > posted reference to. I don't see what other patch might be needed. > > > No-one is saying there is a need for (other) patch(es) > "If you really want to change the behaviour, send a patch, ping people, etc." > > I fail to see why you think it's necessary to change behaviour of > > xf86-video-nouveau to support less workflows just to force the workflow you > > prefer. All replies against this patch I saw was on ideological ground, none > > presented any real reason why it's better this way. > > > Afaics thing will work fine if you use udev/eudev/mdev over linux-hotplug. > In the latter of which I cannot see any progress (or changes) over the last > few years. > I successfully ignored devfs. Fads like that come and go. No need to change what's working. Current attempts of integrating pulseaudio and init doesn't convince me udev is stable. Sure, sysvinit didn't have much change in last few years ... because it's working. Systemd, on the other hand ... > Whereas for the ideological ground - I think that the maintainer of the > kernel drm subsystem(Dave) would know better. Yes a bit more information > would not hurt, but considering the other drivers are doing this I do not > see it as a wrong thing/bikeshedding. > > Btw, I believe he already mentioned that it's racy :) > He mentioned that there is race when you start the module and X server immediately starts using it. If you start udev and immediately after it start X, the race will still be there, wouldn't it? In fact, it will be even worse, as udev doesn't exactly have predictable timing. With distributions trying to make startup fast and parallel and often starting display managers-based logins, I'm actually surprised it works. If the code would be supposed to solve the race, it would contain cycle sleeping until some ioctl returns the module finished initialization. Probably with timeout around 30 seconds. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 50571] nouveau crashes with GeForce GT 520
https://bugs.freedesktop.org/show_bug.cgi?id=50571 --- Comment #17 from Vova --- Yes, bug is fixed for me now. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 54437] [NVC8] linux-nouveau2.6 (3.6.0-rc4) : GTX580 : Xorg freezes when using accel
https://bugs.freedesktop.org/show_bug.cgi?id=54437 --- Comment #9 from Leif Gruenwoldt --- (In reply to comment #3) > The card works just fine if using the extracted firmware Can you elaborate on how to do that? This sounds like a better solution than using the proprietary nvidia driver. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 54437] [NVC8] linux-nouveau2.6 (3.6.0-rc4) : GTX580 : Xorg freezes when using accel
https://bugs.freedesktop.org/show_bug.cgi?id=54437 --- Comment #10 from Kelly Doran --- http://nouveau.freedesktop.org/wiki/NVC0_Firmware/ -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 58556] MacBook Pro 5, 1 with nVidia 9400m and 9600m, scrambled screen
https://bugs.freedesktop.org/show_bug.cgi?id=58556 --- Comment #15 from Pierre Moreau --- Bisected to: commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e Author: Ben Skeggs Date: Mon Apr 30 11:33:43 2012 -0500 drm/nouveau: create real execution engine for software object class Just a cleanup more or less, and to remove the need for special handling of software objects. This removes a heap of documentation on dma/graph object formats. The info is very out of date with our current understanding, and is far better documented in rnndb in envytools git. Signed-off-by: Ben Skeggs I'll try to look for a patch this week-end. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 68453] New: Bad rendering (refreshes) when booting recent debug kernels
https://bugs.freedesktop.org/show_bug.cgi?id=68453 Priority: medium Bug ID: 68453 Assignee: nouveau@lists.freedesktop.org Summary: Bad rendering (refreshes) when booting recent debug kernels QA Contact: xorg-t...@lists.x.org Severity: major Classification: Unclassified OS: Linux (All) Reporter: awill...@redhat.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Driver/nouveau Product: xorg Filed this downstream: https://bugzilla.redhat.com/show_bug.cgi?id=986074 But our nouveau maintainer seems to be dormant at present, so filing upstream. Running Fedora 20 (pre-release), when I boot a non-debug kernel, my graphical rendering is mostly fine (minus a few little buglets I've been living with for years). When I boot a debug kernel, though, it's bad - not just sluggish, but bad. It seems like refreshes simply don't always work completely: say, I open a new tab in Firefox, but I can still see all the content from the previous tab until I wait several seconds or switch tabs and switch back or scrub my mouse around a bit. Any kind of window-switching operation tends to show the issue. A Fedora debug kernel build sets the following: @perl -pi -e 's/# CONFIG_SLUB_DEBUG_ON is not set/CONFIG_SLUB_DEBUG_ON=y/' config-nodebug @perl -pi -e 's/# CONFIG_LOCK_STAT is not set/CONFIG_LOCK_STAT=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_STACK_USAGE is not set/CONFIG_DEBUG_STACK_USAGE=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_SLAB is not set/CONFIG_DEBUG_SLAB=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_MUTEXES is not set/CONFIG_DEBUG_MUTEXES=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set/CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_RT_MUTEXES is not set/CONFIG_DEBUG_RT_MUTEXES=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_LOCK_ALLOC is not set/CONFIG_DEBUG_LOCK_ALLOC=y/' config-nodebug @perl -pi -e 's/# CONFIG_PROVE_LOCKING is not set/CONFIG_PROVE_LOCKING=y/' config-nodebug @perl -pi -e 's/# CONFIG_PROVE_RCU is not set/CONFIG_PROVE_RCU=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_SPINLOCK is not set/CONFIG_DEBUG_SPINLOCK=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_VM is not set/CONFIG_DEBUG_VM=y/' config-nodebug @perl -pi -e 's/# CONFIG_FAULT_INJECTION is not set/CONFIG_FAULT_INJECTION=y/' config-nodebug @perl -pi -e 's/# CONFIG_FAILSLAB is not set/CONFIG_FAILSLAB=y/' config-nodebug @perl -pi -e 's/# CONFIG_FAIL_PAGE_ALLOC is not set/CONFIG_FAIL_PAGE_ALLOC=y/' config-nodebug @perl -pi -e 's/# CONFIG_FAIL_IO_TIMEOUT is not set/CONFIG_FAIL_IO_TIMEOUT=y/' config-nodebug @perl -pi -e 's/# CONFIG_FAIL_MAKE_REQUEST is not set/CONFIG_FAIL_MAKE_REQUEST=y/' config-nodebug @perl -pi -e 's/# CONFIG_FAIL_MMC_REQUEST is not set/CONFIG_FAIL_MMC_REQUEST=y/' config-nodebug @perl -pi -e 's/# CONFIG_FAULT_INJECTION_DEBUG_FS is not set/CONFIG_FAULT_INJECTION_DEBUG_FS=y/' config-nodebug @perl -pi -e 's/# CONFIG_FAULT_INJECTION_STACKTRACE_FILTER is not set/CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_SG is not set/CONFIG_DEBUG_SG=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_WRITECOUNT is not set/CONFIG_DEBUG_WRITECOUNT=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_OBJECTS is not set/CONFIG_DEBUG_OBJECTS=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_OBJECTS_FREE is not set/CONFIG_DEBUG_OBJECTS_FREE=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_OBJECTS_TIMERS is not set/CONFIG_DEBUG_OBJECTS_TIMERS=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_OBJECTS_WORK is not set/CONFIG_DEBUG_OBJECTS_WORK=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER is not set/CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_OBJECTS_RCU_HEAD is not set/CONFIG_DEBUG_OBJECTS_RCU_HEAD=y/' config-nodebug @perl -pi -e 's/# CONFIG_X86_PTDUMP is not set/CONFIG_X86_PTDUMP=y/' config-nodebug @perl -pi -e 's/# CONFIG_CAN_DEBUG_DEVICES is not set/CONFIG_CAN_DEBUG_DEVICES=y/' config-nodebug @perl -pi -e 's/# CONFIG_MODULE_FORCE_UNLOAD is not set/CONFIG_MODULE_FORCE_UNLOAD=y/' config-nodebug @perl -pi -e 's/# CONFIG_SYSCTL_SYSCALL_CHECK is not set/CONFIG_SYSCTL_SYSCALL_CHECK=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_NOTIFIERS is not set/CONFIG_DEBUG_NOTIFIERS=y/' config-nodebug @perl -pi -e 's/# CONFIG_DMA_API_DEBUG is not set/CONFIG_DMA_API_DEBUG=y/' config-nodebug @perl -pi -e 's/# CONFIG_PM_TEST_SUSPEND is not set/CONFIG_PM_TEST_SUSPEND=y/' config-generic @perl -pi -e 's/# CONFIG_
[Nouveau] [Bug 68453] Bad rendering (refreshes) when booting recent debug kernels
https://bugs.freedesktop.org/show_bug.cgi?id=68453 --- Comment #1 from Ilia Mirkin --- Does removing CONFIG_DEBUG_WW_MUTEX_SLOWPATH from the list of options enabled fix things? This option randomly injects failures into ww mutexes (now used for ttm)... dunno if that would be enough to cause your issues or not, but definitely worth trying without it. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 68453] Bad rendering (refreshes) when booting recent debug kernels
https://bugs.freedesktop.org/show_bug.cgi?id=68453 --- Comment #2 from Adam Williamson --- Thanks for the suggestion. I'll try it out when I can find a couple hours to get a full kernel build done :) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 67382] [nouveau, nv50] linux 3.9.7-3.10.3: Xorg won't be available
https://bugs.freedesktop.org/show_bug.cgi?id=67382
--- Comment #33 from Emil Velikov ---
Created attachment 84479
--> https://bugs.freedesktop.org/attachment.cgi?id=84479&action=edit
nv50 quirk
Confirmed that only nv50 are affected. The blob's dac handling does differ
between nv50 and later cards, so this patch should do the job.
Feel free to test and provide a full name + email if you'd like your
contributions to me acknowledged ("Reported-by" and "Tested-by")
--
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 67382] [nouveau, nv50] linux 3.9.7-3.10.3: Xorg won't be available
https://bugs.freedesktop.org/show_bug.cgi?id=67382
--- Comment #34 from Emil Velikov ---
Here is a bit more information as to the blob's handing on the case
nv50
Simple register bashing
write(loadval | 0x010)
udelay(140s)
read()
write(0)
nv94/96
HWSQ
: 5f 01 00 ewait #CRTC0_VBLANK 0x0
0003: 5f 01 01 ewait #CRTC0_VBLANK 0x1
0006: 0e wait 0x2 shl 0x6
0007: 0d wait 0x1 shl 0x6
0008: 02 wait 0x2 shl 0x0
0009: 01 wait 0x1 shl 0x0
// the above are only valid if the output is already enabled
000a: e2 08 02 10 00 data 0x100208
000f: e0 0c a8 61 00 addr 0x61a80c
0014: 00 nop
0015: 40 0c a8 addrlo 0xa80c
0018: 05 wait 0x1 shl 0x2
0019: e2 00 00 00 00 data 0x0
001e: 40 0c a8 addrlo 0xa80c
0021: 7f exit
0022: 7f exit
0023: 7f exit
PBUS.HWSQ.TRIGGER <= { TYPE = START | ENTRY_POINT = 0 }
PBUS.HWSQ.STATUS => { A = { IP = 0x5 | ACTIVE } }
if output is connected ~5,4 ms later
PDISPLAY.DAC[0x1].LOAD_CTRL => { LOAD_PATTERN = 0 | PRESENT = 0x7 }
PDISPLAY.DAC[0x1].LOAD_CTRL <= { LOAD_PATTERN = 0 | PRESENT = 0 }
otherwise in ~5us
PDISPLAY.DAC[0x1].LOAD_CTRL => { LOAD_PATTERN = 0 | PRESENT = 0x0 }
PDISPLAY.DAC[0x1].LOAD_CTRL <= { LOAD_PATTERN = 0 | PRESENT = 0 }
--
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 68456] New: kernel NULL pointer dereference on 'modprobe nouveau'
https://bugs.freedesktop.org/show_bug.cgi?id=68456 Priority: medium Bug ID: 68456 Assignee: nouveau@lists.freedesktop.org Summary: kernel NULL pointer dereference on 'modprobe nouveau' QA Contact: xorg-t...@lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: hpdei...@gmx.de Hardware: Other Status: NEW Version: git Component: Driver/nouveau Product: xorg Loading the nouveau module leads to an instant crash. I was advised on #nouveau to try the config option NvI2C=1, which worked. But the default config is nevertheless broken. I have a "GeForce 7600 GT" card and use the latest (commit 3b56bba6) kernel from anongit.freedesktop.org master which seems to be rebased onto linux-3.11-rc6. Here is the generated backtrace: kernel: BUG: unable to handle kernel NULL pointer dereference at (null) kernel: IP: [] nouveau_i2c_pre_xfer+0xf/0x1d [nouveau] kernel: PGD 0 kernel: Oops: [#1] SMP kernel: Modules linked in: nouveau(+) video mxm_wmi i2c_algo_bit ttm drm_kms_helper drm hwmon_vid i2c_core usbhid usb_storage kvm_amd kvm pcspkr ohci_pci snd_hda_codec_via ohci_hcd ehci_pci k10temp r8169 snd_hda_intel ehci_hcd wmi snd_hda_codec snd_pcm snd_page_alloc snd_timer snd acpi_cpufreq mperf processor thermal_sys hwmon kernel: CPU: 0 PID: 439 Comm: kworker/0:1 Not tainted 3.11.0-rc6-g3b56bba #2 kernel: Hardware name: System manufacturer System Product Name/M4A77TD, BIOS 030509/10/2009 kernel: Workqueue: events work_for_cpu_fn kernel: task: 88012aff2050 ti: 88012ab4a000 task.ti: 88012ab4a000 kernel: RIP: 0010:[] [] nouveau_i2c_pre_xfer+0xf/0x1d [nouveau] kernel: RSP: 0018:88012ab4b918 EFLAGS: 00010286 kernel: RAX: RBX: 880128fb7800 RCX: kernel: RDX: 880128fb7800 RSI: a01ebdf5 RDI: 88012a2ba800 kernel: RBP: 88012a98ecc0 R08: 000a R09: fffb kernel: R10: R11: 88012391 R12: 88012a2ba820 kernel: R13: a01ebdf5 R14: a02f80c0 R15: 88012a98ef00 kernel: FS: 7f273a9c0780() GS:88012fc0() knlGS: kernel: CS: 0010 DS: ES: CR0: 8005003b kernel: CR2: CR3: 01527000 CR4: 07f0 kernel: Stack: kernel: a026871a 880128fb7800 88012a98ecc0 kernel: 88012a2ba800 88012a2ba820 a02f80c0 a028ed5a kernel: 0020 88012ab4ba7c 88012ab4b9e0 kernel: Call Trace: kernel: [] ? __i2c_bit_add_bus+0x2a/0x2b3 [i2c_algo_bit] kernel: [] ? nouveau_i2c_port_create_+0x136/0x18a [nouveau] kernel: [] ? nv04_i2c_port_ctor+0x2b/0x5c [nouveau] kernel: [] ? dcb_i2c_entry+0x24/0x48 [nouveau] kernel: [] ? nouveau_object_ctor+0x2b/0xb7 [nouveau] kernel: [] ? nouveau_i2c_create_+0xce/0x1de [nouveau] kernel: [] ? nouveau_event_create+0x1d/0x5e [nouveau] kernel: [] ? nv04_i2c_ctor+0x1f/0x2d [nouveau] kernel: [] ? nouveau_object_ctor+0x2b/0xb7 [nouveau] kernel: [] ? nouveau_devobj_ctor+0x52f/0x5a3 [nouveau] kernel: [] ? nouveau_object_ctor+0x2b/0xb7 [nouveau] kernel: [] ? nouveau_object_new+0x162/0x20e [nouveau] kernel: [] ? nouveau_drm_load+0x154/0x565 [nouveau] kernel: [] ? drm_get_minor+0x196/0x1e8 [drm] kernel: [] ? drm_get_pci_dev+0x141/0x243 [drm] kernel: [] ? __pci_set_master+0x22/0x6d kernel: [] ? nouveau_drm_probe+0x1cb/0x1ee [nouveau] kernel: [] ? local_pci_probe+0x34/0x5b kernel: [] ? work_for_cpu_fn+0xb/0x11 kernel: [] ? process_one_work+0x1c1/0x2c8 kernel: [] ? process_scheduled_works+0x18/0x25 kernel: [] ? worker_thread+0x1eb/0x29b kernel: [] ? manage_workers.isra.25+0x1ae/0x1ae kernel: [] ? kthread+0xad/0xb5 kernel: [] ? __kthread_parkme+0x5e/0x5e kernel: [] ? ret_from_fork+0x7c/0xb0 kernel: [] ? __kthread_parkme+0x5e/0x5e kernel: Code: 48 81 c6 80 dc 00 00 e8 69 fd f0 e0 8b 44 24 08 48 83 c4 10 5b c3 e9 10 f2 ff ff 90 51 48 8b 47 18 48 8b 38 48 8b 87 50 03 00 00 <48> 8b 00 48 85 c0 74 02 ff d0 31 c0 5a c3 48 8b 87 50 03 00 00 kernel: RIP [] nouveau_i2c_pre_xfer+0xf/0x1d [nouveau] kernel: RSP kernel: CR2: kernel: ---[ end trace 451adc65612b1d9f ]--- -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 68456] [NV4B] null deref on load, NvI2C=1 makes it work
https://bugs.freedesktop.org/show_bug.cgi?id=68456 Ilia Mirkin changed: What|Removed |Added Summary|kernel NULL pointer |[NV4B] null deref on load, |dereference on 'modprobe|NvI2C=1 makes it work |nouveau'| -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 68402] Some elements are only rendered in top-left area
https://bugs.freedesktop.org/show_bug.cgi?id=68402 --- Comment #4 from Emil Velikov --- You're a star Ján Just had a word with our main dev and he suggested that viewport transformation is optional, whereas viewport clip rectangle must be set before and after 3d_blit(). With that said, here is what can be done to double-check/fix this - note a quick piglit [1] test before and after each one, plus testing of other games/gl apps is essential. * nuke the viewport clip rectangle (despite all odds) * change the viewport clip rectangle - traceback and use the original values (the ones saved at the begingin on 3d_blit() and restored at the end) * nuke the viewport transformation * add the conditional NV50_TIC_5_LAST_LEVEL__MASK on tic[5] in nvc0_create_texture_view (compare vs nv50_create_texture_view) I'm hoping that one of the last two will do the job, although chances are that it may be one of the first two. Either way a piglit and further testing will prove which solution is the most appropriate. Feel free to give it a shot yourself, as it will take a some time until I get to it(apart from the lack of HW). Note: depending on your luck(and other unknown to me factors) piglit may lockup X and your system. Normally a s2r cycle is sufficient to get it back into shape, otherwise a reboot is needed. Cheers, Emil [1] http://cgit.freedesktop.org/piglit/ -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 68456] [NV4B] null deref on load, NvI2C=1 makes it work
https://bugs.freedesktop.org/show_bug.cgi?id=68456 --- Comment #1 from Ilia Mirkin --- The code decodes to 1c: 51 push %rcx 1d: 48 8b 47 18 mov0x18(%rdi),%rax 21: 48 8b 38mov(%rax),%rdi 24: 48 8b 87 50 03 00 00mov0x350(%rdi),%rax 2b:* 48 8b 00mov(%rax),%rax <-- trapping instruction 2e: 48 85 c0test %rax,%rax 31: 74 02 je 0x35 33: ff d0 callq *%rax 35: 31 c0 xor%eax,%eax 37: 5a pop%rdx 38: c3 retq Which means that port->func is NULL. Still trying to work out exactly how that happens. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 68456] [NV4B] null deref on load, NvI2C=1 makes it work
https://bugs.freedesktop.org/show_bug.cgi?id=68456 --- Comment #2 from Ilia Mirkin --- Created attachment 84484 --> https://bugs.freedesktop.org/attachment.cgi?id=84484&action=edit pass i2c functions into create func Can you give this patch a shot? It compiles, but I haven't tested it beyond that. Should fix the null deref. But it might still not work. (Obviously without the NvI2C=1 thing.) BTW, how are you hitting this? Did you set something in i2c like bit_test=1? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 20341] NV31 lockup
https://bugs.freedesktop.org/show_bug.cgi?id=20341 Jason Detring changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- Priority|high|medium --- Comment #13 from Jason Detring --- Hi Ilia, thanks for the ticket bump. I pulled this machine out of storage to retest. The entire graphics stack has now been upgraded. - Mesa 9.1.6 - Xorg server 1.13.4 - xf86-video-nouveau 1.0.9 - Linux 3.11-rc6 Nouveau now reports at bootup: [6.584942] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x031100a1 [6.585121] nouveau [ DEVICE][:01:00.0] Chipset: NV31 (NV31) [6.585212] nouveau [ DEVICE][:01:00.0] Family : NV30 [6.587705] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [6.629569] nouveau [ VBIOS][:01:00.0] ... appears to be valid [6.629663] nouveau [ VBIOS][:01:00.0] using image from PRAMIN [6.629755] nouveau [ VBIOS][:01:00.0] BMP version 5.27 [6.630214] nouveau [ VBIOS][:01:00.0] version 04.31.20.52.00 [6.631927] nouveau W[ PTIMER][:01:00.0] unknown input clock freq [6.632210] nouveau [ PFB][:01:00.0] RAM type: DDR1 [6.632340] nouveau [ PFB][:01:00.0] RAM size: 128 MiB [6.632429] nouveau [ PFB][:01:00.0]ZCOMP: 262144 tags [6.642148] [TTM] Zone kernel: Available graphics memory: 93186 kiB [6.642277] [TTM] Initializing pool allocator [6.642535] nouveau [ DRM] VRAM: 127 MiB [6.642661] nouveau [ DRM] GART: 128 MiB [6.642752] nouveau [ DRM] BMP version 5.39 [6.642839] nouveau [ DRM] DCB version 2.2 [6.642928] nouveau [ DRM] DCB outp 00: 01000300 9c40 [6.643043] nouveau [ DRM] DCB outp 01: 02010310 9c40 [6.643132] nouveau [ DRM] DCB outp 02: 01010312 [6.643220] nouveau [ DRM] DCB outp 03: 02020321 0003 [6.643663] nouveau [ DRM] Loading NV17 power sequencing microcode [6.645661] nouveau [ DRM] Saving VGA fonts [6.690672] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [6.690779] [drm] No driver support for vblank timestamp query. [6.690966] nouveau [ DRM] 0xE176: Parsing digital output script table [6.691764] nouveau [ DRM] 0 available performance level(s) [6.691859] nouveau [ DRM] c: core 234MHz memory 501MHz voltage 1220mV [6.695827] nouveau [ DRM] MM: using M2MF for buffer copies [6.696202] nouveau [ DRM] Setting dpms mode 3 on TV encoder (output 3) [6.777513] nouveau [ DRM] allocated 1920x1200 fb: 0x9000, bo cbb04600 [6.777995] fbcon: nouveaufb (fb0) is primary device [6.794224] Console: switching to colour frame buffer device 240x75 [6.798678] nouveau :01:00.0: fb0: nouveaufb frame buffer device [6.798701] nouveau :01:00.0: registered panic notifier [6.798729] [drm] Initialized nouveau 1.1.1 20120801 for :01:00.0 on minor 0 I spent some time ensuring the Nvidia driver (173.14.18) tested earlier in the ticket was completely removed. glxinfo now yields direct rendering: Yes ... OpenGL vendor string: nouveau OpenGL renderer string: Gallium 0.4 on NV31 OpenGL version string: 1.5 Mesa 9.1.6 as expected. Nouveau's 3D engine seems to have no lockup problems. I spent a few minutes working my way through xscreensaver's GL modules with no catastrophic consequences. It appears only 2D acceleration has issues. Running "x11perf -putimage500" still locks up the machine. Symptoms aren't exactly the same as earlier in the ticket, but the end result still is loss of a usable UI. 1. X freezes. Local input is dropped. Mouse pointer freezes, keyboard lights do not respond to toggles. 2. Machine is not completely frozen, SSH still works. 3. X continues to run for a few seconds, then crashes. X dies, but the system does not return to a console. The keyboard is still locked and the screen is black. 4. dmesg has been spammed as follows: [ 5096.360378] nouveau E[ PFIFO][:01:00.0] DMA_PUSHER - ch 1 [X[1337]] get 0x00037be4 put 0x0001d690 state 0x2000a428 (err: CALL_SUBR_ACTIVE) push 0x [ 5096.360431] nouveau E[ PFIFO][:01:00.0] DMA_PUSHER - ch 1 [X[1337]] get 0x0001d690 put 0x0001d6a0 state 0x8000 (err: INVALID_CMD) push 0x [ 5096.360475] nouveau E[ PFIFO][:01:00.0] DMA_PUSHER - ch 1 [X[1337]] get 0x0001d6a0 put 0x0001d6b0 state 0x8000 (err: INVALID_CMD) push 0x [ 5096.360516] nouveau E[ PFIFO][:01:00.0] DMA_PUSHER - ch 1 [X[1337]] get 0x0001d6b0 put 0x0001d6c0 state 0x8000 (err: INVALID_CMD) push 0x ... lots of above lines repeated ... [ 5126.421032] nouveau E[ X[1337]] failed to idle channel 0x [X[1337]] [ 5126.425268] nouveau E[ PFIFO][:01:00.
