Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 14-06-2010 23:31, Christian Zander wrote:
On Mon, Jun 14, 2010 at 02:30:03PM -0700, Rene Ladan wrote:
(...)
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the nvidia driver running
again.
Yes, the unnecessary (and now problematic) wiring and unwiring calls will
be
removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
I would just remove the calls to vm_page_wire() and vm_page_unwire() along
with the immediately adjacent calls to vm_page_{un,}lock_queues().
Just to confirm, like the attached patch?
Yes.
This is with a GeForce GT 240M, current/amd64 r209035, nvidia-driver
195.36.15
I haven't runtime-tested it yet...
Using the above configuration, X still locks up but now after showing
the NVIDIA splash screen. Without the patch it locks up before that
point. Pinging the computer doesn't work anymore, no panic or logs, a
hard reset is required.
Would disabling DRI and/or Accel in xorg.conf or updating the driver /
operating system somehow help?
Rene
--
http://www.rene-ladan.nl/
GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC
(subkeys.pgp.net)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Sunday 13 June 2010 11:23:07 pm Doug Barton wrote:
On 06/13/10 19:09, Alan Cox wrote:
On Sun, Jun 13, 2010 at 8:38 PM, Doug Bartondo...@freebsd.org wrote:
On 06/01/10 08:26, John Baldwin wrote:
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the nvidia driver running
again.
Yes, the unnecessary (and now problematic) wiring and unwiring calls will
be
removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
I would just remove the calls to vm_page_wire() and vm_page_unwire() along
with the immediately adjacent calls to vm_page_{un,}lock_queues().
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Mon, Jun 14, 2010 at 05:48:55AM -0700, John Baldwin wrote:
(...)
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the nvidia driver running
again.
Yes, the unnecessary (and now problematic) wiring and unwiring calls will
be
removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
I would just remove the calls to vm_page_wire() and vm_page_unwire() along
with the immediately adjacent calls to vm_page_{un,}lock_queues().
That's all I did. The next 256.xx build will pick these changes up.
--
christian zander
ch?zan...@nvidia.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 06/14/10 14:30, Rene Ladan wrote:
On 14-06-2010 14:48, John Baldwin wrote:
On Sunday 13 June 2010 11:23:07 pm Doug Barton wrote:
On 06/13/10 19:09, Alan Cox wrote:
On Sun, Jun 13, 2010 at 8:38 PM, Doug Bartondo...@freebsd.org wrote:
On 06/01/10 08:26, John Baldwin wrote:
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the nvidia driver running
again.
Yes, the unnecessary (and now problematic) wiring and unwiring calls will
be
removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
I would just remove the calls to vm_page_wire() and vm_page_unwire() along
with the immediately adjacent calls to vm_page_{un,}lock_queues().
Just to confirm, like the attached patch?
This is with a GeForce GT 240M, current/amd64 r209035, nvidia-driver
195.36.15
I haven't runtime-tested it yet...
This worked great, thanks! I'm re-attaching the patch for Alexey's
benefit, just in case.
Details, I'm running today's -current (r209174) and I've had it up for
4.5 hours already, which is 3 hours longer than I was able to run with
anything 195.22 for months. I've done full normal use which includes
lots of terminals, tbird, firefox, flash, etc.
Thanks again,
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
--- src/nvidia_subr.c.orig 2010-03-12 17:48:52.0 +0100
+++ src/nvidia_subr.c 2010-06-14 23:25:28.0 +0200
@@ -1301,9 +1301,6 @@
for (i = 0; i count; i++) {
pte_array[i] = at-pte_array[i].physical_address;
-vm_page_lock_queues();
-vm_page_wire(PHYS_TO_VM_PAGE(pte_array[i]));
-vm_page_unlock_queues();
sglist_append_phys(at-sg_list, pte_array[i], PAGE_SIZE);
}
@@ -1365,9 +1362,6 @@
os_flush_cpu_cache();
for (i = 0; i count; i++) {
-vm_page_lock_queues();
-vm_page_unwire(PHYS_TO_VM_PAGE(at-pte_array[i].physical_address), 0);
-vm_page_unlock_queues();
kmem_free(kernel_map,
at-pte_array[i].virtual_address, PAGE_SIZE);
malloc_type_freed(M_NVIDIA, PAGE_SIZE);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 14-06-2010 14:48, John Baldwin wrote:
On Sunday 13 June 2010 11:23:07 pm Doug Barton wrote:
On 06/13/10 19:09, Alan Cox wrote:
On Sun, Jun 13, 2010 at 8:38 PM, Doug Bartondo...@freebsd.org wrote:
On 06/01/10 08:26, John Baldwin wrote:
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the nvidia driver running
again.
Yes, the unnecessary (and now problematic) wiring and unwiring calls will
be
removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
I would just remove the calls to vm_page_wire() and vm_page_unwire() along
with the immediately adjacent calls to vm_page_{un,}lock_queues().
Just to confirm, like the attached patch?
This is with a GeForce GT 240M, current/amd64 r209035, nvidia-driver
195.36.15
I haven't runtime-tested it yet...
Rene
--
http://www.rene-ladan.nl/
GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6
(subkeys.pgp.net)
--- src/nvidia_subr.c.orig 2010-03-12 17:48:52.0 +0100
+++ src/nvidia_subr.c 2010-06-14 23:25:28.0 +0200
@@ -1301,9 +1301,6 @@
for (i = 0; i count; i++) {
pte_array[i] = at-pte_array[i].physical_address;
-vm_page_lock_queues();
-vm_page_wire(PHYS_TO_VM_PAGE(pte_array[i]));
-vm_page_unlock_queues();
sglist_append_phys(at-sg_list, pte_array[i], PAGE_SIZE);
}
@@ -1365,9 +1362,6 @@
os_flush_cpu_cache();
for (i = 0; i count; i++) {
-vm_page_lock_queues();
-vm_page_unwire(PHYS_TO_VM_PAGE(at-pte_array[i].physical_address), 0);
-vm_page_unlock_queues();
kmem_free(kernel_map,
at-pte_array[i].virtual_address, PAGE_SIZE);
malloc_type_freed(M_NVIDIA, PAGE_SIZE);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Mon, Jun 14, 2010 at 02:30:03PM -0700, Rene Ladan wrote:
(...)
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the nvidia driver running
again.
Yes, the unnecessary (and now problematic) wiring and unwiring calls will
be
removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
I would just remove the calls to vm_page_wire() and vm_page_unwire() along
with the immediately adjacent calls to vm_page_{un,}lock_queues().
Just to confirm, like the attached patch?
Yes.
This is with a GeForce GT 240M, current/amd64 r209035, nvidia-driver
195.36.15
I haven't runtime-tested it yet...
Rene
--
http://www.rene-ladan.nl/
GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6
(subkeys.pgp.net)
Content-Description: patch-jhb-current
--- src/nvidia_subr.c.orig2010-03-12 17:48:52.0 +0100
+++ src/nvidia_subr.c 2010-06-14 23:25:28.0 +0200
@@ -1301,9 +1301,6 @@
for (i = 0; i count; i++) {
pte_array[i] = at-pte_array[i].physical_address;
-vm_page_lock_queues();
-vm_page_wire(PHYS_TO_VM_PAGE(pte_array[i]));
-vm_page_unlock_queues();
sglist_append_phys(at-sg_list, pte_array[i], PAGE_SIZE);
}
@@ -1365,9 +1362,6 @@
os_flush_cpu_cache();
for (i = 0; i count; i++) {
-vm_page_lock_queues();
-vm_page_unwire(PHYS_TO_VM_PAGE(at-pte_array[i].physical_address),
0);
-vm_page_unlock_queues();
kmem_free(kernel_map,
at-pte_array[i].virtual_address, PAGE_SIZE);
malloc_type_freed(M_NVIDIA, PAGE_SIZE);
--
christian zander
ch?zan...@nvidia.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Mon, Jun 14, 2010 at 2:31 PM, Christian Zander czan...@nvidia.com wrote:
On Mon, Jun 14, 2010 at 02:30:03PM -0700, Rene Ladan wrote:
(...)
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the nvidia driver running
again.
Yes, the unnecessary (and now problematic) wiring and unwiring calls will
be
removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
I would just remove the calls to vm_page_wire() and vm_page_unwire() along
with the immediately adjacent calls to vm_page_{un,}lock_queues().
Just to confirm, like the attached patch?
Yes.
This is with a GeForce GT 240M, current/amd64 r209035, nvidia-driver
195.36.15
I haven't runtime-tested it yet...
Rene
--
http://www.rene-ladan.nl/
GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6
(subkeys.pgp.net)
Content-Description: patch-jhb-current
--- src/nvidia_subr.c.orig 2010-03-12 17:48:52.0 +0100
+++ src/nvidia_subr.c 2010-06-14 23:25:28.0 +0200
@@ -1301,9 +1301,6 @@
for (i = 0; i count; i++) {
pte_array[i] = at-pte_array[i].physical_address;
- vm_page_lock_queues();
- vm_page_wire(PHYS_TO_VM_PAGE(pte_array[i]));
- vm_page_unlock_queues();
sglist_append_phys(at-sg_list, pte_array[i], PAGE_SIZE);
}
@@ -1365,9 +1362,6 @@
os_flush_cpu_cache();
for (i = 0; i count; i++) {
- vm_page_lock_queues();
- vm_page_unwire(PHYS_TO_VM_PAGE(at-pte_array[i].physical_address),
0);
- vm_page_unlock_queues();
kmem_free(kernel_map,
at-pte_array[i].virtual_address, PAGE_SIZE);
malloc_type_freed(M_NVIDIA, PAGE_SIZE);
I'll give it a quick shot on my desktop to see how things go.
FWIW, nvidia-driver-195.36.15 has been a rock solid release as well,
with or without the patch.
Cheers,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 06/14/10 19:14, Doug Barton wrote: Details, I'm running today's -current (r209174) and I've had it up for 4.5 hours already, which is 3 hours longer than I was able to run with anything 195.22 for months. I've done full normal use which includes lots of terminals, tbird, firefox, flash, etc. I may have spoke too soon. About 90 minutes after sending this message, and after 1 hour+ of watching a flash video (a CISSP training course) I got a lockup which required me to power off my laptop. After fsck'ing I got back to my desktop, opened firefox, opened my flash video again, and it locked up almost instantly. This time I got a core though. I'm not sure if this is related to the nvidia driver or not, but there 'tis: Unread portion of the kernel message buffer: panic: mi_switch: switch in a critical section cpuid = 1 panic: bufwrite: buffer is not busy??? cpuid = 1 Uptime: 11m11s #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc05f697f in boot (howto=260) at /usr/local/src/sys/kern/kern_shutdown.c:416 #2 0xc05f6c62 in panic (fmt=Variable fmt is not available. ) at /usr/local/src/sys/kern/kern_shutdown.c:590 #3 0xc07f881e in ffs_bufwrite (bp=0xd8d687f8) at /usr/local/src/sys/ufs/ffs/ffs_vfsops.c:1858 #4 0xc066bfa8 in vfs_bio_awrite (bp=0xd8d687f8) at buf.h:386 #5 0xc067592b in vop_stdfsync (ap=0xd8f59c6c) at /usr/local/src/sys/kern/vfs_default.c:650 #6 0xc0588a5c in devfs_fsync (ap=0xd8f59c6c) at /usr/local/src/sys/fs/devfs/devfs_vnops.c:566 #7 0xc088ec95 in VOP_FSYNC_APV (vop=0xc0947080, a=0xd8f59c6c) at vnode_if.c:1267 #8 0xc0686928 in sync_vnode (slp=0xc4f50bf8, bo=0xd8f59cd8, td=0xc5964780) at vnode_if.h:549 #9 0xc0686c73 in sched_sync () at /usr/local/src/sys/kern/vfs_subr.c:1819 #10 0xc05cd378 in fork_exit (callout=0xc0686a00 sched_sync, arg=0x0, frame=0xd8f59d28) at /usr/local/src/sys/kern/kern_fork.c:843 #11 0xc08568d0 in fork_trampoline () at /usr/local/src/sys/i386/i386/exception.s:270 (kgdb) Full file is core.txt.2 in my freefall home directory. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 06/01/10 08:26, John Baldwin wrote: I've asked the driver author if the calls to vm_page_wire() and vm_page_unwire() can simply be removed but have not heard back yet. Is there any news on this? I have updated to the latest current so I'm running the nv driver now, but I'd like to get the nvidia driver running again. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Sun, Jun 13, 2010 at 8:38 PM, Doug Barton do...@freebsd.org wrote: On 06/01/10 08:26, John Baldwin wrote: I've asked the driver author if the calls to vm_page_wire() and vm_page_unwire() can simply be removed but have not heard back yet. Is there any news on this? I have updated to the latest current so I'm running the nv driver now, but I'd like to get the nvidia driver running again. Yes, the unnecessary (and now problematic) wiring and unwiring calls will be removed in a future release of the driver. Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 06/13/10 19:09, Alan Cox wrote: On Sun, Jun 13, 2010 at 8:38 PM, Doug Bartondo...@freebsd.org wrote: On 06/01/10 08:26, John Baldwin wrote: I've asked the driver author if the calls to vm_page_wire() and vm_page_unwire() can simply be removed but have not heard back yet. Is there any news on this? I have updated to the latest current so I'm running the nv driver now, but I'd like to get the nvidia driver running again. Yes, the unnecessary (and now problematic) wiring and unwiring calls will be removed in a future release of the driver. Excellent! Any ETA? Or are there patches against an existing version of the driver? Thanks, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Sat, May 29, 2010 at 12:31 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, May 29, 2010 at 11:48 AM, datastream datastream.freecity datastream.freec...@gmail.com wrote: On Sun, May 30, 2010 at 2:11 AM, Doug Barton do...@freebsd.org wrote: On 05/26/10 09:51, Kostik Belousov wrote: I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. Ok, I just tried this with an r208622 kernel and sources, and the system locks up as soon as I type 'startx'. No panic, no core dump, it just wedges, requiring it to be powered off. http://www.nvnews.net/vbulletin/showthread.php?t=150719 NVIDIA-FreeBSD-x86_64-195.36.24 with r208117 in my T61 laptop works well. I'll try out this driver then. I'll have to see what the delta was with the kernel glue... Thanks for the feedback, nvidia-driver-195.36.24 works really well with my kernel so far. I'm going to soak the driver in for a few hours while I'm building a new kernel to see what HEAD provides as far as stability is concerned today. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Saturday 29 May 2010 10:55:41 pm Craig Rodrigues wrote: On Sun, May 30, 2010 at 02:48:13AM +0800, datastream datastream.freecity wrote: http://www.nvnews.net/vbulletin/showthread.php?t=150719 NVIDIA-FreeBSD-x86_64-195.36.24 with r208117 in my T61 laptop works well. Hi, I did the following: - updated r208649 - applied following patch to nvidia-driver port which bumps driver version up to 195.36.24, and also applies kib's patch My system still hangs after doing a startx. I also tried recompiling the driver *without* kib's patch, and my system still hangs. I've asked the driver author if the calls to vm_page_wire() and vm_page_unwire() can simply be removed but have not heard back yet. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 05/26/10 09:51, Kostik Belousov wrote: I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. Ok, I just tried this with an r208622 kernel and sources, and the system locks up as soon as I type 'startx'. No panic, no core dump, it just wedges, requiring it to be powered off. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Sun, May 30, 2010 at 2:11 AM, Doug Barton do...@freebsd.org wrote: On 05/26/10 09:51, Kostik Belousov wrote: I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patchhttp://people.freebsd.org/%7Ekib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. Ok, I just tried this with an r208622 kernel and sources, and the system locks up as soon as I type 'startx'. No panic, no core dump, it just wedges, requiring it to be powered off. http://www.nvnews.net/vbulletin/showthread.php?t=150719 NVIDIA-FreeBSD-x86_64-195.36.24 with r208117 in my T61 laptop works well. Thanks, Kevin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Sat, May 29, 2010 at 11:48 AM, datastream datastream.freecity datastream.freec...@gmail.com wrote: On Sun, May 30, 2010 at 2:11 AM, Doug Barton do...@freebsd.org wrote: On 05/26/10 09:51, Kostik Belousov wrote: I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. Ok, I just tried this with an r208622 kernel and sources, and the system locks up as soon as I type 'startx'. No panic, no core dump, it just wedges, requiring it to be powered off. http://www.nvnews.net/vbulletin/showthread.php?t=150719 NVIDIA-FreeBSD-x86_64-195.36.24 with r208117 in my T61 laptop works well. I'll try out this driver then. I'll have to see what the delta was with the kernel glue... Thanks for the feedback, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Sun, May 30, 2010 at 02:48:13AM +0800, datastream datastream.freecity wrote:
http://www.nvnews.net/vbulletin/showthread.php?t=150719
NVIDIA-FreeBSD-x86_64-195.36.24 with r208117 in my T61 laptop works well.
Hi,
I did the following:
- updated r208649
- applied following patch to nvidia-driver port which bumps driver version
up to 195.36.24, and also applies kib's patch
My system still hangs after doing a startx.
I also tried recompiling the driver *without* kib's patch, and my
system still hangs.
--
Craig Rodrigues
rodr...@crodrigues.org
? a.txt
? nvidia-vm_page_lock.1.patch
? work
Index: Makefile
===
RCS file: /home/pcvs/ports/x11/nvidia-driver/Makefile,v
retrieving revision 1.98
diff -r1.98 Makefile
9c9
DISTVERSION?= 195.36.15
---
DISTVERSION?= 195.36.24
Index: distinfo
===
RCS file: /home/pcvs/ports/x11/nvidia-driver/distinfo,v
retrieving revision 1.36
diff -r1.36 distinfo
1,15c1,3
MD5 (NVIDIA-FreeBSD-x86-195.36.15.tar.gz) = 2537ca726240344c7eaa44857e2b134e
SHA256 (NVIDIA-FreeBSD-x86-195.36.15.tar.gz) =
21fc89fa59e2cc96e560af856a3fa583ce4bfb7975465c71170c64962201e7a1
SIZE (NVIDIA-FreeBSD-x86-195.36.15.tar.gz) = 25614326
MD5 (NVIDIA-FreeBSD-x86_64-195.36.15.tar.gz) =
95af03aedc818a3dfd8ae9f289746ba4
SHA256 (NVIDIA-FreeBSD-x86_64-195.36.15.tar.gz) =
d64c664398cb4dade24af6b108e03607614f1f7584c71449230c646c313d0e7e
SIZE (NVIDIA-FreeBSD-x86_64-195.36.15.tar.gz) = 26449559
MD5 (NVIDIA-FreeBSD-x86-173.14.25.tar.gz) = 1eca3916a9ae86b953f54405e1881774
SHA256 (NVIDIA-FreeBSD-x86-173.14.25.tar.gz) =
c432ed94ce71e297b2d9304d9f34f906b58e2c7c4bc13d8dbac264ed52fd6261
SIZE (NVIDIA-FreeBSD-x86-173.14.25.tar.gz) = 16682722
MD5 (NVIDIA-FreeBSD-x86-96.43.16.tar.gz) = 3fc5c2bb537d4a7664d84a7a0df09c7c
SHA256 (NVIDIA-FreeBSD-x86-96.43.16.tar.gz) =
38bf334284dc600d92d8436333c98d5577e34d69456ed71f175caa6dffcd
SIZE (NVIDIA-FreeBSD-x86-96.43.16.tar.gz) = 11842453
MD5 (NVIDIA-FreeBSD-x86-71.86.13.tar.gz) = 19000b906225ebd39ca3edc1b0c3c7a5
SHA256 (NVIDIA-FreeBSD-x86-71.86.13.tar.gz) =
27ae01cd6fe050871f7785c2146b18e74ea882f6262e46dc965bf26061238447
SIZE (NVIDIA-FreeBSD-x86-71.86.13.tar.gz) = 8066159
---
MD5 (NVIDIA-FreeBSD-x86-195.36.24.tar.gz) = b09ee65d4d445fe8679e50bc49bba8c7
SHA256 (NVIDIA-FreeBSD-x86-195.36.24.tar.gz) =
d175c6848ac174f4c0c54ce7325959e21132f833e13d34004fab116c7034244f
SIZE (NVIDIA-FreeBSD-x86-195.36.24.tar.gz) = 25632339
Index: files/patch-nvidia-vm_page_lock.1
===
RCS file: files/patch-nvidia-vm_page_lock.1
diff -N files/patch-nvidia-vm_page_lock.1
0a1,34
--- src/nvidia_subr.c.orig2010-05-26 19:34:20.722118986 +0300
+++ src/nvidia_subr.c 2010-05-26 19:50:00.198768786 +0300
@@ -1237,6 +1237,7 @@
struct nvidia_alloc *at;
struct nvidia_softc *sc = nv-os_state;
vm_offset_t address;
+vm_page_t m;
uint32_t i;
vm_memattr_t attr;
uint32_t size = (count * PAGE_SIZE);
@@ -1301,9 +1302,10 @@
for (i = 0; i count; i++) {
pte_array[i] = at-pte_array[i].physical_address;
-vm_page_lock_queues();
-vm_page_wire(PHYS_TO_VM_PAGE(pte_array[i]));
-vm_page_unlock_queues();
+m = PHYS_TO_VM_PAGE(pte_array[i]);
+vm_page_lock(m);
+vm_page_wire(m);
+vm_page_unlock(m);
sglist_append_phys(at-sg_list, pte_array[i], PAGE_SIZE);
}
@@ -1365,9 +1367,7 @@
os_flush_cpu_cache();
for (i = 0; i count; i++) {
-vm_page_lock_queues();
vm_page_unwire(PHYS_TO_VM_PAGE(at-pte_array[i].physical_address),
0);
-vm_page_unlock_queues();
kmem_free(kernel_map,
at-pte_array[i].virtual_address, PAGE_SIZE);
malloc_type_freed(M_NVIDIA, PAGE_SIZE);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 05/26/10 09:51, Kostik Belousov wrote: I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. cc -pipe -g -g -g -DNV_VERSION_STRING=\195.36.15\ -D__KERNEL__ -DNVRM -O -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c nvidia_subr.c cc1: warnings being treated as errors nvidia_subr.c: In function 'nv_alloc_system_pages': nvidia_subr.c:1306: warning: implicit declaration of function 'vm_page_lock' nvidia_subr.c:1306: warning: nested extern declaration of 'vm_page_lock' nvidia_subr.c:1308: warning: implicit declaration of function 'vm_page_unlock' nvidia_subr.c:1308: warning: nested extern declaration of 'vm_page_unlock' *** Error code 1 FYI, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Thu, May 27, 2010 at 11:54:27AM -0700, Doug Barton wrote: On 05/26/10 09:51, Kostik Belousov wrote: I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. cc -pipe -g -g -g -DNV_VERSION_STRING=\195.36.15\ -D__KERNEL__ -DNVRM -O -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c nvidia_subr.c cc1: warnings being treated as errors nvidia_subr.c: In function 'nv_alloc_system_pages': nvidia_subr.c:1306: warning: implicit declaration of function 'vm_page_lock' nvidia_subr.c:1306: warning: nested extern declaration of 'vm_page_lock' nvidia_subr.c:1308: warning: implicit declaration of function 'vm_page_unlock' nvidia_subr.c:1308: warning: nested extern declaration of 'vm_page_unlock' *** Error code 1 I think you have stale/wrong includes used by the build. I just checked that driver indeed builds with my patch. vm_page_lock() and vm_page_unlock() are the macros defined in vm/vm_page.h that are present since first Kip commit. Look at the target of the @ symlink in the driver directory. pgpiZJZqxEpWj.pgp Description: PGP signature
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 5/27/2010 12:12 PM, Kostik Belousov wrote: I think you have stale/wrong includes used by the build. I just checked that driver indeed builds with my patch. vm_page_lock() and vm_page_unlock() are the macros defined in vm/vm_page.h that are present since first Kip commit. As I reported earlier, I am using an older kernel atm for stability reasons. I will try again with a more up to date kernel when time allows. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
Garrett Cooper wrote: Just reporting the fact that nvidia-driver 195.22 is horribly broken between r206173 and r208486 (my machine consistency livelocks at X11 startup); the latest driver is still broken as well with the same symptoms. I realize that's a huge revision difference, and I'll definitely try and track down the root cause via a binary search, but I wanted to make sure that other folks knew of the issue and don't upgrade and their systems break horribly as well. I suspect that the locking changes are causing the issue, but I don't have any hard data to backup my claim at this time. I'm sure they are. The Nvidia driver directly accesses low-level virtual memory structures on which the synchronization rules have changed. (In contrast, the Xorg dri drivers in our source tree are using higher-level interfaces that have remained stable.) I don't think that a binary search is needed. The lock assertion failures should indicate most if not all of the changes that are needed in the driver. When Kip got this process started, he bumped FreeBSD_version, so it should be possible to condition the locking changes in the driver. Good luck! Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Wed, May 26, 2010 at 11:23:02AM -0500, Alan Cox wrote: Garrett Cooper wrote: Just reporting the fact that nvidia-driver 195.22 is horribly broken between r206173 and r208486 (my machine consistency livelocks at X11 startup); the latest driver is still broken as well with the same symptoms. I realize that's a huge revision difference, and I'll definitely try and track down the root cause via a binary search, but I wanted to make sure that other folks knew of the issue and don't upgrade and their systems break horribly as well. I suspect that the locking changes are causing the issue, but I don't have any hard data to backup my claim at this time. I'm sure they are. The Nvidia driver directly accesses low-level virtual memory structures on which the synchronization rules have changed. (In contrast, the Xorg dri drivers in our source tree are using higher-level interfaces that have remained stable.) I don't think that a binary search is needed. The lock assertion failures should indicate most if not all of the changes that are needed in the driver. When Kip got this process started, he bumped FreeBSD_version, so it should be possible to condition the locking changes in the driver. Good luck! I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. pgpb0ONXeqTA4.pgp Description: PGP signature
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
Kostik Belousov wrote: On Wed, May 26, 2010 at 11:23:02AM -0500, Alan Cox wrote: Garrett Cooper wrote: Just reporting the fact that nvidia-driver 195.22 is horribly broken between r206173 and r208486 (my machine consistency livelocks at X11 startup); the latest driver is still broken as well with the same symptoms. I realize that's a huge revision difference, and I'll definitely try and track down the root cause via a binary search, but I wanted to make sure that other folks knew of the issue and don't upgrade and their systems break horribly as well. I suspect that the locking changes are causing the issue, but I don't have any hard data to backup my claim at this time. I'm sure they are. The Nvidia driver directly accesses low-level virtual memory structures on which the synchronization rules have changed. (In contrast, the Xorg dri drivers in our source tree are using higher-level interfaces that have remained stable.) I don't think that a binary search is needed. The lock assertion failures should indicate most if not all of the changes that are needed in the driver. When Kip got this process started, he bumped FreeBSD_version, so it should be possible to condition the locking changes in the driver. Good luck! I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. The second snippet looks weird to me, specifically, seeing an explicit unwiring before a kmem_free() call. Should the corresponding allocation be using kmem_alloc_attr()? Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 5/26/2010 9:51 AM, Kostik Belousov wrote: I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. Kostik, Thanks for taking a look at this! I sent the following to Alexey recently in regards to his query about whether or not the new version of the driver works. Maybe it will assist you: Good news, it was a simple version bump to upgrade to 195.36.24. Bad news, no improvement. Under very light load (X11 using openbox, Alpine mail client) it lasted about an hour. As soon as I started adding more stress (firefox, flash, etc.) it wedged after about 30 minutes (total uptime, 90 minutes). This was still on the old kernel that I've been using in combination with 195.22: FreeBSD dougb.net 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r207134: Thu Apr 29 23:14:20 PDT 2010 i386 The combination of the r207134 kernel and the 195.22 version of the driver has been very stable for me. If I try to go newer than that in either category I get lockups and/or panics. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Wed, May 26, 2010 at 10:41 AM, Alan Cox a...@cs.rice.edu wrote: Kostik Belousov wrote: On Wed, May 26, 2010 at 11:23:02AM -0500, Alan Cox wrote: Garrett Cooper wrote: Just reporting the fact that nvidia-driver 195.22 is horribly broken between r206173 and r208486 (my machine consistency livelocks at X11 startup); the latest driver is still broken as well with the same symptoms. I realize that's a huge revision difference, and I'll definitely try and track down the root cause via a binary search, but I wanted to make sure that other folks knew of the issue and don't upgrade and their systems break horribly as well. I suspect that the locking changes are causing the issue, but I don't have any hard data to backup my claim at this time. I'm sure they are. The Nvidia driver directly accesses low-level virtual memory structures on which the synchronization rules have changed. (In contrast, the Xorg dri drivers in our source tree are using higher-level interfaces that have remained stable.) I don't think that a binary search is needed. The lock assertion failures should indicate most if not all of the changes that are needed in the driver. When Kip got this process started, he bumped FreeBSD_version, so it should be possible to condition the locking changes in the driver. Good luck! I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. The second snippet looks weird to me, specifically, seeing an explicit unwiring before a kmem_free() call. Should the corresponding allocation be using kmem_alloc_attr()? I'm by no means an expert in this area, but isn't removing the locking on free a bad thing? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Wed, May 26, 2010 at 12:41:51PM -0500, Alan Cox wrote: Kostik Belousov wrote: On Wed, May 26, 2010 at 11:23:02AM -0500, Alan Cox wrote: Garrett Cooper wrote: Just reporting the fact that nvidia-driver 195.22 is horribly broken between r206173 and r208486 (my machine consistency livelocks at X11 startup); the latest driver is still broken as well with the same symptoms. I realize that's a huge revision difference, and I'll definitely try and track down the root cause via a binary search, but I wanted to make sure that other folks knew of the issue and don't upgrade and their systems break horribly as well. I suspect that the locking changes are causing the issue, but I don't have any hard data to backup my claim at this time. I'm sure they are. The Nvidia driver directly accesses low-level virtual memory structures on which the synchronization rules have changed. (In contrast, the Xorg dri drivers in our source tree are using higher-level interfaces that have remained stable.) I don't think that a binary search is needed. The lock assertion failures should indicate most if not all of the changes that are needed in the driver. When Kip got this process started, he bumped FreeBSD_version, so it should be possible to condition the locking changes in the driver. Good luck! I did a quick glance over the driver, try this: http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch I did not even compiled the patched driver. The second snippet looks weird to me, specifically, seeing an explicit unwiring before a kmem_free() call. Should the corresponding allocation be using kmem_alloc_attr()? I have no idea about lifecycle of the unmanaged pages in nvidia driver. The weird thing is that the pages are wired explicitely by a call to vm_page_wire(9) at all. The pages are allocated by contigmapping(9), that already wires the region. Possibly this is done to signify two references to the page, second one is by sg list that is stuffed with the pages immediately after. My goal was to fix an obvious misusage of the KPI. pgpUVla5Sj2bw.pgp Description: PGP signature
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
I'm by no means an expert in this area, but isn't removing the locking on free a bad thing? Looking at the code, it seems that vm_page_unwire() only requires the page to be locked if it is managed. As it was acquired by contigmalloc, the page should be unmanaged so that should be ok. I am confused as to why vm_page_unwire() does not require the page to be locked if the page is unmanaged. What is synchronizing the accesses to m-wire_count? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 5/26/2010 2:56 PM, Ryan Stone wrote: I'm by no means an expert in this area, but isn't removing the locking on free a bad thing? Looking at the code, it seems that vm_page_unwire() only requires the page to be locked if it is managed. As it was acquired by contigmalloc, the page should be unmanaged so that should be ok. I am confused as to why vm_page_unwire() does not require the page to be locked if the page is unmanaged. What is synchronizing the accesses to m-wire_count? You can think of unmanaged pages as being private. Not necessarily private to a thread or processor, but private to some entity, such as a particular process's page table. So, no one else, such as the page daemon, is going to be concurrently accessing the wire count field of the page, and thus, no page or page queues locking is needed. Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
Just reporting the fact that nvidia-driver 195.22 is horribly broken between r206173 and r208486 (my machine consistency livelocks at X11 startup); the latest driver is still broken as well with the same symptoms. I realize that's a huge revision difference, and I'll definitely try and track down the root cause via a binary search, but I wanted to make sure that other folks knew of the issue and don't upgrade and their systems break horribly as well. I suspect that the locking changes are causing the issue, but I don't have any hard data to backup my claim at this time. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 05/26/2010 12:00 AM, Garrett Cooper wrote: Just reporting the fact that nvidia-driver 195.22 is horribly broken between r206173 and r208486 (my machine consistency livelocks at X11 startup); the latest driver is still broken as well with the same symptoms. I realize that's a huge revision difference, and I'll definitely try and track down the root cause via a binary search, but I wanted to make sure that other folks knew of the issue and don't upgrade and their systems break horribly as well. I suspect that the locking changes are causing the issue, but I don't have any hard data to backup my claim at this time. Thanks, -Garrett same goes for nvidia-driver-96. nv seems unaffected though. (thankfully i rarely need X on that machine) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
