From owner-freebsd-hackers Sun Jan 12 1: 9:54 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD60A37B401 for ; Sun, 12 Jan 2003 01:09:48 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E34843F43 for ; Sun, 12 Jan 2003 01:09:48 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0C99jYp068049; Sun, 12 Jan 2003 01:09:45 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0C99inM068048; Sun, 12 Jan 2003 01:09:44 -0800 (PST) Date: Sun, 12 Jan 2003 01:09:44 -0800 (PST) From: Matthew Dillon Message-Id: <200301120909.h0C99inM068048@apollo.backplane.com> To: Jake Burkholder Cc: hackers@FreeBSD.ORG, "Alan L. Cox" , Tor.Egge@cvsup.no.freebsd.org Subject: Re: vmapbuf/vunmapbuf consolidation -- need alpha/ia64 review. References: <20021102171534X.tegge@cvsup.no.freebsd.org> <3DCD7F3A.DE013857@imimic.com> <200301092137.h09Lbo0E005483@apollo.backplane.com> <3E1DF369.81ADB566@imimic.com> <200301100058.h0A0wiqo000380@apollo.backplane.com> <3E1FF17B.455C2A71@imimic.com> <200301112051.h0BKpiWr047795@apollo.backplane.com> <20030111161850.C212@locore.ca> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok, here is another rev of the patch. In the actual commit the #if 0's and the code they enclosed will be removed. I have tested this on i386 under -current. It would be nice if it could be tested on a sparc station just to make sure everything is working as expected. -Matt Index: alpha/alpha/vm_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/vm_machdep.c,v retrieving revision 1.77 diff -u -r1.77 vm_machdep.c --- alpha/alpha/vm_machdep.c 10 Dec 2002 02:33:43 -0000 1.77 +++ alpha/alpha/vm_machdep.c 11 Jan 2003 20:39:48 -0000 @@ -337,6 +337,8 @@ { } +#if 0 + /* * Map an IO request into kernel virtual address space. * @@ -405,6 +407,8 @@ bp->b_data = bp->b_saveaddr; } + +#endif /* * Reset back to firmware. Index: i386/i386/vm_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/vm_machdep.c,v retrieving revision 1.196 diff -u -r1.196 vm_machdep.c --- i386/i386/vm_machdep.c 10 Dec 2002 02:33:43 -0000 1.196 +++ i386/i386/vm_machdep.c 11 Jan 2003 20:40:23 -0000 @@ -435,6 +435,8 @@ return((int)va); } +#if 0 + /* * Map an IO request into kernel virtual address space. * @@ -508,6 +510,7 @@ bp->b_data = bp->b_saveaddr; } +#endif /* * Force reset the processor by invalidating the entire address space! Index: ia64/ia64/vm_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/ia64/ia64/vm_machdep.c,v retrieving revision 1.51 diff -u -r1.51 vm_machdep.c --- ia64/ia64/vm_machdep.c 10 Dec 2002 02:33:43 -0000 1.51 +++ ia64/ia64/vm_machdep.c 11 Jan 2003 20:41:06 -0000 @@ -350,6 +350,8 @@ { } +#if 0 + /* * Map an IO request into kernel virtual address space. * @@ -418,6 +420,8 @@ bp->b_data = bp->b_saveaddr; } + +#endif /* * Force reset the processor by invalidating the entire address space! Index: kern/vfs_bio.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.352 diff -u -r1.352 vfs_bio.c --- kern/vfs_bio.c 7 Jan 2003 19:55:08 -0000 1.352 +++ kern/vfs_bio.c 12 Jan 2003 05:21:16 -0000 @@ -3540,6 +3540,82 @@ bp->b_npages = newnpages; } +/* + * Map an IO request into kernel virtual address space. + * + * All requests are (re)mapped into kernel VA space. + * Notice that we use b_bufsize for the size of the buffer + * to be mapped. b_bcount might be modified by the driver. + */ +void +vmapbuf(struct buf *bp) +{ + caddr_t addr, kva; + vm_offset_t pa; + int pidx; + struct vm_page *m; + struct pmap *pmap = &curproc->p_vmspace->vm_pmap; + + GIANT_REQUIRED; + + if ((bp->b_flags & B_PHYS) == 0) + panic("vmapbuf"); + + for (addr = (caddr_t)trunc_page((vm_offset_t)bp->b_data), pidx = 0; + addr < bp->b_data + bp->b_bufsize; + addr += PAGE_SIZE, pidx++) { + /* + * Do the vm_fault if needed; do the copy-on-write thing + * when reading stuff off device into memory. + * + * NOTE! Must use pmap_extract() because addr may be in + * the userland address space, and kextract is only guarenteed + * to work for the kernland address space (see: sparc64 port). + */ + vm_fault_quick((addr >= bp->b_data) ? addr : bp->b_data, + (bp->b_iocmd == BIO_READ)?(VM_PROT_READ|VM_PROT_WRITE):VM_PROT_READ); + pa = trunc_page(pmap_extract(pmap, (vm_offset_t) addr)); + if (pa == 0) + panic("vmapbuf: page not present"); + m = PHYS_TO_VM_PAGE(pa); + vm_page_hold(m); + bp->b_pages[pidx] = m; + } + if (pidx > btoc(MAXPHYS)) + panic("vmapbuf: mapped more than MAXPHYS"); + pmap_qenter((vm_offset_t)bp->b_saveaddr, bp->b_pages, pidx); + + kva = bp->b_saveaddr; + bp->b_npages = pidx; + bp->b_saveaddr = bp->b_data; + bp->b_data = kva + (((vm_offset_t) bp->b_data) & PAGE_MASK); +} + +/* + * Free the io map PTEs associated with this IO operation. + * We also invalidate the TLB entries and restore the original b_addr. + */ +void +vunmapbuf(struct buf *bp) +{ + int pidx; + int npages; + + GIANT_REQUIRED; + + if ((bp->b_flags & B_PHYS) == 0) + panic("vunmapbuf"); + + npages = bp->b_npages; + pmap_qremove(trunc_page((vm_offset_t)bp->b_data), + npages); + vm_page_lock_queues(); + for (pidx = 0; pidx < npages; pidx++) + vm_page_unhold(bp->b_pages[pidx]); + vm_page_unlock_queues(); + + bp->b_data = bp->b_saveaddr; +} #include "opt_ddb.h" #ifdef DDB Index: powerpc/powerpc/vm_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/powerpc/powerpc/vm_machdep.c,v retrieving revision 1.80 diff -u -r1.80 vm_machdep.c --- powerpc/powerpc/vm_machdep.c 8 Jan 2003 12:29:59 -0000 1.80 +++ powerpc/powerpc/vm_machdep.c 11 Jan 2003 20:41:20 -0000 @@ -230,6 +230,9 @@ panic("cpu_throw() didn't"); } + +#if 0 + /* * Map an IO request into kernel virtual address space. * @@ -303,6 +306,8 @@ bp->b_data = bp->b_saveaddr; } + +#endif /* * Reset back to firmware. Index: sparc64/sparc64/vm_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/sparc64/sparc64/vm_machdep.c,v retrieving revision 1.32 diff -u -r1.32 vm_machdep.c --- sparc64/sparc64/vm_machdep.c 5 Jan 2003 05:30:40 -0000 1.32 +++ sparc64/sparc64/vm_machdep.c 11 Jan 2003 20:41:33 -0000 @@ -377,6 +377,8 @@ return(r); } +#if 0 + /* * Map an IO request into kernel virtual address space. * @@ -450,3 +452,5 @@ bp->b_data = bp->b_saveaddr; } + +#endif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 12 2:10:40 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5317037B401; Sun, 12 Jan 2003 02:10:39 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA4BC43F3F; Sun, 12 Jan 2003 02:10:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0CAAcYp081371; Sun, 12 Jan 2003 02:10:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0CAAcr4081370; Sun, 12 Jan 2003 02:10:38 -0800 (PST) Date: Sun, 12 Jan 2003 02:10:38 -0800 (PST) From: Matthew Dillon Message-Id: <200301121010.h0CAAcr4081370@apollo.backplane.com> To: hackers@freebsd.org, rwatson@freebsd.org Subject: possible cpu_wait() / vm_waitproc() / MAC problem Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG While working on an MFC I noticed that sys/compat/svr4/svr4_misc.c (in CURRENT) is calling cpu_wait() in svr4_sys_waitsys() instead of vm_waitproc(). I believe it needs to call vm_waitproc(). Can anyone say for sure? Also, in kern/kern_exit.c the wait code has this: #ifdef MAC mac_destroy_proc(p) #endif This appears to be missing from svr4_sys_waitsys() as well, also in -current. Could someone confirm that? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 12 5: 8:52 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24AE637B401 for ; Sun, 12 Jan 2003 05:08:50 -0800 (PST) Received: from nebula.wanadoo.fr (ca-sqy-2-218.abo.wanadoo.fr [80.8.55.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A59B43F6B for ; Sun, 12 Jan 2003 05:08:49 -0800 (PST) (envelope-from dak@wanadoo.fr) Received: from nebula.wanadoo.fr (localhost.wanadoo.fr [127.0.0.1]) by nebula.wanadoo.fr (8.12.6/8.12.6) with ESMTP id h0CD92sG016946 for ; Sun, 12 Jan 2003 14:09:02 +0100 (CET) (envelope-from dak@nebula.wanadoo.fr) Received: (from dak@localhost) by nebula.wanadoo.fr (8.12.6/8.12.6/Submit) id h0CD92fM016945 for hackers@freebsd.org; Sun, 12 Jan 2003 14:09:02 +0100 (CET) Date: Sun, 12 Jan 2003 14:09:01 +0100 From: Aurelien Nephtali To: hackers@freebsd.org Subject: dlopen()/dlsym()/etc sources ? Message-ID: <20030112130901.GA16913@nebula.wanadoo.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline User-Agent: Mutt/1.5.3i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I would like to know where are the dlopen()/dlsym()/etc sources ? There's nothing in the libc sources :/ (I'm using the HEAD tree) -- Aurelien --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+IWjtDNsbHbt8ok8RAnNYAJwK7IByJC2qgXntIayF7TBQu6bNXwCeKu0D W2xLzxaTN6fOmh5fzryYCIA= =3jPD -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 12 6: 9:44 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9555D37B401 for ; Sun, 12 Jan 2003 06:09:43 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28B8243F5B for ; Sun, 12 Jan 2003 06:09:43 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0007.cvx40-bradley.dialup.earthlink.net ([216.244.42.7] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18Xio1-0003L1-00; Sun, 12 Jan 2003 06:09:41 -0800 Message-ID: <3E2176CE.DAFE9A24@mindspring.com> Date: Sun, 12 Jan 2003 06:08:14 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aurelien Nephtali Cc: hackers@freebsd.org Subject: Re: dlopen()/dlsym()/etc sources ? References: <20030112130901.GA16913@nebula.wanadoo.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a45505fcef9aa9ffcd02c1c7b2aee69386548b785378294e88350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Aurelien Nephtali wrote: > I would like to know where are the dlopen()/dlsym()/etc sources ? > There's nothing in the libc sources :/ > > (I'm using the HEAD tree) src/lib/csu/common/crtbegin.c src/lib/csu/i386/crt0.c src/lib/csu/i386-elf/crt1.c That's the glue. The actual functions are mapped in from a known symbol offset from the entrypoint in the ld.so (src/libexec/rtld-elf/). This is "you are not expected to understand this" code. If you are trying for a static libdlopen.a, then you should look at the way that constructors (ctor's) are handled, and the code that is "#ifdef DYNAMIC". Basically, you will need to change the ctor functions to pass a void * instead of nothing (void), and make it the base address of the context structure that used in the initialization phase in the crt0 code. Then make a static library with a constructor that mmap's in the ld.so, and then knows the offset of the .entry, and passes the main arg vector (the base address of the context structure) to the constructor there, which will let you resolve the dlopen/dlclose/etc. symbols. It's a bit of work, because of the compiler changes needed for the constructors modifies the way C++ handles them (particularly, you will shoot your foot off with --callee-pop, if you don't expect the void * as an argument, but there are other dangers, too...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 12 6:18:51 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5549C37B401 for ; Sun, 12 Jan 2003 06:18:43 -0800 (PST) Received: from mail.bellavista.cz (mail.bellavista.cz [62.168.44.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16BB743F13 for ; Sun, 12 Jan 2003 06:18:42 -0800 (PST) (envelope-from neuhauser@bellavista.cz) Received: from freepuppy.bellavista.cz (freepuppy.bellavista.cz [10.0.0.10]) by mail.bellavista.cz (Postfix) with ESMTP id BE4D969; Sun, 12 Jan 2003 15:18:40 +0100 (CET) Received: by freepuppy.bellavista.cz (Postfix, from userid 1001) id 639922FDE06; Sun, 12 Jan 2003 15:18:39 +0100 (CET) Date: Sun, 12 Jan 2003 15:18:39 +0100 From: Roman Neuhauser To: Terry Lambert Cc: Roman Neuhauser Subject: Re: sendmail: how to get the named of FreeBSD4.7 standards compliant? Message-ID: <20030112141839.GY1196@freepuppy.bellavista.cz> Mail-Followup-To: Terry Lambert , Roman Neuhauser References: <20030101181330.C8233@disp.oper.dinoex.org> <3E134659.78028611@mindspring.com> <20030106173652.A495@disp.oper.dinoex.org> <20030109132202.GG1196@freepuppy.bellavista.cz> <3E1DE003.73BF3025@mindspring.com> <20030110105903.GL1196@freepuppy.bellavista.cz> <3E1F1FC6.D5D33801@mindspring.com> <20030110214845.GW1196@freepuppy.bellavista.cz> <3E1F54D3.64C85686@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1F54D3.64C85686@mindspring.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG thanks for not cc'ing me. # tlambert2@mindspring.com / 2003-01-10 15:18:43 -0800: > Roman Neuhauser wrote: > > > So, do you manually put "yahoo.com" SOA records in your DNS? > > > > no. > > > > > How do you answer requests for "yahoo.com". > > > > it's simple: > > [ ... "I have a DNS caching server that forwards all requests, > except those to "bellavista.cz"; for those, it does > content redirection on the request to another server > whose sole purpose in life is to answer those requests, > while refusing all other requests" ... ] actually, the DNS cache is recursive: it doesn't forward, it resolves the names itself. > [ ... ] > > my real setup is this: 10.0.0.1 is the router, and I have a DNS > > cache on 10.0.0.25, and a content server authoritative for > > bellavista.cz on 10.0.0.26. or at least it thinks it's > > authoritative, and the cache is configured to short-circuit all > > queries about bellavista.cz to 10.0.0.26. > > > > now, this setup might actually look a bit different. suppose the > > outside IP of my router (62.168.44.50) is listed as an authoritative > > server for bellavista.cz, and suppose I forward all traffic for > > 62.168.44.50:53 to 10.0.0.26:53. the content nameserver can then > > provide different answers based on the client's IP address. > > nonrecursive queries (RD bit cleared; "gimme an authoritative > > answer") about lilith.bellavista.cz comming from 10.0.0/24 will be > > answered with 10.0.0.1, while those coming from anywhere else will > > get 62.168.44.50. and so on. > > In "bind", this is called a "view". I noted previously that this > can be accomplished with bind version 9. so I heard. > The thing that makes this different is that you are consuming > multiple internal IP addresses for your seperate DNS servers. > While this is possible, it's generally not recommended, because > of Windows stupidity. I still don't understand this claim. The Windows boxen will never ask the authoritative server, so I don't see any problem. There's obviously none [that would affect my users], as this is exactly what I do, and no machines have any trouble with resolving. That means several FreeBSD boxes, several NT 5, NT 5.1, and a W98 box. No problems whatsoever. All these systems delegate name resolution to 10.0.0.25, which is a *cache*, through /etc/resolv.conf or its windowsland counterpart. The cache at 10.0.0.25 resolves names by recursing the name server hierarchy rooted at {a..m}.root-servers.net with the exception of bellavista.cz, which is short-circuited to 10.0.0.26. > As far as splitting the responses by source IP address: that only > works by default if all machines in the domain are interior to > the local network, and all machines which are externally visible > are dual-homed. Many DSL lines these days are done via a /2, > which means they are limited to 2 routable addresses. No, it only works by default if all the DNS *caches* are interior to the local network, because the content DNS server is queried by the cache, not the Windows client. > As far as whether or not the external interface is a real primary, > a stealth primary, or a stealth secondary, really depends on the > configuration of the connection. ... > Basically, you need to be able to GUI-config the device you keep trying to divert the point of discussion. the OP has had Bind ans Sendmail configured without a GUI configurator; nowhere did he mention a need for one. > > again, the content server only knows about names within/under > > bellavista.cz, it doesn't need to know the root servers. the cache > > is recursive, so it does. > > Clearly, you have either written your own cache, or you are using > DJB's cache, with patches. I use djbdns without any patches. I might not have expressed myself clearly: "the content server only knows about names within/under bellavista.cz, it doesn't need to know the root servers. the cache is recursive, so it does need to know them." > > > > Hmm? Are you talking about having both a cache and a content server > > > > on a router? The interior Windows clients of course only query the > > > > cache, so you can have the content server on 127.0.0.1. And, BTW, I > > > > don't see why I couldn't have more than one address on the inside > > > > interface, cache on one, content/authoritative server on another. > > > > > > Because your Windows clients could contact only one of them. > > > > sure. Windows clients ask the cache, which in turn asks the content > > server. > > This works, if you cache maintains a fixed IP address, and if > you can configure Microsoft's DHCP server to give out the IP > address of your cache for it's DNS. the OP has FreeBSD on both the router/NAT and the inside box. nowhere did he mention using windows or DHCP. > > > Where was *your* second nameserver again? I see a nameserver on > > > 10.0.0.{1,2}; where is your nameserver on 1.2.3.4? > > > > DNS works just fine with one authoritative server. requiring two is > > an administrative decision, and nothing in the protocol enforces it. > > This presumes a caching DNS server, which is willing to "split the > view" on your behalf. This is, I admit, a possibility, but it's an > administrative headache. I don't see the connection between a domain being on a single authoritative server, and a cache. The cache will query any name server of those it got referred to; the number only has a lower bound defined precisely (your nameserver might only listen on udp/53, so the count'd be limited by what fits in a udp datagram). > We are talking about systems that are deployed in locations where > there are no UNIX or network administrators employed. No we are taling about systems administered by the OP, which are various versions of FreeBSD. more unrelated problems > > > And then, how does an internal client get the external IP "yahoo.com", > > > if the requests are being dropped?!? > > > > I think I answered this. > > You did: a specialized proxy cache. Does the ability to override the content server asked for a domain base specialization? that depends on what you base your view of generalness on. if you ever used Windows 95, the ability to bind more than one IP to and interface would probably make every other OS look highly specialized. > > > > > [This is complicated] > > > > > both as noted above, for Windows clients (it would require a second IP > > > > > address on the interior network, minimally, to resolve), > > > > > > > > which is: > > > > > > > > 1. not true in the sense that you can have the authoritative server > > > > on 127.0.0.1 which is always there > > > > > > Then it's a proxy for the interior and exterior DNS servers running > > > on your border device. It's also specially written, rather than > > > using off-the-shelf software, since it can't be a standard bind. right. it's a standard, off-the-shelf, no-patches, djbdns. > > I don't think you'd want to provide a promiscuous DNS cache. it > > should listen on the inside IP only. > > I really disagree with this. so you think having a cache on your outer interface, so that anyone on the internet can put your IP in their /etc/resolv.conf, and abuse your resources, is a good idea? interesting. :) > > > > 2. trivial to add > > > > > > I guess, if you have the source code to Windows TCP on hand. Last > > > time I checked, this was millions of $ to license. > > > > err, did the OP have a Windows-based router? I thought it was > > FreeBSD. even if the router used Windows, the cache nor the content > > server has to live on it. > > Windows clients have certain protocol requirements and deficiencies, > designed to lock you into using Microsoft-supplied servers (e.g. the > inability to specify multiple servers for certain types of requests, > NT Domain registration, etc.). > > It may not be an issue if you are an all-Linux or all-BSD office, > but in most customer deployments, you can not avoid dealing with > Windows. again, the OP has specifically requested that others replying to his question limit the scope of their emails to his environment, which is a FreeBSD-4.7 box, and a FreeBSD-4.4 box: "What I am talking about is a limited test environment consisting _only_ of FreeBSD Systems." > The issue here is trying to arrive at a general solution to the > problem space, rather than trying to arrive at a particular way > of doing things, and then bending your customer to your model (a > good way to chase away a customer). Hmmm, I just checked, and adding an IP on an XP box is a matter of being able to operate the mouse. about 10 clicks; you don't even need to restart. so, what source, what millions? and, as I've already shown, Windows are perfectly happy in a setting you seem to consider next to impossible. the only difference is I don't use DHCP. > > > > > and by the fact that the IP address of the external interface is > > > > > unknown until after link-up, > > > > > > > > hm? what does the external IP have to do with this? > > > > > > It's where the other side of your horizon lives; it's where the > > > external DNS server lives. > > > > do you say "it's the IP authoritative for the domain"? if so, the > > OP will IMO have to use a service similar to dyndns.org anyway. > > That's a possibility, but the Windows clients I've seen for that > have been seriously deficient. Technically, you've been able to > change IP addreses, etc., without rebooting since Windows 98, but > the damn thing will still prompt you "Reboot Now For Changes To > Take Effect?". a nonissue. the router is the dyndns, not the NATted windows machines behind it. > The actual implementation, in the dyndns.org case, requires more > infrastructure than they really have available there. It's a > partial solution, in that it doesn't support ASMTP and similar > things, necessary for externally hosted infrastructure. > > > > > > > which will generally occur well after the DHCP lease is granted to > > > > > interior machines. This is even urther complicated by the fact > > > > > that the DHCP server is likely to be a Windows Primary Domain > > > > > Controller, and therefore not the border device, itself. > > > > > > > > i don't see how that's related. > > > > > > You can't give a DHCP lease pointing to a DNS server on the > > > exterior interface, when you don't yet know the IP address of > > > the exterior interface. How can you configure an unknown IP > > > address?!? > > > > how can you publish the exterior interface as authoritative for a > > domain when you don't yet knwo the IP address of the interface? > > The answer is that you modify the configuration of the internal > DNS server, either via DNSUPDAT, or by modifying it's config files, > and kicking it in the head, on link-up/link-down events. My own > preference is to avoid the facial bruises. 8-). > > If the interior server then forwards requests to the external > server, that forwards to the ISP's forwarding servers (if it can), > then you are OK. no, forget caches. I asked about something else: how do you publish *to the outsied world* that your NS RR ns1.domain.tld has the IP a.b.c.d if you don't know the IP? How do you get a domain registered if you don't know the name server IP's? > > > > primary/secondary is: > > > > > > > > 1. Bindism > > > > > > OK, I now see that you are engaged on a religious crusade against > > > "bind". > > > > no I'm not. > > > > > If you want to partcipate in this thread, please refrain from > > > proselytizing us about DJBDNS. Thanks. > > > > hmmm? where did I mention djbdns? stop putting things I didn't (mean > > to) say in my mouth please. > > At this point, it's the only viable competitor to bind, at least > on my radar; I'd be interested in seeing an alternative, but by > condemning "primar/secondary" as a "bindism", it kind of shows > that whatever you're using, it's not "bind". ;^). more implementations use Bind's configuration data format, and probably zone transfers. it's just that this is not the only way of syncing the configuration among one's nameservers, and, IMO, zone transfers are a prime example of reinventing the wheel, and have zero relevance to the merit of DNS, which is publishing name<->ip bindings. even if it's obvious I don't use bind, I don't see what of my post made you think I was on any kind of crusade. also, you say you are interested in seeing a viable alternative, but don't want to hear about alternative implementations. interesting. > > > > 2. administrative concept. *I* can modify the data on either of the > > > > *authoritative* servers and rsyns+ssh the data to the other. It > > > > doesn't matter which way the data goes at all. (It is actually > > > > always done from A to B because the data is preprocessed and I only > > > > want to transfer the compiled form.) > > > > > > Your ISP will not permit this; > > > > my ISP couldn't care less. I don't know about yours. > > My ISP doesn't allow the modification of their databases via > an rsyc from a remote client. They are annoyed enough at > having to actually provide Internet connectivity, instead of > me just sending them money for no service at all... So your ISP's name servers are authoritative for your domain[s]. That's not my setup. > > > your ISP will *maybe* permit DNSSEC and DNSUPDAT, however. Speaking > > > from personal experience as "your ISP" (IBM Web Connection NOC, > > > Rochester, NY). > > > > aha. I'm glad you're not my ISP. I wouldn't be your customer for long. > > You can't get shell accounts from most ISPs in the U.S., either. The only service I need from my ISP is connectivity. The boxes are my own (as in: my employer's). Terry, if you want to keep this thread alive any longer (and want followups from me), keep it focused. No further pulling "dumb windows DHCP server" rabbits from the hat, please. -- If you cc me or remove the list(s) completely I'll most likely ignore your message. see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 12 7:49:44 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB34C37B401; Sun, 12 Jan 2003 07:49:42 -0800 (PST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7479243F13; Sun, 12 Jan 2003 07:49:42 -0800 (PST) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs.huji.ac.il with esmtp id 18XkMn-000A5B-00; Sun, 12 Jan 2003 17:49:41 +0200 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-hackers@FreeBSD.ORG Cc: smp@FreeBSD.ORG Subject: Re: Asus/PR-DLSR smp hangs on boot In-reply-to: Your message of Wed, 08 Jan 2003 11:21:13 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Jan 2003 17:49:41 +0200 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG problem solved, i had apm enabled. danny > hi, > I have yet another dual box to test, Asus Dual Intel/Xeon, > this one came preconfigured with 4.7 Release, and 'sort of works' - using the > 1Giga ethernet is problematic. > > The latest 4.7 stable hangs on boot - just after > SMP: AP CPU #1 Launched! > > btw, the -release hangs here for about 20 seconds, then goes on ok. > > here are 2 logs: > ftp://ftp/users/danny/freebsd/logs/release.log is from a successfull boot > ftp://ftp/users/danny/freebsd/logs/stable.log is from a failed boot. > > thanks, > danny > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 12 11:29:16 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95B5837B401 for ; Sun, 12 Jan 2003 11:29:15 -0800 (PST) Received: from hclb.demon.co.uk (hclb.demon.co.uk [158.152.8.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDD0B43F5B for ; Sun, 12 Jan 2003 11:29:12 -0800 (PST) (envelope-from devans@hclb.demon.co.uk) Received: from localhost (devans@localhost) by hclb.demon.co.uk (8.11.1/8.9.3) with ESMTP id h0CJQOE00719; Sun, 12 Jan 2003 19:26:24 GMT (envelope-from devans@hclb.demon.co.uk) Date: Sun, 12 Jan 2003 19:26:24 +0000 (GMT) From: Dave Evans To: "M. Warner Losh" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: boot2 no longer displays a prompt In-Reply-To: <20030111.143026.40685845.imp@bsdimp.com> Message-ID: <20030112191930.E499-100000@hclb.demon.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 11 Jan 2003, M. Warner Losh wrote: > In message: <1042319907snx@hclb.demon.co.uk> > devans@hclb.demon.co.uk (Dave Evans) writes: > : At bootup, boot2 is the program which displays a - sign on the console > : and if you hit the space bar it comes up with a prompt allowing you to > : change the drive and partition of the loader program, e.g. > : ad(0,e)/boot/loader. > : > : At least that's how it used to work. Nowadays, judging from my current > : of October 20, 2002, the - sign is no longer displayed and boot2 goes > : straight through to the loader. > : > : Is this a bug, perhaps fixed, or has the prompt been taken out to make > : room for UFS2 code? I've looked through the commit logs and there > : is nothing to indicate the prompt has been taken out. > > It appears that we set autoboot to 1. If there is a /boot.config and > we cannot parse it, we set it to 0. When set to 0 we prompt. > However, it looks like there might be a bug, or it might be a boot0cfg > issue: > I put -z in /boot.config as an illegal option, in the hope that it would disable autoboot. It does, the prompt is now displayed, but it does not allow you to type anything in. Even a carriage return has no effect. The result is you cannot boot at all. *** warning: do not try this unless you have a way of restoring boot.config :-( To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 12 11:32:38 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1715637B401 for ; Sun, 12 Jan 2003 11:32:37 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C1F343F13 for ; Sun, 12 Jan 2003 11:32:36 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0CJWY1e007198; Sun, 12 Jan 2003 12:32:35 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 12 Jan 2003 12:30:33 -0700 (MST) Message-Id: <20030112.123033.27800883.imp@bsdimp.com> To: devans@hclb.demon.co.uk Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: boot2 no longer displays a prompt From: "M. Warner Losh" In-Reply-To: <20030112191930.E499-100000@hclb.demon.co.uk> References: <20030111.143026.40685845.imp@bsdimp.com> <20030112191930.E499-100000@hclb.demon.co.uk> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20030112191930.E499-100000@hclb.demon.co.uk> Dave Evans writes: : : : On Sat, 11 Jan 2003, M. Warner Losh wrote: : : > In message: <1042319907snx@hclb.demon.co.uk> : > devans@hclb.demon.co.uk (Dave Evans) writes: : > : At bootup, boot2 is the program which displays a - sign on the console : > : and if you hit the space bar it comes up with a prompt allowing you to : > : change the drive and partition of the loader program, e.g. : > : ad(0,e)/boot/loader. : > : : > : At least that's how it used to work. Nowadays, judging from my current : > : of October 20, 2002, the - sign is no longer displayed and boot2 goes : > : straight through to the loader. : > : : > : Is this a bug, perhaps fixed, or has the prompt been taken out to make : > : room for UFS2 code? I've looked through the commit logs and there : > : is nothing to indicate the prompt has been taken out. : > : > It appears that we set autoboot to 1. If there is a /boot.config and : > we cannot parse it, we set it to 0. When set to 0 we prompt. : > However, it looks like there might be a bug, or it might be a boot0cfg : > issue: : > : : I put -z in /boot.config as an illegal option, in the hope : that it would disable autoboot. It does, the prompt is now displayed, : but it does not allow you to type anything in. Even a carriage return : has no effect. The result is you cannot boot at all. : : *** warning: do not try this unless you have a way of restoring : boot.config :-( Which makes sense, given the rest of the analysis. You'll need new boot blocks to fix it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 12 12:14: 1 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2188137B406 for ; Sun, 12 Jan 2003 12:13:57 -0800 (PST) Received: from kestrel.alerce.com (kestrel.alerce.com [209.182.219.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A91C43F1E for ; Sun, 12 Jan 2003 12:13:56 -0800 (PST) (envelope-from hartzell@rosebud.alerce.com) Received: from rosebud.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) by kestrel.alerce.com (8.12.4/8.12.4) with ESMTP id h0CKDUk6017177 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sun, 12 Jan 2003 12:13:31 -0800 (PST) (envelope-from hartzell@rosebud.alerce.com) X-Authentication-Warning: kestrel.alerce.com: Host w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92] claimed to be rosebud.alerce.com Received: from rosebud.alerce.com (rosebud.alerce.com [127.0.0.1]) by rosebud.alerce.com (8.12.7/8.12.7) with ESMTP id h0CKCFVj010659 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 12 Jan 2003 12:12:16 -0800 (PST) (envelope-from hartzell@rosebud.alerce.com) Received: (from hartzell@localhost) by rosebud.alerce.com (8.12.7/8.12.6/Submit) id h0CKCFKc010656; Sun, 12 Jan 2003 12:12:15 -0800 (PST) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15905.52254.957313.867553@rosebud.alerce.com> Date: Sun, 12 Jan 2003 12:12:14 -0800 To: freebsd-hackers@freebsd.org Subject: usb keychain memory disk doesn't work on 4.7p3 X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: hartzell@kestrel.alerce.com (George Hartzell) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I can't make my little Lexar JumpDrive 128Mb USB keychain memory "disk" work. The device works on a windows machine, and worked on this very laptop back when it was running Redhat Linux 7.2 w/ RedHat's various updates. I got the same failure trying to use the device on a Dell OptiPlex GX110. I'm using: - Sony Vaio PCG-Z505JE - FreeBSD 4.7p3 from cvs When I insert the device, I get this in /var/log/messages: Jan 12 12:04:28 rosebud /kernel: umass0: LEXR PLUG DRIVE LEXR PLUG DRIVE, rev 1.10/0.01, addr 2 Jan 12 12:04:28 rosebud /kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Jan 12 12:04:28 rosebud /kernel: da0: Removable Direct Access SCSI-2 device Jan 12 12:04:28 rosebud /kernel: da0: 650KB/s transfers Jan 12 12:04:28 rosebud /kernel: da0: 123MB (251904 512 byte sectors: 64H 32S/T 123C) With this in my /etc/fstab: /dev/da0c /mnt/jumpdrive msdos rw,noauto 0 0 I get this when I try a mount: > sudo mount /mnt/jumpdrive msdos: /dev/da0c: Input/output error And this in /var/log/messages: Jan 12 12:05:02 rosebud /kernel: da0: reading primary partition table: error reading fsbn 0 I've tried every device in /dev/da0*: /dev/da0 /dev/da0c /dev/da0f /dev/da0s1 /dev/da0s1c /dev/da0s1f /dev/da0s2 /dev/da0a /dev/da0d /dev/da0g /dev/da0s1a /dev/da0s1d /dev/da0s1g /dev/da0s3 /dev/da0b /dev/da0e /dev/da0h /dev/da0s1b /dev/da0s1e /dev/da0s1h /dev/da0s4 and get the same result with all of them. I've attached my dmesg info below: Can anyone either suggest a fix or a place to start looking? g. Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.7-RELEASE-p3 #2: Wed Jan 8 11:17:28 PST 2003 root@rosebud.alerce.com:/usr/obj/usr/src/sys/ROSEBUD Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (496.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 335478784 (327616K bytes) avail memory = 320507904 (312996K bytes) Preloaded elf kernel "kernel" at 0xc0567000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 7 entries at 0xc00fdf50 apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 9 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfc90-0xfc9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xfca0-0xfcbf irq 9 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: port 0x1040-0x104f at device 7.3 on pci0 pci0: (vendor=0x104d, dev=0x8039) at 8.0 irq 9 pcm0: port 0xfc8c-0xfc8f,0xfcc0-0xfcff mem 0xfedf8000-0xfedfffff irq 9 at device 9.0 on pci0 pci0: (vendor=0x14f1, dev=0x2443) at 10.0 irq 9 fxp0: port 0xfc40-0xfc7f mem 0xfec00000-0xfecfffff,0xfedf6000-0xfedf6fff irq 9 at device 11.0 on pci0 fxp0: Ethernet address 08:00:46:07:71:d5 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci_cfgintr_linked: linked (61) to hard-routed irq 9 pci_cfgintr: 0:12 INTA routed to irq 9 pcic0: irq 9 at device 12.0 on pci0 pcic0: PCI Memory allocated: 0x88000000 pccard0: on pcic0 pci0: (vendor=0x104d, dev=0x808a) at 13.0 irq 0 orm0: