Kernel panic -- Memory modified after free
I upgraded my kernel yesterday, after testing alc@'s patch for mmu_oea (PowerPC 32-bit, AIM), and now I'm seeing the kernel panic in the subject. Unfortunately, I didn't keep my knonw-good working kernel from prior to testing alc@'s patch, so the most recent kernel I have that works is from over a year ago, so booting to it means I get no networking, as the ABI has changed. With this, every time it panics, it shows Most recently used by 'bus'. Has anyone else seen this kind panic from recent kernels? For further testing, I tried downloading the kernel tarball from allbsd.org, from the 20120601 snapshot, and that also shows the same panic. Also, this only occurs on my G4 tower, which is a dual processor machine. The exact same kernels work fine on my PowerBook, which is single processor. - Justin ___ 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: panic after starting X with r238120
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.07.2012 05:14, Steve Wills wrote: For what it's worth, I discovered that twm and xterm don't trigger the issue, but konsole and other kde things do, which is what led me to discover that setting kern.ipc.shm_use_phys back to default fixed it. I encountered the same issue with x11-wm/awesome, but everything's ok with twm. A kernel from 2012-06-23 doesn't crash but a kernel from 2012-07-03 does crash. Here're the sysctls/tunables I have regarding shm: In /boot/loader.conf: kern.ipc.shmmni=1024 kern.ipc.shmseg=1024 In /etc/sysctl.conf: kern.ipc.shmmax=2147483648 kern.ipc.shm_use_phys=1 kern.ipc.shm_allow_removed=1 - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/5QesACgkQa+xGJsFYOlPRwQCcClck3824nWltHoIVzuzmLBLz dyUAoIhVeREUZH26QdcJkyyXfna9LYQQ =mKU0 -END PGP SIGNATURE- ___ 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: Occassional permission denied in the middle of a large transfer over NFS
On 08/07/2012 00:26, Rick Macklem wrote: Vincent Hoffman wrote: Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. Just to confirm, you patched both the kernel and mountd and replaced both on the server? Also, I'm not sure how ZFS handles it's exports. I can't remember if you've tried an exported UFS volume. It might be something ZFS specific? rick Hi Rick, yes I patched both the kernel and mountd, rebuilt kernel and world (to be sure), added the -S flag to mountd in rc.conf and rebooted. This is a test VM running -CURRENT and is only exporting a ufs2 filesystem. (11:43:05 ~) 0 $ cat /etc/exports /usr/local/export -maproot=root -alldirs XX.XX.XX.XX Client is a 8.3-RELEASE box but I see the same with linux clients. (I can confirm that it works fine when I am not running the mount/umount loop) The production system has been fine since I removed the SIGHUP call in mount.c so thanks for that suggestion. Vince [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min Max Median Avg Stddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21 186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Thanks for all your work on NFS on FreeBSD. Vince Also, you could easily hack mount.c so that it doesn't send a SIGHUP to mountd (which causes the exports to be reloaded) every time a local fs is mounted. True and I may have to do that for the production NAS for the time being. Thanks for looking at this. Vince rick thanks, Vince ___ 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 ___ 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
sleeping thread panic?
Sorry, no symbols but this happened twice last night while being the target of a dump over NFS .. root@mail:/var/crash # less info.0 Dump header from device /dev/ada0s1 Architecture: i386 Architecture Version: 2 Dump Length: 252809216B (241 MB) Blocksize: 512 Dumptime: Sun Jul 8 00:21:23 2012 Hostname: mail.auburn.protected-networks.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012 r...@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN Panic String: sleeping thread Dump Parity: 2996346376 Bounds: 0 Dump Status: good (kgdb) bt #0 0xc07530cd in doadump () #1 0xc0753656 in kern_reboot () #2 0xc0753cfc in panic () #3 0xc079a34e in propagate_priority () #4 0xc079b5e4 in turnstile_wait () #5 0xc073ea71 in _mtx_lock_sleep () #6 0xc09c4772 in vm_page_unwire () #7 0xc07db039 in vfs_vmio_release () #8 0xc07dd476 in getnewbuf () #9 0xc07de50b in getblk () #10 0xc0966d99 in ffs_balloc_ufs2 () #11 0xc099281e in ffs_write () #12 0xc0a38b05 in VOP_WRITE_APV () #13 0xc068a65e in nfsvno_write () #14 0xc06882e7 in nfsrvd_write () #15 0xc066ea05 in nfsrvd_dorpc () #16 0xc067d42f in nfssvc_program () #17 0xc09356e2 in svc_run_internal () #18 0xc0935b70 in svc_thread_start () #19 0xc07204fb in fork_exit () #20 0xc09fe7a4 in fork_trampoline () ___ 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: Use of C99 extra long double math functions after r236148
On Tue, May 29, 2012, Peter Jeremy wrote: On 2012-May-28 15:54:06 -0700, Steve Kargl s...@troutmask.apl.washington.edu wrote: Given that cephes was written years before C99 was even conceived, I suspect all functions are sub-standard. Well, most of cephes was written before C99. The C99 parts of cephes were written to turn it into a complete C99 implementation. I'm a bit late to the party, but I thought I'd chime in with some context. We did consider using Cephes years ago, and even got permission from the author to release it under an acceptable license. We later decided not to use it for technical reasons. By the way, virtually none of the people who have complained about the missing functions actually need them. Mostly they just want to compile some software that was written by a naive programmer who thought it would be cool to use the most precise type available. The complex functions are even less commonly needed, and the truth is that they have no business being part of the C standard anyway. The question remains of what to do about the missing functions. Bruce and Steve have been working on expl and logl for years. If those ever get in the tree, the remaining long double functions are easy. Those functions are basically done, modulo a bunch of cleanup and testing, and I encourage any mathematically inclined folks who are interested in pushing things along to get in touch with them. I'm not going to have any time myself for a few months at least. Lastly, there's the question of mediocre alternatives, such as solutions that get the boundary cases wrong or don't handle 128-bit floating point. For the exponential and logarithmic functions, Bruce and Steve have already written good implementations, so there's no reason to settle for less. As for the other long double functions, bringing in some Cephes code in a separate directory as a temporary fix might be the way to go. I don't like that solution, and Steve raises some good technical points about why it isn't ideal; however, a better solution is more than a decade overdue, and people are justified in finding that unacceptable. ___ 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: panic after starting X with r238120
On Sun, Jul 08, 2012 at 10:16:44AM +0200, Jean-S?bastien P?dron wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.07.2012 05:14, Steve Wills wrote: For what it's worth, I discovered that twm and xterm don't trigger the issue, but konsole and other kde things do, which is what led me to discover that setting kern.ipc.shm_use_phys back to default fixed it. I encountered the same issue with x11-wm/awesome, but everything's ok with twm. A kernel from 2012-06-23 doesn't crash but a kernel from 2012-07-03 does crash. Here're the sysctls/tunables I have regarding shm: In /boot/loader.conf: kern.ipc.shmmni=1024 kern.ipc.shmseg=1024 In /etc/sysctl.conf: kern.ipc.shmmax=2147483648 kern.ipc.shm_use_phys=1 kern.ipc.shm_allow_removed=1 You know, this is not much useful ? Backtrace is. pgpzNDWbkQj3b.pgp Description: PGP signature
Re: sleeping thread panic?
On Sun, Jul 08, 2012 at 08:46:32AM -0400, Michael Butler wrote: Sorry, no symbols but this happened twice last night while being the target of a dump over NFS .. root@mail:/var/crash # less info.0 Dump header from device /dev/ada0s1 Architecture: i386 Architecture Version: 2 Dump Length: 252809216B (241 MB) Blocksize: 512 Dumptime: Sun Jul 8 00:21:23 2012 Hostname: mail.auburn.protected-networks.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012 r...@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN Panic String: sleeping thread Dump Parity: 2996346376 Bounds: 0 Dump Status: good (kgdb) bt #0 0xc07530cd in doadump () #1 0xc0753656 in kern_reboot () #2 0xc0753cfc in panic () #3 0xc079a34e in propagate_priority () #4 0xc079b5e4 in turnstile_wait () #5 0xc073ea71 in _mtx_lock_sleep () #6 0xc09c4772 in vm_page_unwire () #7 0xc07db039 in vfs_vmio_release () #8 0xc07dd476 in getnewbuf () #9 0xc07de50b in getblk () #10 0xc0966d99 in ffs_balloc_ufs2 () #11 0xc099281e in ffs_write () #12 0xc0a38b05 in VOP_WRITE_APV () #13 0xc068a65e in nfsvno_write () #14 0xc06882e7 in nfsrvd_write () #15 0xc066ea05 in nfsrvd_dorpc () #16 0xc067d42f in nfssvc_program () #17 0xc09356e2 in svc_run_internal () #18 0xc0935b70 in svc_thread_start () #19 0xc07204fb in fork_exit () #20 0xc09fe7a4 in fork_trampoline () You need to provide: 1. exact version of your kernel sources 2. complete panic message. There should be backtrace of the 'sleeping thread', not the paniced thread, right after the panic message. pgpfXAiWhw0bI.pgp Description: PGP signature
Re: sleeping thread panic?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/12 09:34, Konstantin Belousov wrote: On Sun, Jul 08, 2012 at 08:46:32AM -0400, Michael Butler wrote: Sorry, no symbols but this happened twice last night while being the target of a dump over NFS .. root@mail:/var/crash # less info.0 Dump header from device /dev/ada0s1 Architecture: i386 Architecture Version: 2 Dump Length: 252809216B (241 MB) Blocksize: 512 Dumptime: Sun Jul 8 00:21:23 2012 Hostname: mail.auburn.protected-networks.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012 r...@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN Panic String: sleeping thread Dump Parity: 2996346376 Bounds: 0 Dump Status: good (kgdb) bt #0 0xc07530cd in doadump () #1 0xc0753656 in kern_reboot () #2 0xc0753cfc in panic () #3 0xc079a34e in propagate_priority () #4 0xc079b5e4 in turnstile_wait () #5 0xc073ea71 in _mtx_lock_sleep () #6 0xc09c4772 in vm_page_unwire () #7 0xc07db039 in vfs_vmio_release () #8 0xc07dd476 in getnewbuf () #9 0xc07de50b in getblk () #10 0xc0966d99 in ffs_balloc_ufs2 () #11 0xc099281e in ffs_write () #12 0xc0a38b05 in VOP_WRITE_APV () #13 0xc068a65e in nfsvno_write () #14 0xc06882e7 in nfsrvd_write () #15 0xc066ea05 in nfsrvd_dorpc () #16 0xc067d42f in nfssvc_program () #17 0xc09356e2 in svc_run_internal () #18 0xc0935b70 in svc_thread_start () #19 0xc07204fb in fork_exit () #20 0xc09fe7a4 in fork_trampoline () You need to provide: 1. exact version of your kernel sources This is the CVS equivalent of SVN r238221 2. complete panic message. There should be backtrace of the 'sleeping thread', not the paniced thread, right after the panic message. Sorry, that is the entire info file - nothing more than I've posted is logged, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5jyEACgkQQv9rrgRC1JLMGwCfZ+LwlzmVPgXvKz4BRAtEYk2W TI0Ani60MowM1vCvnyx68toimxcw7PYO =pdMc -END PGP SIGNATURE- ___ 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: sleeping thread panic?
On Sun, Jul 08, 2012 at 09:46:09AM -0400, Michael Butler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/08/12 09:34, Konstantin Belousov wrote:
On Sun, Jul 08, 2012 at 08:46:32AM -0400, Michael Butler wrote:
Sorry, no symbols but this happened twice last night while being the
target of a dump over NFS ..
root@mail:/var/crash # less info.0
Dump header from device /dev/ada0s1
Architecture: i386
Architecture Version: 2
Dump Length: 252809216B (241 MB)
Blocksize: 512
Dumptime: Sun Jul 8 00:21:23 2012
Hostname: mail.auburn.protected-networks.net
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012
r...@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN
Panic String: sleeping thread
Dump Parity: 2996346376
Bounds: 0
Dump Status: good
(kgdb) bt
#0 0xc07530cd in doadump ()
#1 0xc0753656 in kern_reboot ()
#2 0xc0753cfc in panic ()
#3 0xc079a34e in propagate_priority ()
#4 0xc079b5e4 in turnstile_wait ()
#5 0xc073ea71 in _mtx_lock_sleep ()
#6 0xc09c4772 in vm_page_unwire ()
#7 0xc07db039 in vfs_vmio_release ()
#8 0xc07dd476 in getnewbuf ()
#9 0xc07de50b in getblk ()
#10 0xc0966d99 in ffs_balloc_ufs2 ()
#11 0xc099281e in ffs_write ()
#12 0xc0a38b05 in VOP_WRITE_APV ()
#13 0xc068a65e in nfsvno_write ()
#14 0xc06882e7 in nfsrvd_write ()
#15 0xc066ea05 in nfsrvd_dorpc ()
#16 0xc067d42f in nfssvc_program ()
#17 0xc09356e2 in svc_run_internal ()
#18 0xc0935b70 in svc_thread_start ()
#19 0xc07204fb in fork_exit ()
#20 0xc09fe7a4 in fork_trampoline ()
You need to provide:
1. exact version of your kernel sources
This is the CVS equivalent of SVN r238221
2. complete panic message. There should be backtrace of the 'sleeping
thread', not the paniced thread, right after the panic message.
Sorry, that is the entire info file - nothing more than I've posted is
logged,
Catch it next time ? This should be quite reproducable, if real.
Actually, try this.
diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
index 9485fdd..de33afc 100644
--- a/sys/vm/vm_pageout.c
+++ b/sys/vm/vm_pageout.c
@@ -1030,7 +1030,6 @@ rescan0:
++pageout_lock_miss;
if (object-flags OBJ_MIGHTBEDIRTY)
vnodes_skipped++;
- vm_page_lock_queues();
goto unlock_and_continue;
}
KASSERT(mp != NULL,
@@ -1041,7 +1040,6 @@ rescan0:
if (vget(vp, LK_EXCLUSIVE | LK_TIMELOCK,
curthread)) {
VM_OBJECT_LOCK(object);
- vm_page_lock_queues();
++pageout_lock_miss;
if (object-flags OBJ_MIGHTBEDIRTY)
vnodes_skipped++;
@@ -1082,15 +1080,17 @@ rescan0:
* If the page has become held it might
* be undergoing I/O, so skip it
*/
+ KASSERT(queues_locked, (unlocked queues 2));
+ mtx_assert(vm_page_queue_mtx, MA_OWNED);
if (m-hold_count) {
- vm_page_lock_queues();
- queues_locked = TRUE;
vm_page_unlock(m);
vm_page_requeue(m);
if (object-flags OBJ_MIGHTBEDIRTY)
vnodes_skipped++;
goto unlock_and_continue;
}
+ vm_page_unlock_queues();
+ queues_locked = FALSE;
}
/*
pgpB71frPVvvV.pgp
Description: PGP signature
XSAVEOPT
Please find at http://people.freebsd.org/~kib/misc/xsaveopt.1.patch a patch to finally add suport for using XSAVEOPT for our amd64 context switch code. See Intel SDM for description of the XSAVEOPT instruction. Summary is that the instruction allows to not write parts of the FPU state which was not touched by the thread. Context switch then would write less to the PCB when thread is moved out from CPU. This is mainly to facilitate the ever-growing size of the FPU register file, in particular, AVX/YMM registers. Normal applications do not touch YMM, so saving them on each context switch if FPU was used is waste. Main complication is that any consumer of the ucontext_t still expect to see fully populated machine state, including the extended states which were not saved. Since CPU only avoids save when corresponding state is pristine, we can use the copy of initial state. CPUID provides an enumerator that allows OS to easily pick up neccesary area and copy over. I tried hard, but was unable to measure any statistically significant difference in the context switch times between XSAVE and XSAVEOPT using lmbench lat_ctx, on Core i7 2600K. pgpOO58de7n7q.pgp Description: PGP signature
Re: sleeping thread panic?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/08/12 10:31, Konstantin Belousov wrote:
Catch it next time ? This should be quite reproducable, if real.
Actually, try this.
diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
index 9485fdd..de33afc 100644
--- a/sys/vm/vm_pageout.c
+++ b/sys/vm/vm_pageout.c
@@ -1030,7 +1030,6 @@ rescan0:
++pageout_lock_miss;
if (object-flags OBJ_MIGHTBEDIRTY)
vnodes_skipped++;
- vm_page_lock_queues();
goto unlock_and_continue;
}
KASSERT(mp != NULL,
@@ -1041,7 +1040,6 @@ rescan0:
if (vget(vp, LK_EXCLUSIVE | LK_TIMELOCK,
curthread)) {
VM_OBJECT_LOCK(object);
- vm_page_lock_queues();
++pageout_lock_miss;
if (object-flags OBJ_MIGHTBEDIRTY)
vnodes_skipped++;
@@ -1082,15 +1080,17 @@ rescan0:
* If the page has become held it might
* be undergoing I/O, so skip it
*/
+ KASSERT(queues_locked, (unlocked queues 2));
+ mtx_assert(vm_page_queue_mtx, MA_OWNED);
if (m-hold_count) {
- vm_page_lock_queues();
- queues_locked = TRUE;
vm_page_unlock(m);
vm_page_requeue(m);
if (object-flags OBJ_MIGHTBEDIRTY)
vnodes_skipped++;
goto unlock_and_continue;
}
+ vm_page_unlock_queues();
+ queues_locked = FALSE;
}
/*
Just waiting for the second of two attached RAID arrays to finish
rebuilding and I'll give this a shot - thanks!
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (FreeBSD)
iEYEARECAAYFAk/5pKgACgkQQv9rrgRC1JKXAgCdEJhZIKRmLbAzIROKmN2WuZCU
mb4AnR3Z+BrN7uqwYnXwubBEBx/QlWf8
=Ne6G
-END PGP SIGNATURE-
___
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: sleeping thread panic?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/12 11:18, Michael Butler wrote: On 07/08/12 10:31, Konstantin Belousov wrote: Catch it next time ? This should be quite reproducable, if real. Actually, try this. diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index 9485fdd..de33afc 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1030,7 +1030,6 @@ rescan0: ++pageout_lock_miss; if (object-flags OBJ_MIGHTBEDIRTY) vnodes_skipped++; -vm_page_lock_queues(); goto unlock_and_continue; [ .. snip .. ] Just waiting for the second of two attached RAID arrays to finish rebuilding and I'll give this a shot - thanks! I repeated the dumps from last night over NFS with this patch installed and no more panics :-) imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5vAMACgkQQv9rrgRC1JJtPACgnyrSlf8jebp9iQLmTiXkaMYs /LUAn2BUlKUJ5aSMZ4biyqG9zZSRzPZA =WGNA -END PGP SIGNATURE- ___ 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: sleeping thread panic?
On Sun, Jul 08, 2012 at 12:57:39PM -0400, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/12 11:18, Michael Butler wrote: On 07/08/12 10:31, Konstantin Belousov wrote: Catch it next time ? This should be quite reproducable, if real. Actually, try this. diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index 9485fdd..de33afc 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1030,7 +1030,6 @@ rescan0: ++pageout_lock_miss; if (object-flags OBJ_MIGHTBEDIRTY) vnodes_skipped++; - vm_page_lock_queues(); goto unlock_and_continue; [ .. snip .. ] Just waiting for the second of two attached RAID arrays to finish rebuilding and I'll give this a shot - thanks! I repeated the dumps from last night over NFS with this patch installed and no more panics :-) But, are panics reproducable without the patch ? pgpmWE0hflEOj.pgp Description: PGP signature
Re: Occassional permission denied in the middle of a large transfer over NFS
On 07/07/2012 13:26, Vincent Hoffman wrote: On 01/07/2012 12:18, Rick Macklem wrote: Vincent Hoffman wrote: On 01/07/2012 01:53, Rick Macklem wrote: To modify mountd to use the kernel changes is more work than I have time for, in part because mountd.c is a very ugly old piece of C code, imho. I do have a patch that suspends/resumes execution of the nfsd threads (new, experimental for FreeBSD8.n only) when mountd reloads /etc/exports. This approach has certain disadvantages vs Andrey's transactional load/commit model, but it is simple and might be sufficient for your problem. If you want to try this patch, it is at: http://people.freebsd.org/~rmacklem/atomic-export.patch (The patch affects both the kernel and mountd.c.) Happy to try it, to be certain I have understood, this is for the newnfs server (experimental in 8.x default for 8 9+) Yes, that is correct. For the old (default on 8.x) it will have no effect. I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when i get a minute. Also, to enable it, you must add a -S flag to mountd_flags, after you've replaced the mountd executable. The patch is pretty straightforward, but has not seen much testing. Hopefully, it might be useful for you, rick Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min MaxMedian AvgStddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Replying to myself just as a record, I have tried nfse and I didnt get the permission denied at all. The only issue I had with it is that it strictly adheres to the syntax in exports(5) while mountd is a little more flexible. I had /usr/local/export -alldirs -maproot=root 85.xx.xx.xx /usr is the root of that filesystem mountd - allowed this but actually silently exports /usr (and all dirs below) nfse - didnt allow this, it needed to be the correct /usr -alldirs -maproot=root 85.xx.xx.xx which is I guess a POLA violation but follows the documentation. this was using nfse in mountd compatibility mode. I havent played with its more advanced features. Vince Thanks for all your work on NFS on FreeBSD. Vince ___ 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: sleeping thread panic?
On 07/08/2012 11:59, Konstantin Belousov wrote: On Sun, Jul 08, 2012 at 12:57:39PM -0400, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/12 11:18, Michael Butler wrote: On 07/08/12 10:31, Konstantin Belousov wrote: Catch it next time ? This should be quite reproducable, if real. Actually, try this. diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index 9485fdd..de33afc 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1030,7 +1030,6 @@ rescan0: ++pageout_lock_miss; if (object-flags OBJ_MIGHTBEDIRTY) vnodes_skipped++; - vm_page_lock_queues(); goto unlock_and_continue; [ .. snip .. ] Just waiting for the second of two attached RAID arrays to finish rebuilding and I'll give this a shot - thanks! I repeated the dumps from last night over NFS with this patch installed and no more panics :-) But, are panics reproducable without the patch ? The patch looks correct. I'm sorry that I didn't catch this problem when I reviewed the original patch yesterday. :-( I don't think that you really need these assertions: + KASSERT(queues_locked, (unlocked queues 2)); + mtx_assert(vm_page_queue_mtx, MA_OWNED); The control flow from the preceding acquire is straightforward and vm_page_requeue() itself asserts that the page queues lock is held. 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: Use of C99 extra long double math functions after r236148
On Jul 8, 2012, at 6:40 AM, David Schultz wrote: On Tue, May 29, 2012, Peter Jeremy wrote: On 2012-May-28 15:54:06 -0700, Steve Kargl s...@troutmask.apl.washington.edu wrote: Given that cephes was written years before C99 was even conceived, I suspect all functions are sub-standard. Well, most of cephes was written before C99. The C99 parts of cephes were written to turn it into a complete C99 implementation. I'm a bit late to the party, but I thought I'd chime in with some context. We did consider using Cephes years ago, and even got permission from the author to release it under an acceptable license. We later decided not to use it for technical reasons. By the way, virtually none of the people who have complained about the missing functions actually need them. Mostly they just want to compile some software that was written by a naive programmer who thought it would be cool to use the most precise type available. The complex functions are even less commonly needed, and the truth is that they have no business being part of the C standard anyway. The question remains of what to do about the missing functions. Bruce and Steve have been working on expl and logl for years. If those ever get in the tree, the remaining long double functions are easy. Those functions are basically done, modulo a bunch of cleanup and testing, and I encourage any mathematically inclined folks who are interested in pushing things along to get in touch with them. I'm not going to have any time myself for a few months at least. Where can I find these? Lastly, there's the question of mediocre alternatives, such as solutions that get the boundary cases wrong or don't handle 128-bit floating point. For the exponential and logarithmic functions, Bruce and Steve have already written good implementations, so there's no reason to settle for less. As for the other long double functions, bringing in some Cephes code in a separate directory as a temporary fix might be the way to go. I don't like that solution, and Steve raises some good technical points about why it isn't ideal; however, a better solution is more than a decade overdue, and people are justified in finding that unacceptable. Don't let the perfect be the enemy of the good. It is better to have OK implementations of these functions than none at all. We originally had so-so double support, but bruce spent many years optimizing them to make them very good. If we were just starting out, and hadn't let 10 years get behind us, I'd give the substandard argument some weight. But now that we're 13 years down the line from c99's publication I think we need to relax our standards a bit. I'd even argue that these functions being a little bad could easily spur people to make them better. Their absence makes people just #define llexp(x) lexp(x), etc. :( Warner Warner___ 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: panic after starting X with r238120
On Sun, Jul 8, 2012 at 3:16 AM, Jean-Sébastien Pédron dumbb...@freebsd.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.07.2012 05:14, Steve Wills wrote: For what it's worth, I discovered that twm and xterm don't trigger the issue, but konsole and other kde things do, which is what led me to discover that setting kern.ipc.shm_use_phys back to default fixed it. I encountered the same issue with x11-wm/awesome, but everything's ok with twm. A kernel from 2012-06-23 doesn't crash but a kernel from 2012-07-03 does crash. In r237513 on 6/23 I made a mistake that was corrected in r238124 on 7/5. I can vaguely see a connection between kern.ipc.shm_use_phys and the problem fixed in r238124. So, I'd like to know if this problem still exists. Wait, however, until you see Kostik commit a change to vm_pageout.c, before you update your system. Here're the sysctls/tunables I have regarding shm: In /boot/loader.conf: kern.ipc.shmmni=1024 kern.ipc.shmseg=1024 In /etc/sysctl.conf: kern.ipc.shmmax=2147483648 kern.ipc.shm_use_phys=1 kern.ipc.shm_allow_removed=1 - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/5QesACgkQa+xGJsFYOlPRwQCcClck3824nWltHoIVzuzmLBLz dyUAoIhVeREUZH26QdcJkyyXfna9LYQQ =mKU0 -END PGP SIGNATURE- ___ 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 ___ 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: Use of C99 extra long double math functions after r236148
Here is a technical question. I know that people always talk about ulp's in the context of how good a function implementation is. I think the ulp is the number of base 2 digits at the end of the mantissa that we cannot rely on. So if one were to write a naive implementation of lexp(x) that used Taylor's series if x is positive, and 1/lexp(-x) is x is negative - well one could fairly easily estimate an upper bound on the ulp, but it wouldn't be low (like ulp=1 or 2), but probably rather higher (ulp of the order of 10 or 20). So do people really work hard to get that last drop of ulp out of their calculations? Would a ulp=10 be considered unacceptable? Also, looking through the source code for the FreeBSD implementation of exp, I saw that they used some rather smart rational function. (I don't know how they came up with it.) Presumably a big part of the issue is to make the functions work rather fast. And a naive implementation of Taylor's series wouldn't be fast. But if people want lexp rather than exp, they must have already decided that accuracy is more important than speed. ___ 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: [CFT] Xorg 7.7 ready for testing!
Hello All! I'm created unofficial pkg repo for patched xorg tree. I'm still experimenting with it, but I already have built all required packages for CURRENT i386. You can find it here: http://pkgng.gits.kiev.ua/packages/test10-32-kmsxorg/ If anyone want to test new xorg, you can install all required packages using ports/pkg. pkg install -x xorg\* pkg install -x xf86\* pkg install xterm Also, you can try kde4 in this repo, pkg install kde I'll provide xorg testing enthusiasts with prebuilt images for simply boot it and report any feedback in near future. -- Regards, Alexander Yerenkow ___ 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: Use of C99 extra long double math functions after r236148
On Sun, Jul 08, 2012 at 11:51:56AM -0600, Warner Losh wrote: On Jul 8, 2012, at 6:40 AM, David Schultz wrote: On Tue, May 29, 2012, Peter Jeremy wrote: On 2012-May-28 15:54:06 -0700, Steve Kargl s...@troutmask.apl.washington.edu wrote: Given that cephes was written years before C99 was even conceived, I suspect all functions are sub-standard. Well, most of cephes was written before C99. The C99 parts of cephes were written to turn it into a complete C99 implementation. I'm a bit late to the party, but I thought I'd chime in with some context. We did consider using Cephes years ago, and even got permission from the author to release it under an acceptable license. We later decided not to use it for technical reasons. By the way, virtually none of the people who have complained about the missing functions actually need them. Mostly they just want to compile some software that was written by a naive programmer who thought it would be cool to use the most precise type available. The complex functions are even less commonly needed, and the truth is that they have no business being part of the C standard anyway. The question remains of what to do about the missing functions. Bruce and Steve have been working on expl and logl for years. If those ever get in the tree, the remaining long double functions are easy. Those functions are basically done, modulo a bunch of cleanup and testing, and I encourage any mathematically inclined folks who are interested in pushing things along to get in touch with them. I'm not going to have any time myself for a few months at least. Where can I find these? I've posted expl() a few times for the ld80 version. I don't have an ld128 version, which is why I have yet to submit a formal patch for expl(). I also have an ld80 expm1l(). I have a copy of bde's ld80 logl(). IIRC, bde wrote an ld128, but I don't have nor do I know if it has been tested. Lastly, there's the question of mediocre alternatives, such as solutions that get the boundary cases wrong or don't handle 128-bit floating point. For the exponential and logarithmic functions, Bruce and Steve have already written good implementations, so there's no reason to settle for less. As for the other long double functions, bringing in some Cephes code in a separate directory as a temporary fix might be the way to go. I don't like that solution, and Steve raises some good technical points about why it isn't ideal; however, a better solution is more than a decade overdue, and people are justified in finding that unacceptable. Don't let the perfect be the enemy of the good. It is better to have OK implementations of these functions than none at all. You'll need to define OK, because some of the implementations I've read are poor. I also hope that before anything is committed to libm that the person doing the committing does some rather thorough testing of the code. We originally had so-so double support, but bruce spent many years optimizing them to make them very good. If we were just starting out, and hadn't let 10 years get behind us, I'd give the substandard argument some weight. But now that we're 13 years down the line from c99's publication I think we need to relax our standards a bit. I'd even argue that these functions being a little bad could easily spur people to make them better. Their absence makes people just #define llexp(x) lexp(x), etc. :( Of course, the converse argument is that people have had 10 years to learn enough about floating point to actually write and submit code. I knew very little about FP before I wrote sqrtl(). I had a need for sqrtl() and so I went looking for a solution. PS: I also wrote sincos[fl](), which is very handy for the complex trig functions. -- Steve ___ 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: Occassional permission denied in the middle of a large transfer over NFS
Vincent Hoffman wrote: On 07/07/2012 13:26, Vincent Hoffman wrote: On 01/07/2012 12:18, Rick Macklem wrote: Vincent Hoffman wrote: On 01/07/2012 01:53, Rick Macklem wrote: To modify mountd to use the kernel changes is more work than I have time for, in part because mountd.c is a very ugly old piece of C code, imho. I do have a patch that suspends/resumes execution of the nfsd threads (new, experimental for FreeBSD8.n only) when mountd reloads /etc/exports. This approach has certain disadvantages vs Andrey's transactional load/commit model, but it is simple and might be sufficient for your problem. If you want to try this patch, it is at: http://people.freebsd.org/~rmacklem/atomic-export.patch (The patch affects both the kernel and mountd.c.) Happy to try it, to be certain I have understood, this is for the newnfs server (experimental in 8.x default for 8 9+) Yes, that is correct. For the old (default on 8.x) it will have no effect. I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when i get a minute. Also, to enable it, you must add a -S flag to mountd_flags, after you've replaced the mountd executable. The patch is pretty straightforward, but has not seen much testing. Hopefully, it might be useful for you, rick Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min Max Median Avg Stddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21 186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Replying to myself just as a record, I have tried nfse and I didnt get the permission denied at all. The only issue I had with it is that it strictly adheres to the syntax in exports(5) while mountd is a little more flexible. I had /usr/local/export -alldirs -maproot=root 85.xx.xx.xx /usr is the root of that filesystem mountd - allowed this but actually silently exports /usr (and all dirs below) Not exactly correct. mountd exports the entire file system in the kernel for the NFS server, since exports can only be attached to the mount points in the kernel. However, when the client's mount protocol requests a mount file handle for anything other than /usr/local/export, it will refuse that. (Which means that to mount anything other than /usr/local/export, the client must maliciously guess the file handle for mounting.) Put another way, a non-malicious NFSv3 client will only be able to mount /usr/local/export. Robert Watson calls this an administrative control and feels that it is necessary. Until this is resolved by the collective, I do not see how mountd can be replaced by nfse, although I'd like to see mountd replaced because of the above problem + mountd.c is very old, ugly (implies difficult to change) code. nfse - didnt allow this, it needed to be the correct /usr -alldirs -maproot=root 85.xx.xx.xx which is I guess a POLA violation but follows the documentation. this was using nfse in mountd compatibility mode. I havent played with its more advanced features. Vince Thanks for all your work on NFS on FreeBSD. Vince ___ 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 ___ 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: Use of C99 extra long double math functions after r236148
On Sun, Jul 08, 2012, Steve Kargl wrote: The question remains of what to do about the missing functions. Bruce and Steve have been working on expl and logl for years. If those ever get in the tree, the remaining long double functions are easy. Those functions are basically done, modulo a bunch of cleanup and testing, and I encourage any mathematically inclined folks who are interested in pushing things along to get in touch with them. I'm not going to have any time myself for a few months at least. Where can I find these? I've posted expl() a few times for the ld80 version. I don't have an ld128 version, which is why I have yet to submit a formal patch for expl(). I also have an ld80 expm1l(). I have a copy of bde's ld80 logl(). IIRC, bde wrote an ld128, but I don't have nor do I know if it has been tested. Yes, Bruce has ld128 versions, and clusteradm very kindly got us a sparc64 machine to test on. That was about the time I ran out of time to keep working on it. If someone wants to pick it up, that would be great. PS: I also wrote sincos[fl](), which is very handy for the complex trig functions. Yes, you should commit that! ___ 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: Use of C99 extra long double math functions after r236148
On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote:
Here is a technical question. I know that people always talk about
ulp's in the context of how good a function implementation is. I think
the ulp is the number of base 2 digits at the end of the mantissa that
we cannot rely on.
There are a few definitions of ULP (units in the last place).
Google 'Muller ULP' and check goldberg's paper (google
'goldberg floating point'.
Here's how I define ULP for my testing and the MPFR code.
/* From a das email:
ulps = err * (2**(LDBL_MANT_DIG - e)), where e = ilogb(z).
I use:
mpfr_sub(err, acc_out, approx_out, GMP_RNDN);
mpfr_abs(err, err, GMP_RNDN);
mpfr_mul_2si(ulpx, err, -mpfr_get_exp(acc_out) + LDBL_MANT_DIG, GMP_RNDN);
ulp = mpfr_get_d(ulpx, GMP_RNDN);
if (ulp 0.506 mpfr_cmpabs(err, ldbl_minx) 0) {
print warning...;
}
*/
#include gmp.h
#include mpfr.h
#include sgk.h
static mpfr_t mp_ulp_err;
/*
* Set the precision of the ULP computation.
*/
void
mp_ulp_init(int prec)
{
mpfr_init2(mp_ulp_err, (mpfr_prec_t)prec);
}
/*
* Given the 'approximate' value of a function and
* an 'accurate' value compute the ULP.
*/
double
mp_ulp(mpfr_t approximate, mpfr_t accurate, int dig)
{
double ulp;
mpfr_sub(mp_ulp_err, accurate, approximate, RD);
mpfr_abs(mp_ulp_err, mp_ulp_err, RD);
mpfr_mul_2si(mp_ulp_err, mp_ulp_err, - mpfr_get_exp(accurate) + dig,
RD);
ulp = mpfr_get_d(mp_ulp_err, RD);
return (ulp);
}
So if one were to write a naive implementation of lexp(x) that used
Taylor's series if x is positive, and 1/lexp(-x) is x is negative - well
one could fairly easily estimate an upper bound on the ulp, but it
wouldn't be low (like ulp=1 or 2), but probably rather higher (ulp of
the order of 10 or 20).
I've already written an ld80 expl(). I have tested billions if not
trillions of values. Don't recall the max ULP I saw, but I know it
was less than 1. I don't have an ld128 version, so I won't submit
a patch for libm.
So do people really work hard to get that last drop of ulp out of their
calculations?
I know very few scientist who work hard to reduce the ULP. Most
have little understanding of floating point.
Would a ulp=10 be considered unacceptable?
Yes, it is unacceptable for the math library. Remember ULPs
propagate and can quickly grow if the initial ulp for a
result is large.
Also, looking through the source code for the FreeBSD implementation of
exp, I saw that they used some rather smart rational function. (I don't
know how they came up with it.)
See Steven Moshier's book, which is the basis for CEPHES.
Instead of using a minimax polynomial approximation for
the function in some interval, one uses a minimax approximation
with a rational function.
--
Steve
___
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: Use of C99 extra long double math functions after r236148
On 07/08/2012 06:58 PM, Steve Kargl wrote: On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote: So do people really work hard to get that last drop of ulp out of their calculations? I know very few scientist who work hard to reduce the ULP. Most have little understanding of floating point. Would a ulp=10 be considered unacceptable? Yes, it is unacceptable for the math library. Remember ULPs propagate and can quickly grow if the initial ulp for a result is large. OK. But suppose I wanted ld80 precision. What would be the advantage of using an ld80 expl function with a ulp of 1 over an ld128 expl function with a ulp of 10? The error propagation in the latter case could not be worse than the error propagation in the latter case. In other words, if I were asked to write a super-fantastic expl function, where run time was not a problem, I would use mpfr, use Taylor's series with a floating point precision that had way more digits than I needed, and then just truncate away the last digits when returning the answer. And this would be guaranteed to give the correct answer to just above 0.5 ulp (which I assume is best possible). From a scientist's point of view, I would think ulp is a rather unimportant concept. The concepts of absolute and relative error are much more important to them. The only way I can see ULP errors greatly propagating is if one is performing iteration type calculations (like f(f(f(f(x). This sort of thing is done when computing Julia sets and such like. And in that case, as far as I can see, a slightly better ulp is not going to drastically change the limitations of whatever floating point precision you are using. ___ 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: Occassional permission denied in the middle of a large transfer over NFS
Vincent Hoffman:
On 08/07/2012 00:26, Rick Macklem wrote:
Vincent Hoffman wrote:
Hi Rick,
I'm afraid this didnt make any real difference for me.
Since I couldnt test it on the live system I tried it on a test vm.
on the vm (nfs server) I set a looping mount/umount
while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp
;
done
and on the client I set a loop of tars of large directorys to the
nfs
mount running under time to see how well it survived. Then
replicated
the test with the patch and without.
Just to confirm, you patched both the kernel and mountd and replaced
both
on the server?
Also, I'm not sure how ZFS handles it's exports. I can't remember if
you've
tried an exported UFS volume. It might be something ZFS specific?
rick
Hi Rick,
yes I patched both the kernel and mountd, rebuilt kernel and world (to
be sure), added the -S flag to mountd in rc.conf and rebooted.
This is a test VM running -CURRENT and is only exporting a ufs2
filesystem.
(11:43:05 ~) 0 $ cat /etc/exports
/usr/local/export -maproot=root -alldirs XX.XX.XX.XX
Client is a 8.3-RELEASE box but I see the same with linux clients.
(I can confirm that it works fine when I am not running the
mount/umount
loop)
Oops, the patch I sent you worked for NFSv4 only. If you also apply the
attached patch, it seems to work for NFSv3 as well.
The patch is also at:
http://people.freebsd.org/~rmacklem/atomic-export2.patch
You must also run the new/experimental server. (I can't remember if I
mentioned that before.)
rick
The production system has been fine since I removed the SIGHUP call in
mount.c so thanks for that suggestion.
Vince
[root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt
x nopatch.txt
+ atomicpatch.txt
+--+
|
*
|
|
*
|
|
x*
|
| xx*
x
|
| +x**
xx
|
| xxx
x
|
| xxx +x+
+
|
| +*xx +x+ x
+
|
| +*xx + +
x |
| *+*xx+ +++x * x
x |
| x**++*x+***x+ x*+ x ++*+ + x+ +x +
+ +|
|||___M_M_A__A___|__|
|
+--+
N Min Max Median Avg Stddev
x 101 1.25 106.8 14.08 21.892178 22.196005
+ 101 1.21 186.93 18.46 27.995842 30.523218
No difference proven at 95.0% confidence
(excuse wrapped ascii art)
I think I'll have a look at the nfse patch set and see how that
performs.
Thanks for all your work on NFS on FreeBSD.
Vince
Also, you could easily hack mount.c so that it doesn't send a
SIGHUP
to mountd (which causes the exports to be reloaded) every time a
local
fs is mounted.
True and I may have to do that for the production NAS for the
time
being.
Thanks for looking at this.
Vince
rick
thanks, Vince
___
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
___
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
--- fs/nfsserver/nfs_nfsdsocket.c.sav 2012-07-08 20:32:37.0 -0400
+++ fs/nfsserver/nfs_nfsdsocket.c 2012-07-08 20:42:03.0 -0400
@@ -352,7 +352,7 @@ APPLESTATIC void
nfsrvd_dorpc(struct nfsrv_descript *nd, int isdgram,
NFSPROC_T *p)
{
- int error = 0, lktype;
+ int error = 0, gotref = 0, lktype;
vnode_t vp;
mount_t mp = NULL;
struct nfsrvfh fh;
@@ -378,6 +378,11 @@ nfsrvd_dorpc(struct nfsrv_descript *nd,
nd-nd_repstat = NFSERR_GARBAGE;
goto out;
}
+ gotref = 1;
+ NFSLOCKV4ROOTMUTEX();
+ nfsv4_getref(nfsv4rootfs_lock, NULL,
+ NFSV4ROOTLOCKMUTEXPTR, NULL);
+ NFSUNLOCKV4ROOTMUTEX();
if (nd-nd_procnum == NFSPROC_READ ||
nd-nd_procnum == NFSPROC_READDIR ||
nd-nd_procnum == NFSPROC_READLINK ||
@@ -471,6 +476,11 @@ nfsrvd_dorpc(struct nfsrv_descript *nd,
nd-nd_flag = ~ND_SAVEREPLY;
out:
+ if (gotref != 0) {
+ NFSLOCKV4ROOTMUTEX();
+ nfsv4_relref(nfsv4rootfs_lock);
+ NFSUNLOCKV4ROOTMUTEX();
+ }
NFSEXITCODE2(0, nd);
}
___
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
newbus' ivar's limitation..
Hi folks, Ok, yet another Newbus' limitation. Assuming a device exports more than one interface, and one of its child has need to use more than one interface, each interfaces cannot register, concurrently, its own ivar. While I try to always have a single child per interface/resource, I need to keep some compatibility with the old way of doing thing (POLA wrt. drivers I cannot/will not convert and userland). So, it would have been nice if ivar had been per-interface, not global and unique to one device. Unless I am mistaken, ivar are the only way for a parent can transmit information to a child. I can not simply implement a new METHOD to get that ivar as the device implements multiple time the same function (actually, up to 4 time for one, 3 for the other, with possible crossovers...), each one physically distinct. Each child is being tied to a pair. Thus, I need to pass each child discriminator(s) for each interfaces right after having been *created*, which cannot be done later on. Of course, it is out-of-question to have crossover in the interfaces definitions. The best way I could achieve this currently is to pass the child's device to its parent, and do a lookup based on that pointer to get information I need, but erk my 1c, - Arnaud ___ 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: panic after starting X with r238120
On 07/08/12 13:56, Alan Cox wrote: In r237513 on 6/23 I made a mistake that was corrected in r238124 on 7/5. I can vaguely see a connection between kern.ipc.shm_use_phys and the problem fixed in r238124. So, I'd like to know if this problem still exists. Wait, however, until you see Kostik commit a change to vm_pageout.c, before you update your system. I booted r238261 with kern.ipc.shm_use_phys=1 and the problem seems to have disappeared. Thanks! Steve ___ 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: Use of C99 extra long double math functions after r236148
On Sun, Jul 08, 2012 at 07:29:30PM -0500, Stephen Montgomery-Smith wrote: On 07/08/2012 06:58 PM, Steve Kargl wrote: On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote: So do people really work hard to get that last drop of ulp out of their calculations? I know very few scientist who work hard to reduce the ULP. Most have little understanding of floating point. Would a ulp=10 be considered unacceptable? Yes, it is unacceptable for the math library. Remember ULPs propagate and can quickly grow if the initial ulp for a result is large. OK. But suppose I wanted ld80 precision. What would be the advantage of using an ld80 expl function with a ulp of 1 over an ld128 expl function with a ulp of 10? The error propagation in the latter case could not be worse than the error propagation in the latter case. Well, on the most popular hardware (that being i386/amd64), ld80 will use hardware fp instruction while ld128 must be done completely in software. The speed difference is significant. In other words, if I were asked to write a super-fantastic expl function, where run time was not a problem, I would use mpfr, use Taylor's series with a floating point precision that had way more digits than I needed, and then just truncate away the last digits when returning the answer. And this would be guaranteed to give the correct answer to just above 0.5 ulp (which I assume is best possible). It's more like 1 ULP after truncation (, which isn't truncation but rounding). The problem is run-time that 'run-time is the problem'. Try writing a expl() and simply use mpfr_exp() with 64-bit precision. If you're doing any serious simulation where exp() will be evaluate millions or billions of time, you'll notice the difference. The only way I can see ULP errors greatly propagating is if one is performing iteration type calculations (like f(f(f(f(x). Have you read Goldberg's paper? Not to mention, I've seen way too many examples of 'x - y' where cancellation of significant digits causes problems. Throw in rather poor estimates of function results with real poor ULP and you have problems. -- Steve ___ 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: newbus' ivar's limitation..
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.
There's one pointer for the ivars. The bus code gets to determine what the
ivar looks like, because the interface is totally private to the bus. So long
as it returns the right thing for any key that's presented, it doesn't matter
quite how things are done.
So I'm not sure I understand what you are saying here.
The problem, more basically, is that the ivar keys are not unique. Currently,
there's no bits used in the key to define the values to be non-overlapping.
For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
We could easily reserve the upper 16-bits of this field to be that key. This
value could then be used to differentiate them. But this wouldn't scale too
well. Given that there's only about a dozen or two in the tree, that's right
at the moment, it wouldn't be hard to do something like:
enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16
and the above could be changed to:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
but then again, most of the existing interfaces in the kernel are mutually
exclusive, so you could implement this just for your new interfaces.
Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.
ivars are but one way to communicate this. However, they are the generic way
to convert a key to a value and store a key on a value. I don't really
understand what you are trying to say here, perhaps an example would help
illustrate what you are trying to do, since I don't quite understand the
problem here.
The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk
That doesn't make any sense. The child's parent already sets that child's ivar
when the child is created. The child's parent already gets a pointer to the
child when asked to do the key to value translation. Again, perhaps an example
would help here.
Warner___
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
Build error on CURRENT
I'm getting a compile error during buildworld here:
=== libexec/atrun (all)
cc -g -DATJOB_DIR=\/var/at/jobs/\
-DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1
-DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\/var/at/\
-I/usr/data/sb/head/libexec/atrun/../../usr.bin/at
-I/usr/data/sb/head/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized -Wno-pointer-sign -c
/usr/data/sb/head/libexec/atrun/atrun.c
${CTFCONVERT_CMD} expands to empty string
cc -g -DATJOB_DIR=\/var/at/jobs/\
-DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1
-DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\/var/at/\
-I/usr/data/sb/head/libexec/atrun/../../usr.bin/at
-I/usr/data/sb/head/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized -Wno-pointer-sign -c
/usr/data/sb/head/libexec/atrun/gloadavg.c
${CTFCONVERT_CMD} expands to empty string
cc -g -DATJOB_DIR=\/var/at/jobs/\
-DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1
-DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\/var/at/\
-I/usr/data/sb/head/libexec/atrun/../../usr.bin/at
-I/usr/data/sb/head/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o
-lpam -lutil
/usr/obj/usr/data/sb/head/tmp/usr/lib/libc.so: undefined reference to `log'
*** [atrun] Error code 1
Stop in /usr/data/sb/head/libexec/atrun.
*** [all] Error code 1
Stop in /usr/data/sb/head/libexec.
*** [libexec.all__D] Error code 1
Stop in /usr/data/sb/head.
*** [everything] Error code 1
Stop in /usr/data/sb/head.
*** [buildworld] Error code 1
At first I thought maybe it was because of an old install (CURRENT as
of December 2011) so I built and installed stable/9. That went off
just fine.
I thought it may be because my svn checkout of CURRENT got
interrupted, so I re-extracted from scratch and see the same thing.
I've also tried completely removing /usr/obj. I've build with no -j flag.
Looking at the sources I don't see the symbol log in libc anywhere
except as a DEBUG local variable that is only used in one file, always
under DEBUG. The only thing I see that's of interested is the
libexec.all__D target which I haven't yet grepped for to see what it
is.
My make.conf and src.conf are pretty sparse:
root@:/data/sb/head # cat /etc/make.conf
#LIBC_EXTRAMK=/usr/data/sb/ino64/tools/tools/shlib-compat/Makefile.sysfake
CFLAGS=-g
# added by use.perl 2011-09-17 07:04:17
PERL_VERSION=5.12.4
root@:/data/sb/head # cat /etc/src.conf
#WITHOUT_CLANG=yes
Clearly the tinderbox machines aren't hitting this, and I didn't see
anything in the mailing list either. So it's almost certainly
something on my end, but I'm at a loss as to what it could be.
Thanks,
matthew
___
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: Use of C99 extra long double math functions after r236148
On Jul 8, 2012, at 8:01 PM, Steve Kargl wrote: Not to mention, I've seen way too many examples of 'x - y' where cancellation of significant digits causes problems. Throw in rather poor estimates of function results with real poor ULP and you have problems. Are these problems significantly more or less than the usual #define I talked about before? If the functions are so so, but much better than the double version, we have a significant win, even if things aren't perfect. If we weren't 13 past the publication date of the c99 standard, I'd be more sympathetic to the 'we need a high quality implementation' arguments. However, we can't let the perfect be the enemy of the good here. We claim c99 conformance, yet don't have these functions. After all, many of the original functions that were in our library had sub-optimial performance which bruce optimized over many years. Why can't we use this model here? Warner ___ 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: Java and NIO?
On Jul 5, 2012, at 10:38 , George Neville-Neil wrote: On Jul 4, 2012, at 15:49 , Greg Lewis wrote: On Tue, Jul 03, 2012 at 11:38:23AM -0700, Waitman Gobble wrote: g...@freebsd.org wrote .. Howdy, Can someone tell me if anyone is working on this Java NIO bug? http://freebsd.1045724.n5.nabble.com/i386-159787-openjdk-1-6-nio-muti-thread-bug-td4700530.html I would like to avoid using Linux just to run Zookeeper: http://zookeeper-user.578899.n2.nabble.com/What-s-the-problem-with-nio-on-FreeBSD-td5208183.html Hi George, There is/was a patch from David Xu http://lists.freebsd.org/pipermail/freebsd-java/2010-August/008747.html maybe this fixes it? This patch was incorporated into the openjdk6 port soon after it was posted. However, I can still reproduce the problem. Using -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KqueueSelectorProvider makes no difference. also looks like New I/O was updated in jdk7... but would have to check it out to see if issue still exists.. I can't reproduce the problem with the current openjdk7 port. I haven't tried out Zookeeper though, so YMMV. I would say it's definitely worth a try though. I don't believe anyone is currently working on a fix for the openjdk6 port for this. I'm going to give zookeeper a try with openjdk7. Thanks! A followup. zookeeper is now ported to Freebsd (/usr/ports/devel/zookeeper) Best, George ___ 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: Java and NIO?
On 07/08/2012 19:33, George Neville-Neil wrote: A followup. zookeeper is now ported to Freebsd (/usr/ports/devel/zookeeper) George, did you see the PR and the followup from me regarding the port? -- This .signature sanitized for your protection ___ 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: Java and NIO?
On Jul 8, 2012, at 22:39 , Doug Barton wrote: On 07/08/2012 19:33, George Neville-Neil wrote: A followup. zookeeper is now ported to Freebsd (/usr/ports/devel/zookeeper) George, did you see the PR and the followup from me regarding the port? I got a mail from jgh@ but only today figured out what the PR was. I'll look at the patches from him tomorrow. Best, George ___ 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: Use of C99 extra long double math functions after r236148
On Sun, Jul 08, 2012 at 08:13:21PM -0600, Warner Losh wrote:
On Jul 8, 2012, at 8:01 PM, Steve Kargl wrote:
Not to mention, I've seen way too many examples of 'x - y'
where cancellation of significant digits causes
problems. Throw in rather poor estimates of function
results with real poor ULP and you have problems.
Are these problems significantly more or less than the
usual #define I talked about before? If the functions
are so so, but much better than the double version, we
have a significant win, even if things aren't perfect.
The answer is more complicated than the question asked.
On i386, the precision of long double and double is
53 bits. On amd64, the precision of long double and
double are 64 and 53 bits. On i386 and amd64, emax
and emin are 1024 and -1023 (could be off by one here)
for double and 16384 and -16383 for long double. Now,
consider 2**emin = exp(x) = 2**emax for some set of
x (where I'm using the Fortran exponential operator **
instead of powl(2,{emin|emax}) because FreeBSD does not
have a powl()). The sets for long double and double are
significantly different.
If we weren't 13 past the publication date of the c99 standard,
I'd be more sympathetic to the 'we need a high quality
implementation' arguments. However, we can't let the perfect
be the enemy of the good here. We claim c99 conformance, yet
don't have these functions.
AFAIK, neither gcc in base nor clang would be c99 complaint
even if all of the c99 math functions were available.
After all, many of the original functions that were in our
library had sub-optimial performance which bruce optimized
over many years. Why can't we use this model here?
I think the fear is that committing sub-optimal code would
take many many more years to fix. AFAICT, bde longer commits
code to src/ (since the switch from cvs to svn), and he depends
on his code reviews to get things fixed. With das and me
both having little to no time for FreeBSD, that leaves no one
to review/commit his suggested fixes (not that I would question
bde's opinion on a code change).
--
Steve
___
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: newbus' ivar's limitation..
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.
There's one pointer for the ivars. The bus code gets to determine what the
ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
So I'm not sure I understand what you are saying here.
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.
- Arnaud
The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be
non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
We could easily reserve the upper 16-bits of this field to be that key. This
value could then be used to differentiate them. But this wouldn't scale too
well. Given that there's only about a dozen or two in the tree, that's right
at the moment, it wouldn't be hard to do something like:
enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16
and the above could be changed to:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
but then again, most of the existing interfaces in the kernel are mutually
exclusive, so you could implement this just for your new interfaces.
Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.
ivars are but one way to communicate this. However, they are the generic way
to convert a key to a value and store a key on a value. I don't really
understand what you are trying to say here, perhaps an example would help
illustrate what you are trying to do, since I don't quite understand the
problem here.
The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk
That doesn't make any sense. The child's parent already sets that child's
ivar when the child is created. The child's parent already gets a pointer to
the child when asked to do the key to value translation. Again, perhaps an
example would help here.
Warner
___
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: newbus' ivar's limitation..
On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.
There's one pointer for the ivars. The bus code gets to determine what the
ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
So I'm not sure I understand what you are saying here.
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.
Only if the IVARs for interface A and interface B have overlapping values. If
the Ivar keys don't overlap, then there's no problems at all. Certainly less
hackish than not using them at all. Since dev0 knows the layout of the ivar
that it set on its child, this presents no problems at all. It would return
the values from A from the right part of the ivar, and those from B in the
right part. Apart from the coordination of Ivar numbers, as I outlined in my
last post, there's no issue here.
Warner
- Arnaud
The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be
non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't
scale too well. Given that there's only about a dozen or two in the tree,
that's right at the moment, it wouldn't be hard to do something like:
enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16
and the above could be changed to:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
but then again, most of the existing interfaces in the kernel are mutually
exclusive, so you could implement this just for your new interfaces.
Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.
ivars are but one way to communicate this. However, they are the generic
way to convert a key to a value and store a key on a value. I don't really
understand what you are trying to say here, perhaps an example would help
illustrate what you are trying to do, since I don't quite understand the
problem here.
The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk
That doesn't make any sense. The child's parent already sets that child's
ivar when the child is created. The child's parent already gets a pointer
to the child when asked to do the key to value translation. Again, perhaps
an example would help here.
Warner
___
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: Use of C99 extra long double math functions after r236148
On 07/08/2012 09:01 PM, Steve Kargl wrote: Have you read Goldberg's paper? I must admit that I had not. I found it at: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html Not to mention, I've seen way too many examples of 'x - y' where cancellation of significant digits causes problems. Throw in rather poor estimates of function results with real poor ULP and you have problems. I think that if a program includes x-y where cancellation causes huge loss of digits, then the program should be considered highly flawed. The programmer might get lucky, and a few extra ULP might save his skin, but it would be better if the program catastrophically failed so that he would realize they need to do something smarter. I got my first scientific calculator around 1975, and I remember my surprise when I discovered that (1/3)*3-1 on my calculator did not produce zero. Years later I bought another calculator, and imagine my further surprise when (1/3)*3-1 did produce zero. They must have done something very smart, I thought. The problem is, these kinds of tricks can only help you so much. Calculations like arccos(arccos(arccos(arccos(cos(cos(cos(cos(x)-x are probably not going to be correct no matter how smart the programmer is. The paper by Goldberg has some really nice stuff. I teach a class on numerical methods. One example I present is the problem using equation (4) of Goldberg's paper to solve quadratic equations. I tell them that the smart thing to do is to use equation (4) or equation (5) depending on whether b has the same sign as sqrt(b^2-4ac). This is a very good illustration of how to overcome the x-y problem, and in my opinion it has to be understood by the programmer, not the writer of the square-root package. Trying to compensate by getting that lost drop of ULP out of square root is looking in the wrong direction. But there is other stuff in his paper I don't like, and it comes across as nit-picking rather than really thinking through why he wants the extra accuracy. I feel like he is saving the pennies, but losing the dollars. For example, computing the quadratic formula when b^2 and 4ac are roughly equal (discussed in his proof of Theorem 4). He says that roughly half the digits of the final answer will be contaminated. He recommends performing the calculation with double the precision, and then retaining what is left. The reason I don't like his solution is this. The contamination of half the digits is real, not some artifact of the computing method. Unless you know EXACTLY what a, b and c are, only half the digits of the quadratic formula are valid, no matter how you calculate it. For example, maybe a is calculated by some other part of the program as 1/3. Since 1/3 cannot be represented exactly in base 2, it will not be exactly 1/3. That part of the program doesn't know that this number is going to be used later on in the quadratic formula, so it computes it in single precision. Now the quadratic formula algorithm converts a to double precision. But a will still be 1/3 to single precision. The only way to avoid this error is to perform EVERY pertinent calculation prior to the use of quadratic formula in double precision. (And suppose instead the data comes from a scientific experiment - the programmer needs to be performing an error analysis, not hoping his implementation of quadratic formula is performed in double precision.) Similarly, I am not a fan of the Kahan Summation Formula (Theorem 8). There are two reasons why I might compute large sums. One is accounting, when I better be using high enough precision that the arithmetic is exact. The other is something like numerical integration. But in the latter case, unless the summands have a very special form, it is likely that each summand will only be accurate to within e. Thus the true sum is only known to within n*e, and so the naive method really hasn't lost any precision at all. And typically n*e will be so small compared to the true answer that it won't matter. If it does matter, the problem is that n is too big. The algorithm will take decades to run. Focus efforts on producing a different numerical integration method, instead of getting that lost drop of ULP. I cannot envision any non-contrived circumstance where the Kahan summation formula is going to give an answer that is significantly more reliable than naive summation. I can envision a circumstance when the reduction in speed of the Kahan summation formula over naive summation could be significant. I think the example I like best that illustrates floating point errors is inverting badly conditioned matrices. And any scientist who works with large matrices had better know what ill-conditioned means. The proper answer is that if your matrix is ill-conditioned, give up. You need to look at the problem where your matrix came from, and rethink how you concert
Re: newbus' ivar's limitation..
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.
There's one pointer for the ivars. The bus code gets to determine what the
ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
So I'm not sure I understand what you are saying here.
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.
Only if the IVARs for interface A and interface B have overlapping values.
If the Ivar keys don't overlap, then there's no problems at all. Certainly
less hackish than not using them at all. Since dev0 knows the layout of the
ivar that it set on its child, this presents no problems at all. It would
return the values from A from the right part of the ivar, and those from B in
the right part. Apart from the coordination of Ivar numbers, as I outlined
in my last post, there's no issue here.
I think we should not be talking about the same API here. I have no
idea what you mean by the key to value translation, nor Ivar
numbers. What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.
- Arnaud
Warner
- Arnaud
The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be
non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't
scale too well. Given that there's only about a dozen or two in the tree,
that's right at the moment, it wouldn't be hard to do something like:
enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16
and the above could be changed to:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
but then again, most of the existing interfaces in the kernel are mutually
exclusive, so you could implement this just for your new interfaces.
Unless I am mistaken, ivar are the only way for a parent can transmit
information to a child. I can not simply implement a new METHOD to get
that ivar as the device implements multiple time the same function
(actually, up to 4 time for one, 3 for the other, with possible
crossovers...), each one physically distinct. Each child is being tied
to a pair. Thus, I need to pass each child discriminator(s) for each
interfaces right after having been *created*, which cannot be done
later on. Of course, it is out-of-question to have crossover in the
interfaces definitions.
ivars are but one way to communicate this. However, they are the generic
way to convert a key to a value and store a key on a value. I don't really
understand what you are trying to say here, perhaps an example would help
illustrate what you are trying to do, since I don't quite understand the
problem here.
The best way I could achieve this currently is to pass the child's
device to its parent, and do a lookup based on that pointer to get
information I need, but erk
That doesn't make any sense. The child's parent already sets that child's
ivar when the child is created. The child's parent already gets a pointer
to the child when asked to do the key to value translation. Again, perhaps
an example would help here.
Warner
___
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: newbus' ivar's limitation..
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.
There's one pointer for the ivars. The bus code gets to determine what the
ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
So I'm not sure I understand what you are saying here.
The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be
non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
We could easily reserve the upper 16-bits of this field to be that key. This
value could then be used to differentiate them. But this wouldn't scale too
well. Given that there's only about a dozen or two in the tree, that's right
at the moment, it wouldn't be hard to do something like:
enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16
and the above could be changed to:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
but then again, most of the existing interfaces in the kernel are mutually
exclusive, so you could implement this just for your new interfaces.
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...
- Arnaud
___
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: Java and NIO?
On 07/08/2012 20:01, George Neville-Neil wrote: On Jul 8, 2012, at 22:39 , Doug Barton wrote: On 07/08/2012 19:33, George Neville-Neil wrote: A followup. zookeeper is now ported to Freebsd (/usr/ports/devel/zookeeper) George, did you see the PR and the followup from me regarding the port? I got a mail from jgh@ but only today figured out what the PR was. Are you not getting your g...@freebsd.org mail? I'll look at the patches from him tomorrow. I copied the text from my message below for your convenience. http://www.freebsd.org/cgi/query-pr.cgi?pr=169693 Furthermore the rc.d script is a mess, and should not have been committed like it was (numerous missing bits, bad format, set_rcvar, hard-coded /usr/local, no REQUIRE, no KEYWORD: shutdown, etc.). Please read http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html and then ask in freebsd-rc@ if you have any additional questions. Sorry to be so blunt, but I'm really, really tired of repeating the same stuff over and over again, and this script is really a mess. Also, don't install the script in do-install, see the web page above (and/or the PR) for USE_RC_SUBR. And FYI, there is no need to have the function in that script. You could use (for example) start_cmd=$command start just as well. Not to mention that the function you have should be using $1 as the argument to $command, not $rc_arg. Reasons why left as an exercise for the reader ... Doug -- This .signature sanitized for your protection ___ 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: newbus' ivar's limitation..
On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.
There's one pointer for the ivars. The bus code gets to determine what
the ivar looks like, because the interface is totally private to the bus.
So long as it returns the right thing for any key that's presented, it
doesn't matter quite how things are done.
So I'm not sure I understand what you are saying here.
dev0 implements two interfaces: A and B. dev1, child of dev0, needs to
use both interfaces. There is no generic way for dev0 to export
independent ivars for both interface. For now, I restricted the
function of the second interface not to need ivar, but that's kind of
hackish.
Only if the IVARs for interface A and interface B have overlapping values.
If the Ivar keys don't overlap, then there's no problems at all. Certainly
less hackish than not using them at all. Since dev0 knows the layout of the
ivar that it set on its child, this presents no problems at all. It would
return the values from A from the right part of the ivar, and those from B
in the right part. Apart from the coordination of Ivar numbers, as I
outlined in my last post, there's no issue here.
I think we should not be talking about the same API here. I have no
idea what you mean by the key to value translation, nor Ivar
numbers. What I refer to is that device_set_ivars() /
device_get_ivars() acts on a single instance variables from `struct
device': `ivars'. In that case, I do not really see how to set that
specific field to two distinct values for each interfaces.
We are talking about the ivar interface. You are just misunderstanding how it
is used.
Let us say that dev0 wants to implement interface A and B. The interface it
implements is the device_read _ivar method. That method looks like:
int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_ivar *iv = device_get_ivar(child);
switch (which) {
case PCI_IVAR_SUBVENDOR:
*result = iv-subvendor;
break;
...
default:
return EINVAL;
}
return 0;
}
So, if you wanted to implement interface A and interface B, you would have to
support reading and writing A_IVAR_* and B_IVAR_*. The above routine would
look like:
struct mydev_ivar {
int a_1;
int a_2;
int b_1;
int b_2;
};
int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);
switch (which) {
case A_IVAR_1:
*result = iv-a_1;
break;
case A_IVAR_2:
*result = iv-a_2;
break;
case B_IVAR_1:
*result = iv-b_1;
break;
case B_IVAR_2:
*result = iv-b_2;
break;
default:
return EINVAL;
}
return 0;
}
and similar for the write routine. Now, there are some busses that provide
convenience structures and functions for dealing with the ivars. In that case,
you'd be able to use the wrapper structures and routines like so:
struct mdev_ivar {
struct a_ivar a;
struct b_ivar b;
};
int mydev_read_ivar(device_t dev, device child, int which, uintpr_t *result)
{
struct mydev_ivar *iv = device_get_ivar(child);
switch (which) {
case A_IVAR_1:
case A_IVAR_2:
return a_helper_read_ivar(iv-a, which, result);
case B_IVAR_1:
case B_IVAR_2:
return b_helper_read_ivar(iv-b, which, result);
default:
return EINVAL;
}
return 0;
}
Both of these work only if the A_IVAR values are disjoint from the B_IVAR
values. Your mydev device is the one that sets the ivar on dev1, in your
example, so it would know how to malloc and create the mydev_ivar structure,
even if the interfaces it is implementing provide helper functions, like I've
outlined above.
Warner
- Arnaud
Warner
- Arnaud
The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be
Re: newbus' ivar's limitation..
On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to keep some compatibility with the old way
of doing thing (POLA wrt. drivers I cannot/will not convert and
userland). So, it would have been nice if ivar had been per-interface,
not global and unique to one device.
There's one pointer for the ivars. The bus code gets to determine what the
ivar looks like, because the interface is totally private to the bus. So
long as it returns the right thing for any key that's presented, it doesn't
matter quite how things are done.
So I'm not sure I understand what you are saying here.
The problem, more basically, is that the ivar keys are not unique.
Currently, there's no bits used in the key to define the values to be
non-overlapping. For example:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
We could easily reserve the upper 16-bits of this field to be that key.
This value could then be used to differentiate them. But this wouldn't
scale too well. Given that there's only about a dozen or two in the tree,
that's right at the moment, it wouldn't be hard to do something like:
enum ivar_namespace {
IVAR_PCI = 1,
IVAR_PCCARD,
IVAR_USB,
etc
};
#define IVAR_SHIFT 16
and the above could be changed to:
enum pci_device_ivars {
PCI_IVAR_SUBVENDOR = IVAR_PCI IVAR_SHIFT,
PCI_IVAR_SUBDEVICE,
PCI_IVAR_VENDOR,
};
and then we'd have an unambiguous key, and the bus could easily implement
multiple interfaces.
but then again, most of the existing interfaces in the kernel are mutually
exclusive, so you could implement this just for your new interfaces.
ok, I think I got it now. You and I are exactly saying the same thing,
just in different terms; there is no way to currently specify multiple
independent (/overlapping) ivars in a child...
There's no way to support overlapping IVAR keys, yes. However, if you are
designing the ivars for multiple inheritance, then you'll need to make them
non-overlapping. Thankfully, this is trivial to do.
Warner
Warner___
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: Use of C99 extra long double math functions after r236148
On Sun, Jul 08, 2012 at 10:41:44PM -0500, Stephen Montgomery-Smith wrote: On 07/08/2012 09:01 PM, Steve Kargl wrote: Have you read Goldberg's paper? I must admit that I had not. I found it at: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html Yes, it's easy to find. Unfortunately, many people don't know that it exists. I've read that paper between 10 and 20 times and I still learn something new with every reading. Not to mention, I've seen way too many examples of 'x - y' where cancellation of significant digits causes problems. Throw in rather poor estimates of function results with real poor ULP and you have problems. I think that if a program includes x-y where cancellation causes huge loss of digits, then the program should be considered highly flawed. The programmer might get lucky, and a few extra ULP might save his skin, but it would be better if the program catastrophically failed so that he would realize they need to do something smarter. I got my first scientific calculator around 1975, and I remember my surprise when I discovered that (1/3)*3-1 on my calculator did not produce zero. Years later I bought another calculator, and imagine my further surprise when (1/3)*3-1 did produce zero. They must have done something very smart, I thought. Yes. They used CORDIC arithmetic instead of (binary) floating point. The problem is, these kinds of tricks can only help you so much. Calculations like arccos(arccos(arccos(arccos(cos(cos(cos(cos(x)-x are probably not going to be correct no matter how smart the programmer is. Well, I would claim that any programmer who wrote such an expression is not smart. The paper by Goldberg has some really nice stuff. I teach a class on numerical methods. It may be profitable to at least have your students read the paper. I don't know about others, but I find doing floating point arithematic correctly very difficult. One example I present is the problem using equation (4) of Goldberg's paper to solve quadratic equations. I tell them that the smart thing to do is to use equation (4) or equation (5) depending on whether b has the same sign as sqrt(b^2-4ac). This is a very good illustration of how to overcome the x-y problem, and in my opinion it has to be understood by the programmer, not the writer of the square-root package. Trying to compensate by getting that lost drop of ULP out of square root is looking in the wrong direction. Careful. IEEE 754 specifies and one can prove that sqrt() can be computed correctly to less than or equal to 1/2 ULP for all input in all rounding modes. Computing the roots of the quartic equation, which uses the sqrt() function, is a different matter. But there is other stuff in his paper I don't like, and it comes across as nit-picking rather than really thinking through why he wants the extra accuracy. I feel like he is saving the pennies, but losing the dollars. well, in Goldberg's defense, think about the title of the paper. I think his major aim in the paper is get scientist to think about what and how they compute some number. Similarly, I am not a fan of the Kahan Summation Formula (Theorem 8). Oh my. I'm a fan of Kahan's summation formula. But, I assume that one applies it to situations where it is needed. There are two reasons why I might compute large sums. One is accounting, when I better be using high enough precision that the arithmetic is exact. If you're doing accouting, hopefully, you're using BCD. Accouting and floating point simply do not mix. The other is something like numerical integration. But in the latter case, unless the summands have a very special form, it is likely that each summand will only be accurate to within e. Thus the true sum is only known to within n*e, and so the naive method really hasn't lost any precision at all. And typically n*e will be so small compared to the true answer that it won't matter. If it does matter, the problem is that n is too big. The algorithm will take decades to run. Focus efforts on producing a different numerical integration method, instead of getting that lost drop of ULP. I cannot envision any non-contrived circumstance where the Kahan summation formula is going to give an answer that is significantly more reliable than naive summation. I can envision a circumstance when the reduction in speed of the Kahan summation formula over naive summation could be significant. I can envision a use. Try computing the RMS height of a numerically generated random rough surface in the scattering of an incident acoustic field from said surface. The RMS height is a main component in the first order perturbation theory expansion of the scattered field. You get the RMS height wrong, you have no idea what the scatter field strength is. I think the example I like best that illustrates floating point errors is inverting badly
Re: newbus' ivar's limitation..
Hi, On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh i...@bsdimp.com wrote: On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh i...@bsdimp.com wrote: On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: Hi, On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote: On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: Ok, yet another Newbus' limitation. Assuming a device exports more than one interface, and one of its child has need to use more than one interface, each interfaces cannot register, concurrently, its own ivar. While I try to always have a single child per interface/resource, I need to keep some compatibility with the old way of doing thing (POLA wrt. drivers I cannot/will not convert and userland). So, it would have been nice if ivar had been per-interface, not global and unique to one device. There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done. So I'm not sure I understand what you are saying here. dev0 implements two interfaces: A and B. dev1, child of dev0, needs to use both interfaces. There is no generic way for dev0 to export independent ivars for both interface. For now, I restricted the function of the second interface not to need ivar, but that's kind of hackish. Only if the IVARs for interface A and interface B have overlapping values. If the Ivar keys don't overlap, then there's no problems at all. Certainly less hackish than not using them at all. Since dev0 knows the layout of the ivar that it set on its child, this presents no problems at all. It would return the values from A from the right part of the ivar, and those from B in the right part. Apart from the coordination of Ivar numbers, as I outlined in my last post, there's no issue here. I think we should not be talking about the same API here. I have no idea what you mean by the key to value translation, nor Ivar numbers. What I refer to is that device_set_ivars() / device_get_ivars() acts on a single instance variables from `struct device': `ivars'. In that case, I do not really see how to set that specific field to two distinct values for each interfaces. We are talking about the ivar interface. You are just misunderstanding how it is used. yes I indeed did... silly, silly me :-) - Arnaud ___ 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
