Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Jul 2010 14:57:35 +0200
From:      =?ISO-8859-1?Q?Ren=E9_Ladan?= <rene@freebsd.org>
To:        Yuri Pankov <yuri.pankov@gmail.com>
Cc:        freebsd-current@freebsd.org, David Naylor <naylor.b.david@gmail.com>
Subject:   Re: nvidia-driver crashing kernel on head
Message-ID:  <AANLkTimT4UwDzB6jF2eML4U7jQubOs1slwBPHwy_5U3b@mail.gmail.com>
In-Reply-To: <20100702124628.GA2566@darklight.org.ru>
References:  <201007021146.46542.naylor.b.david@gmail.com> <20100702124628.GA2566@darklight.org.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
2010/7/2 Yuri Pankov <yuri.pankov@gmail.com>:
> On Fri, Jul 02, 2010 at 11:46:41AM +0200, David Naylor wrote:
>> Hi,
>>
>> I'm not sure this has been reported before but I am experience crashes w=
ith
>> nvidia-driver on -current (cvsup ~day ago).
>>
>> If I remove all the debugging options from the kernel config then it is =
very
>> usable.
>>
>> Here are the backtraces from two nvidia-driver versions:
>>
>> nvidia-driver-195.36.15 and GENERIC:
>> panic: mutex page lock not owned at /home/freebsd9/src/sys/vm/vm_page.c:=
1638
>> cpuid =3D 1
>> KDB: enter: panic
>> [ thread pid 1815 tid 100097 ]
>> Stopped at =A0 =A0 =A0kdb_enter+0x3d: movq =A0 =A0$0,0x6bc27c(%rip)
>> db> bt
>> Tracing pid 1815 tid 100097 td 0xffffff00045af000
>> kdb_enter() at kdb_enter+0x3d
>> panic() at panic+0x176
>> assert_mtx() at assert_mtx
>> vm_page_wire() at vm_page_wire+0x37
>> nv_alloc_system_pages() at nv_alloc_system_pages+0x217
>> nv_alloc_pages() at nv_alloc_pages+0xcd
>> _nv019978rm() at _nv019978rm+0x7f
>>
>> nvidia-driver-256.35 and custom kernel:
>> panic: blockable sleep lock (sleep mutex) select mtxpool @
>> /home/freebsd9/src/sys/kern/sys_generic.c:1479
>> cpuid =3D 1
>> KDB: enter: panic
>> [ thread pid 1830 tid 100090 ]
>> Stopped at =A0 =A0 =A0kdb_enter+0x3d: movq =A0 =A0$0,0x51368c(%rip)
>> db> bt
>> Tracing pid 1830 tid 100090 td 0xffffff000456d3d0
>> kdb_enter() at kdb_enter+0x3d
>> panic() at panic+0x176
>> witness_checkorder() at witness_checkorder+0x913
>> _mtx_lock_flags() at _mtx_lock_flags+0x68
>> selrecord() at selrecord+0x71
>> nvidia_dev_poll() at nvidia_dev_poll+0x52
>> devfs_poll_f() at devfs_poll_f+0x55
>> kern_select() at kern_select+0x501
>> select() at select+0x54
>> syscallenter() at syscallenter+0x19b
>> syscall() at syscall+0x41
>> Xfast_syscall() at Xfast_syscall+0xe2
>> --- syscall (93, FreeBSD ELF64, select), rip =3D 0x801a17ddc, rsp =3D 0x=
7fffffffe908,
>> rbp =3D 0x100 ---
>>
>> Also of note is:
>> # grep '^C.*FLAGS' /etc/make.conf
>> CFLAGS+=3D -DNDEBUG
>>
>> As mentioned that without any debugging options the system is stable.
>>
>> Is there anything I can do to assist diagnosis?
>>
>> Regards,
>>
>> David
>
> http://lists.freebsd.org/pipermail/freebsd-current/2010-June/017936.html
> helps here, check the thread as well.
>
> You could also try to use 256.35 driver.
>
The 256.35 driver works for me (without the above-referred patch), but anyw=
here
between 1 and 48 hours my laptop locks up hard without any warning nor pani=
c.
This is with CURRENT r209581, GENERIC kernel, but with debug.witness.watch=
=3D0
If I set debug.witness.watch to 1, the kernel freezes when starting X.

The nv driver seems to run nice, but without xv/DRI though.

Regards,
Rene



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimT4UwDzB6jF2eML4U7jQubOs1slwBPHwy_5U3b>