(i)frame based sites cause horrible performence in firefox 14.0.1
Sites that are based on frames or iframes (such as google mail and most of google's non-search services) kill the performance of www/firefox [firefox-14.0.1_1,1] (last updated yesterday on a 9.1 built at the same time) here is the uname: FreeBSD XXX 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2: Thu Aug 9 15:54:37 EDT 2012 root@XXX:/usr/obj/usr/src/sys/GENERIC i386 ___ 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: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
On 08/14/2012 12:20 PM, Adrian Chadd wrote: > Hi, > > Would you be willing to compile a kernel with KTR so you can capture > some KTR scheduler dumps? > > That way the scheduler peeps can feed this into schedgraph.py (and you > can too!) to figure out what's going on. > > Maybe things aren't being scheduled correctly and the added latency is > killing performance? You might also try switching to SCHED_ULE to see if it helps. Although, in the last few months as mav has been converging the 2 I've started to see the same problems I saw on my desktop systems previously re-appear even using ULE. For example, if I'm watching an AVI with VLC and start doing anything that generates a lot of interrupts (like moving large quantities of data from one disk to another) the video and sound start to skip. Also, various other desktop features (like menus, window switching, etc.) start to take measurable time to happen, sometimes seconds. ... and lest you think this is just a desktop problem, I've seen the same scenario on 8.x systems used as web servers. With ULE they were frequently getting into peak load situations that created what I called "mini thundering herd" problems where they could never quite get caught up. Whereas switching to 4BSD the same servers got into high-load situations less often, and they recovered on their own in minutes. Doug ___ 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: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
Hi, Would you be willing to compile a kernel with KTR so you can capture some KTR scheduler dumps? That way the scheduler peeps can feed this into schedgraph.py (and you can too!) to figure out what's going on. Maybe things aren't being scheduled correctly and the added latency is killing performance? Adrian ___ 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: Strange behavior of r239228 on i386 -- looks like livelocks
Hello, Lev. You wrote 15 августа 2012 г., 0:51:03: LS> It looks like I've got live lock on my router. It acts as router, LS> but physical console (serial one) and ssh connection are stalled and LS> don't react on keypresses. After two or three minutes everything LS> unfreeze, then freeze again... named (BIND) could not resolve names (for other network clients) in these moments. -- // Black Lion AKA Lev Serebryakov ___ 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"
Strange behavior of r239228 on i386 -- looks like livelocks
Hello, Current. It looks like I've got live lock on my router. It acts as router, but physical console (serial one) and ssh connection are stalled and don't react on keypresses. After two or three minutes everything unfreeze, then freeze again... After unfreeze here are messages from "nut" that connection with UPS is lost (UPS is connected to other host in network) and re-established. I don't understand how to debug such situation :) uname -a is: FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r239228: Mon Aug 13 13:07:52 MSK 2012 r...@vmware-c-32.home.serebryakov.spb.ru:/usr/obj/nanobsd.gateway-net5501/data/src/sys/NET5501 i386 Scheduler is ULE. -- // Black Lion AKA Lev Serebryakov ___ 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"
CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
Hello, Current. I'm using Soekris net5501 (AMD Geode 500Mhz, 512MiB of RAM) as all-in-one home router: it connects my network to ISP via PPPoE (40Mbit shaped channel, ng0, over 100Mbit ethernet, interface vr1) and acts as AP for my WiFi (Atheros card). It connected to my wired home network with gigabit Intel card (em0, old PCI one). One of servers in my network acts as storage and torrent box in same time. It is connected to wire network (gigabit one). And I found strange thing: when torrents are active (40Mbit up and down, from em0 to ng0 over vr1 with firewall and NAT) router could pass only about 0.1MiB/s of trafic from internal (gigabit) network into WiFi. Yes, 0.1MiB/s. When torrents are not active it could provide from 1.5 to 2.2MiB/s, depending on time of day (and state of environment), so in this case radio channel is limiting factor. Answer looks trivial: router CPU is bottleneck. But here is one additional detail: `top' never shows less than 50% of idle when torrents are active. And `idle' time with torrents traffic is ALWAYS is higher than without them, but with WiFi traffic. Here is typical top-5 when torrents AND WiFi is active (WiFi speed is terrible): PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND 10 root 155 ki31 0K 8K RUN 3:29 75.20% idle 11 root -72- 0K80K WAIT 2:33 12.50% intr{swi1: netisr 0} 11 root -92- 0K80K WAIT 0:39 6.40% intr{irq15: ath0 ata1} 14 root -16- 0K 8K -0:12 5.76% yarrow 0 root -920 0K72K -0:10 1.17% kernel{ath0 taskq} Here is typical top-5 when ONLY WiFi is active (please, note: idle is less than in previous case!): PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND 10 root 155 ki31 0K 8K RUN 3:12 38.57% idle 11 root -92- 0K80K WAIT 0:31 34.67% intr{irq15: ath0 ata1} 11 root -72- 0K80K WAIT 2:12 13.67% intr{swi1: netisr 0} 0 root -920 0K72K -0:08 7.47% kernel{ath0 taskq} 14 root -16- 0K 8K -0:10 4.69% yarrow Here is typical top-5 only with torrents: PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND 10 root 155 ki31 0K 8K RUN 3:47 82.67% idle 11 root -72- 0K80K WAIT 3:00 10.60% intr{swi1: netisr 0} 14 root -16- 0K 8K -0:13 5.18% yarrow 11 root -92- 0K80K WAIT 0:40 0.78% intr{irq15: ath0 ata1} 1870 root 200 10684K 2268K RUN 0:02 0.59% top And here is typical top-5 with no traffic PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND 10 root 155 ki31 0K 8K RUN 4:36 98.58% idle 11 root -72- 0K80K WAIT 3:22 5.08% intr{swi1: netisr 0} 14 root -16- 0K 8K -0:14 0.78% yarrow 11 root -92- 0K80K WAIT 0:41 0.68% intr{irq15: ath0 ata1} 1870 root 200 10684K 2268K RUN 0:02 0.29% top I'm wonder, why adding torrent traffic slows down WiFi transfer BUT gives much more idle time than WiFi transfer alone? I'm using CURRENT r239228 with SCHED_ULE. -- // Black Lion AKA Lev Serebryakov ___ 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: zfsloader failure with r239244
On 14.08.2012 21:03, Steve Wills wrote: > Any ideas if this is a bug or something wrong with my system would be > appreciated. Can you boot with serial console and show what show the `lsdev` command in the loader? And from the running system the output of `gpart show` and `zpool status`. -- WBR, Andrey V. Elsukov ___ 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"
zfsloader failure with r239244
Hi, I just upgraded my system from r238261 to r239244 and was unable to boot one of my zfs root systems. I had to recover using the zfsloader.old that is kept in /boot. The messages from zfsloader were: ZFS: can't find pool by guid ZFS: can't find pool by guid can't load 'kernel' followed by a loader prompt. My loader.conf has: vfs.root.mountfrom="zfs:zroot" as well as other settings. I suspect this may be related to the fact that my zfs root is "formatted using a legacy on-disk format." Specifically, it is version 14 and for the record it's on an MBR partition. This system also has two other pools, one which is version 28 and another which is the latest zpool version (I think? No version number is shown in "zpool list -o all", only a "-"). I've avoided zpool upgrading this pool because I'm a little nervous about updating zfsboot via dd. I didn't see the issue on another zfs root system which is using GPT and the latest zpool version and was upgraded from/to the same versions. Any ideas if this is a bug or something wrong with my system would be appreciated. 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: Speaking of ship blockers for 9....
Gleb Smirnoff wrote: > I> Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if= > I> tun0, stored af=2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=17, > I> found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. > > Let me give you link to my branch of pf: > > http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html > http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html > > In that branch the code that puts the "reverse" pointer on state keys, > as well as the m_addr_changed() function and the pf_compare_state_keys() > had been cut away. > > So, this exact bug definitely can't be reproduced there. However, others > may hide in :) > > Let me encourage you to try and test my branch (instructions in URLs > above). I do see much better performance, however, I'm seeing this panic after about 23 minutes (the slightly higher uptime was a result of a manual fsck). This system is not particularly loaded. It's a UP Pentium-m which is our office gateway. I can give you access to inspect if you like. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc046f8f4 stack pointer = 0x28:0xeb7b7bd8 frame pointer = 0x28:0xeb7b7bec code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 4 (pf purge) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c0819c2b,eb7b7a78,c05d5829,c0816ff2,c08acca0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0816ff2,c08acca0,c07f2736,eb7b7a84,eb7b7a84,...) at kdb_backtrace+0x29 panic(c07f2736,c0845a85,c559fd68,1,1,...) at panic+0xc9 trap_fatal(0,c60c826c,c610b31c,c610ac44,8,...) at trap_fatal+0x353 trap_pfault(eb7b7b18,c05c0a2d,c0ecc500,c0ecc608,c54ec000,...) at trap_pfault+0xd9 trap(eb7b7b98) at trap+0x418 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc046f8f4, esp = 0xeb7b7bd8, ebp = 0xeb7b7bec --- pf_state_key_detach(eb7b7c18,c046af2a,502a6f69,0,8000,...) at pf_state_key_detach+0x74 pf_detach_state(c64d5d00,0,8000,0,c559fbc0,...) at pf_detach_state+0x1c6 pf_unlink_state(c64d5d00,1,0,0,c0870398,...) at pf_unlink_state+0x1c5 pf_purge_expired_states(c08947c0,0,0,c07eadbf,64,...) at pf_purge_expired_states+0xe6 pf_purge_thread(0,eb7b7d08,0,c54ec000,0,...) at pf_purge_thread+0x14f fork_exit(c0471b60,0,eb7b7d08) at fork_exit+0xa2 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xeb7b7d40, ebp = 0 --- Uptime: 57m29s Physical memory: 2038 MB Dumping 189 MB: 174 158 142 126 110 94 78 62 46 30 14 (kgdb) bt #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05d563a in kern_reboot (howto=260) at /usr/src.pflock/sys/kern/kern_shutdown.c:449 #2 0xc05d5888 in panic (fmt=Variable "fmt" is not available.) at /usr/src.pflock/sys/kern/kern_shutdown.c:637 #3 0xc07b8b23 in trap_fatal (frame=0xeb7b7b98, eva=0) at /usr/src.pflock/sys/i386/i386/trap.c:1028 #4 0xc07b8c09 in trap_pfault (frame=0xeb7b7b98, usermode=0, eva=0) at /usr/src.pflock/sys/i386/i386/trap.c:881 #5 0xc07b9a58 in trap (frame=dwarf2_read_address: Corrupted DWARF expression.) at /usr/src.pflock/sys/i386/i386/trap.c:552 #6 0xc07a579c in calltrap () at /usr/src.pflock/sys/i386/i386/exception.s:169 #7 0xc046f8f4 in pf_state_key_detach (s=0xc64d5d00, idx=1) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1040 #8 0xc04713f6 in pf_detach_state (s=0xc64d5d00) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1006 #9 0xc0471975 in pf_unlink_state (s=0xc64d5d00, flags=Variable "flags" is not available.) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1520 #10 0xc0471a96 in pf_purge_expired_states (maxcheck=148) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1573 #11 0xc0471caf in pf_purge_thread (v=0x0) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1371 #12 0xc05a5af2 in fork_exit (callout=0xc0471b60 , arg=0x0, frame=0xeb7b7d08) at /usr/src.pflock/sys/kern/kern_fork.c:995 #13 0xc07a5814 in fork_trampoline () at /usr/src.pflock/sys/i386/i386/exception.s:276 Ian -- Ian Freislich ___ 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: geom mirror now rebuilding on every reboot?
On Mon, 2012-08-06 at 08:34 -0700, Maksim Yevmenkin wrote: > Michael, > > > Something in -current and recently MFC'd to -stable is causing all of my > > gmirror drives to rebuild on reboot :-( > > > > Being remote and these being production machines, I suspect SVN r237929 > > and r237930 in -current and SVN r238500 to -stable but haven't yet been > > able to prove it. > > > > Is anyone else seeing this? > > yes, i've seem something similar only much, much worse. one of our > production systems completely kept loosing its gmirror volumes on > every reboot. it looked like gmirror metadata were completely > corrupted. rebuilding mirrors and reverting back to previous kernel > seemed to work. someone else is tracking it down. Have they managed to track this down to a commit or range of commits yet? Thanks, Gavin ___ 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"
panic: page fault
http://privatepaste.com/147286442b ___ 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: Time to bump default VM_SWZONE_SIZE_MAX?
On 08/13/12 14:23, Peter Jeremy wrote: > On 2012-Aug-12 15:44:07 -0700, Colin Percival > wrote: >> If I'm understanding things correctly, the "maxswzone" value -- set by >> the kern.maxswzone loader tunable or to VM_SWZONE_SIZE_MAX by default -- >> should be approximately 9 MiB per GiB of swap space. > > I'm not sure how you got that value. By default, struct swblock is 288 > bytes (280 bytes on 32-bit archs) and can store up to 32 pages of swap (the > comment in vm/swap_pager.c:swap_pager_swap_init() is wrong). For x86, this > is 2.25 MiB per GiB (best case). I got that value from a previous mailing list discussion -- I think it was based on the (incorrect) value of 16 pages per swblock and not exceeding 50% swblock utilization. > Realistically, I'd say that the default VM_SWZONE_SIZE_MAX can handle about > 9GB swap (at least, that was my experience). The 50% utilization rule of thumb would make it 7 GB, but yes, same order of magnitude. > BTW, if you plan on allocating lots of swap, be aware that each swap device > is limited to 32GiB - see vm/swap_pager.c:swaponsomething(). Yes, noted. I'm not actually using lots of swap myself, but I was writing code for EC2 instances to set up "reasonable" amounts of swap at boot time, and I don't want to accidentally autoconfigure more swap than FreeBSD can safely use. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ 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: Soekris net4801 sees no disk devices with -CURRENT
On Mon, Aug 13, 2012 at 11:30:06PM +0200, Pierre DAVID wrote: > On Sun, Aug 12, 2012 at 05:49:24PM +0200, Paul Schenkeveld wrote: > > Hi, > > > > I am trying to build a NanoBSD image for Soekris net4801 with a recent > > -CURRENT. The kernel boots fine but when it comes to mounting the root > > filesystem, it cannot find the flash disk anymore. Bios is up to date > > (1.33). > > > > Hello, > > I'm trying to resurrect my old net4801 and update it with -CURRENT > (old version was a 8-CURRENT), and I do not succeed to get kernel > output via the RS-232 port. Kernel goes mute just after being loaded. > Could you send me your NanoBSD kernel configuration file? > > Pierre Below is my kernel config. You also have to use boot0sio and create a file called /boot.config containing "-h" so the boot loader knows that you want to use a serial console. Usually NanoBSD does that for you if you include "customize_cmd cust_comconsole" in your NanoBSD config file and leave NANO_BOOTLOADER set to its default of "boot/boot0sio". # from GENERIC cpu I586_CPU ident NET4801 options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options INCLUDE_CONFIG_FILE # Include this file in kernel device apic# I/O APIC device cpufreq device acpi device pci device ahci# AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA device siis# SiliconImage SiI3124/SiI3132/SiI3531 SATA device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass# Passthrough device (direct ATA/SCSI access) device ctl # CAM Target Layer device pmtimer device uart# Generic UART driver device miibus # MII bus support device sis # Silicon Integrated Systems SiS 900/SiS 7016 device loop# Network loopback device random # Entropy device device ether # Ethernet support device vlan# 802.1Q VLAN support device tun # Packet tunnel. device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device bpf # Berkeley packet filter options USB_DEBUG # enable debug msgs device uhci# UHCI PCI->USB interface device ohci# OHCI PCI->USB interface device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da # local additions makeoptions MODULES_OVERRIDE="" options CPU_GEODE options CPU_SOEKRIS device atadisk # ATA disk drives I have tried with and without the "device atadisk" line but my compact flash is never seen by the kernel. Kind regards, Paul Schenkeveld ___ 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: Time to bump default VM_SWZONE_SIZE_MAX?
Slightly better patch (improved documentation) DES -- Dag-Erling Smørgrav - d...@des.no Index: sys/boot/common/loader.8 === --- sys/boot/common/loader.8 (revision 239239) +++ sys/boot/common/loader.8 (working copy) @@ -613,17 +613,26 @@ for details. .It Va kern.maxswzone Limits the amount of KVM to be used to hold swap -meta information, which directly governs the -maximum amount of swap the system can support. -This value is specified in bytes of KVA space -and defaults to 32MBytes on i386 and amd64. -Care should be taken -to not reduce this value such that the actual -amount of configured swap exceeds 1/2 the -kernel-supported swap. -The default of 32MB allows -the kernel to support a maximum of ~7GB of swap. -Only change +metadata, which directly governs the +maximum amount of swap the system can support, +at the rate of approximately 200 MB of swap space +per 1 MB of metadata. +This value is specified in bytes of KVA space. +If no value is provided, the system allocates +enough memory to handle an amount of swap +that corresponds to eight times the amount of +physical memory present in the system. +.Pp +Note that swap metadata can be fragmented, +which means that the system can run out of +space before it reaches the theoretical limit. +Therefore, care should be taken to not configure +more swap than approximately half of the +theoretical maximum. +.Pp +Running out of space for swap metadata can leave +the system in an unrecoverable state. +Therefore, you should only change this parameter if you need to greatly extend the KVM reservation for other resources such as the buffer cache or Index: sys/amd64/include/param.h === --- sys/amd64/include/param.h (revision 239239) +++ sys/amd64/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Mach derived conversion macros */ #define round_page(x) unsigned long)(x)) + PAGE_MASK) & ~(PAGE_MASK)) Index: sys/i386/include/param.h === --- sys/i386/include/param.h (revision 239239) +++ sys/i386/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Ceiling on size of buffer cache (really only effects write queueing, * the VM page cache is not effected), can be changed via * the kern.maxbcache /boot/loader.conf variable. ___ 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"