similar to: Nouveau on a Jetson TK1 problems

Is there any particular reason you're not using the open source NVIDIA Tegra drivers? This is what is being used for the TX1 (Sorry I don't know if it's the same for the TK1) http://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git;a=summary On Mon, Oct 17, 2016 at 11:11 AM, ben <benjaminscott at centurylink.net> wrote: > I hope this is a good mailing list for this problem. I

Please find below an automated bisection report for a kernel Oops seen during the initialisation of the nouveau GPU driver on jetson-tk1. All the LAVA test jobs for this bisection can be found here: http://lava.baylibre.com:10080/scheduler/alljobs?length=25&search=lava-bisect-staging-7366#table Here's the beginning of the Oops stack trace: [ 7.485361] [00000064] *pgd=f9e7b835 [

uhhhhhhhhhhhhh didn't we fix this weeks ago? with "drm/nouveau: tegra: Call nouveau_drm_device_init()" On Fri, 2018-12-07 at 23:31 +0000, Guillaume Tucker wrote: > Please find below an automated bisection report for a kernel Oops > seen during the initialisation of the nouveau GPU driver on > jetson-tk1. > > > All the LAVA test jobs for this bisection can be

On 08/12/2018 00:08, Lyude Paul wrote: > uhhhhhhhhhhhhh > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > nouveau_drm_device_init()" Yes here's the fix from Thierry: https://patchwork.freedesktop.org/patch/263587/ and I can confirm that it does fix the Oops when applied on top of next-20181206 (what I used for the bisection last week):

Hi All, Since I will be working on nouveau pretty much starting today I thought it would be good to write a quick self introduction. I'm an FOSS enthusiast / developer since 1996. I've written (and still maintain) various hwmon drivers, various USB webcam drivers, libv4l and libgphoto camlibs for photoframes which use a custom usb protocol and usb redirection over the network for qemu.

The reset control API has two modes: exclusive access, where the driver expects to have full and immediate control over the state of the reset line, and shared (clock-like) access, where drivers only request reset deassertion while active, but don't care about the state of the reset line while inactive. Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset

On Wed, Jul 19, 2017 at 05:25:04PM +0200, Philipp Zabel wrote: > The reset control API has two modes: exclusive access, where the driver > expects to have full and immediate control over the state of the reset > line, and shared (clock-like) access, where drivers only request reset > deassertion while active, but don't care about the state of the reset line > while inactive.

https://bugs.freedesktop.org/show_bug.cgi?id=108658 Bug ID: 108658 Summary: gt215 scheduling while atomic warning Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=111940 Bug ID: 111940 Summary: frequent timeout warnings during normal operation Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Driver/nouveau

[15561.391527] ------------[ cut here ]------------ [15561.391560] WARNING: CPU: 0 PID: 20957 at drivers/gpu/drm/nouveau/nvif/vmm.c:71 nvif_vmm_put+0x4a/0x50 [nouveau] [15561.391562] Modules linked in: nls_utf8(E) isofs(E) fuse(E) msr(E) xt_comment(E) br_netfilter(E) xt_physdev(E) nfnetlink_cthelper(E) nfnetlink(E) ebtable_filter(E) ebtables(E) af_packet(E) bridge(E) stp(E) llc(E) iscsi_ibft(E)

Hi there, Could someone please comment on the following hard-lock (*). Staring at the code, I see `nvkm_rd32` calls are enclosed in a timeout detection, except one. drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c#L171 ... nvkm_msec(device, 2000, if (!(nvkm_rd32(device, 0x100c80) & 0x00000001)) break; ); ... Would it make sense to also enclose this in the do/while loop ? Full ref: *

Hello, I'm working on a Asus X756UQK laptop with nvidia + intel graphics cards. After a suspend-resume cycle, the machine hangs on shutdown, requiring a forced power off. After resuming I sometimes see the following messages on the kernel log: [ 186.117539] nouveau 0000:01:00.0: DRM: evicting buffers... [ 186.118105] nouveau 0000:01:00.0: DRM: waiting for kernel channels to go

On Sun, Oct 16, 2016 at 11:39 PM, C Bergström <cbergstrom at pathscale.com> wrote: > Is there any particular reason you're not using the open source NVIDIA > Tegra drivers? > > This is what is being used for the TX1 (Sorry I don't know if it's the > same for the TK1) > http://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git;a=summary That's ... not particularly

https://bugs.freedesktop.org/show_bug.cgi?id=108857 Bug ID: 108857 Summary: display becomes unresponsive and keyboard input fails Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau

With linux-next-2017-12-14, I get a crash when nouveau is loaded by systemd-udevd. [ 12.050625] Unable to handle kernel NULL pointer dereference at virtual address 00000058 [ 12.050627] Mem abort info: [ 12.050628] ESR = 0x96000004 [ 12.050630] Exception class = DABT (current EL), IL = 32 bits [ 12.050631] SET = 0, FnV = 0 [ 12.050632] EA = 0, S1PTW = 0 [ 12.050633] Data

Hi Thierry, Thanks for the patch. I applied on top of linux-next-2017-12-14. Different output this time. [ 11.862495] WARNING: CPU: 1 PID: 254 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:391 gf100_vmm_new_+0x60/0x128 [nouveau] [ 11.863458] tegra-dpaux 155c0000.dpaux: 155c0000.dpaux supply vdd not found, using dummy regulator [ 11.866197] tegra-sor 15580000.sor: failed to probe

I applied the changes manually. This time, Xorg is actually starting... [ 16.862744] WARNING: CPU: 3 PID: 381 at drivers/gpu/drm/nouveau/nouveau_bo.c:280 nouveau_bo_new+0x450/0x4d0 [nouveau] [ 16.873333] Modules linked in: nouveau i2c_algo_bit ttm tegra_drm gpio_keys drm_kms_helper drm drm_panel_orientation_quirks(P) host1x dwmac_dwc_qos_eth stmmac_platform stmmac ptp pps_core syscopyarea

There is a new fallthrough pseudo-keyword macro that can be used to replace the various /* fallthrough */ style comments that are used to indicate a case label code block is intended to fallthrough to the next case label block. See commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo keyword for switch/case use") These patches are intended to allow clang to

There is a new fallthrough pseudo-keyword macro that can be used to replace the various /* fallthrough */ style comments that are used to indicate a case label code block is intended to fallthrough to the next case label block. See commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo keyword for switch/case use") These patches are intended to allow clang to

There is a new fallthrough pseudo-keyword macro that can be used to replace the various /* fallthrough */ style comments that are used to indicate a case label code block is intended to fallthrough to the next case label block. See commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough' pseudo keyword for switch/case use") These patches are intended to allow clang to