From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 02:38:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 89EDB16A420 for ; Sun, 24 Jul 2005 02:38:48 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A23243D45 for ; Sun, 24 Jul 2005 02:38:47 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 25293 invoked from network); 24 Jul 2005 02:35:39 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 24 Jul 2005 02:35:39 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6O2ckg7015410; Sat, 23 Jul 2005 22:38:46 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6O2cj6A015409; Sat, 23 Jul 2005 22:38:45 -0400 Date: Sat, 23 Jul 2005 22:38:45 -0400 From: Edwin To: Max Laier Message-ID: <20050724023845.GA15209@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507231623.16183.max@love2party.net> <20050723184108.GA14076@asx01.verolan.com> <200507240027.54127.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200507240027.54127.max@love2party.net> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: Edwin , freebsd-hackers@freebsd.org, Giorgos Keramidas Subject: Re: help w/panic under heavy load - 5.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2005 02:38:48 -0000 Max/et.al., replies to your message in-line below... If I understand correctly...(albeit an overly brief understanding :)) 1. ethernet packet comes in - stuck into an mbuf 2. ether_demux calls ip_fastforward passing the mbuf struct 3. mbuf struct is copied/munged into ip struct by mtod 4. ntohs is called to change ip->ip_len to host byte order incidentally - ip_len should be set to ntohs(ip->ip_len) as well - it seems like neither one of those calls worked? 5. also - the call to set hlen to ip->ip_hl <<2 didn't work out well either - right? since hlen = -1057417216, and i think it's supposed to be 20 (5*4) - am I correct there as well? 6. due to ip->ip_len being in network byte order still a little gremlin helps us to think we have a 10240 byte packet and we need to fragment it... 7. in ip_fragment - ip->ip_len is still 10240 - so we assume that we need to make several fragments - however, the mbuf is correct (len = 40) 8. in ip_fragment - to create the 'second' fragment, we try to copy 1480 bytes @ offset 1500 out of the mbuf that only has a valid data length of 40-bytes??? Are we really looking for the cause of ip->ip_len not being in the correct order @ the right time then? - in that case - there's two possibilities that I see - and I don't think that ntohs not working (1) is too realistic, so I would suppose we are looking for what flipped it in the first place? 1. either ntohs didn't work for some reason, or 2. it was already in host order, and the ntohs call flipped it back to network order If you feel that it's a ipfw/ipfil issue - I can easily take IPFIREWALL* options out of the kernel and build a new one - just give me about 15 minutes. cheers. /edwin Max Laier (max@love2party.net) wrote: > On Saturday 23 July 2005 20:41, Edwin wrote: > > Kernel name: D1-0722 (for reference) > > > > mbsd05# kgdb kernel.debug /usr/local/STORAGE/crash/vmcore.5 > > #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at > > /usr/src/sys/netinet/ip_fastfwd.c:572 warning: Source file is more recent > > than executable. > > Let's hope that's still correct ... > it is - result of manual patch application and removal - just the timestamp/dates on the file are different (verified by diff from clean source tree just now to make sure again. > > 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, > > (kgdb) l > > 567 m->m_pkthdr.csum_flags |= CSUM_IP; > > 568 /* > > 569 * ip_fragment expects ip_len and ip_off in host byte > > 570 * order but returns all packets in network byte order > > 571 */ > > 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, > > 573 (~ifp->if_hwassist & CSUM_DELAY_IP))) { > > 574 goto drop; > > 575 } > > 576 KASSERT(m != NULL, ("null mbuf and no error")); > > (kgdb) i loc > > ip = (struct ip *) 0xc12f700e > > m0 = (struct mbuf *) 0xc12f700e > > ro = {ro_rt = 0xc11f8420, ro_dst = {sa_len = 16 '\020', sa_family = 2 > > '\002', sa_data = "\000\000À¨\002\005\000\000\000\000\000\000\000"}} > > dst = (struct sockaddr_in *) 0xc76bfc3c > > ia = (struct in_ifaddr *) 0x0 > > ifa = (struct ifaddr *) 0x0 > > ifp = (struct ifnet *) 0xc0f91800 > > odest = {s_addr = 84060352} > > dest = {s_addr = 84060352} > > sum = 0 > > ip_len = 0 > > This should not happen. ip_len is initialize from ntohs(ip->ip_len) and never > touched again. Anyway, let's look some more ... is it accurate to say that ip->ip_len is 10240 @ this point - but it should be 40? at line 542 of ip_fastfwd.c 1.17.2.7... the ip->ip_len <= mtu should eval to true and fall through to the true case - but it falls through to false (hence the ip_fragment section) - b/c it is still in network order? if (ip->ip_len <= mtu || (ifp->if_hwassist & CSUM_FRAGMENT && (ip->ip_off & IP_DF) == 0)) { /* * Restore packet header fields to original values */ ip->ip_len = htons(ip->ip_len); ip->ip_off = htons(ip->ip_off); /* * Send off the packet via outgoing interface */ error = (*ifp->if_output)(ifp, m, (struct sockaddr *)dst, ro.ro_rt); } else { /* * Handle EMSGSIZE with icmp reply needfrag for TCP MTU discovery */ if (ip->ip_off & IP_DF) { ipstat.ips_cantfrag++; icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_NEEDFRAG, 0, ifp); goto consumed; } else { /* * We have to fragement the packet */ m->m_pkthdr.csum_flags |= CSUM_IP; /* * ip_fragment expects ip_len and ip_off in host byte * order but returns all packets in network byte order */ if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, (~ifp->if_hwassist & CSUM_DELAY_IP))) { goto drop; } KASSERT(m != NULL, ("null mbuf and no error")); /* > > > error = 84060352 > > hlen = -1057417216 > > mtu = 0 > > __func__ = "ip_fastforward" > > (kgdb) p *ip > > $1 = {ip_hl = 5, ip_v = 4, ip_tos = 0 '\0', ip_len = 10240, ip_id = 61249, > > ip_len should be 40 as ip_len is supposed to be in HOST BYTE ORDER at this > point. Feeding 10240 to ntohs() give the correct value, so something > obviously went wrong. > > Let's see how we got here: > 355 does the byteorder flip to host byte order > 366 pfil OUT > 451 pfil IN > 527 first check ip_len < if_mtu etc ... > > Obviously, the only thing that might mess with the byte order (unless I missed > something along the way) is one of the pfil consumers. > > *** > *** What firewall(s) are you running with? > *** ipfw enabled - it's a permit all (IPFIREWALL_DEFAULT_TOACCEPT) - output from 'ipfw show' fb54c# ipfw show 65535 26395 1874336 allow ip from any to any fb54c# here is the diff from the generic config mbsd05# diff /root/kernels/D1-0722 /root/kernels/GENERIC 21,22d20 < makeoptions DEBUG=-g < 24c22 < #cpu I486_CPU --- > cpu I486_CPU 26,27c24,25 < #cpu I686_CPU < ident D1-0722 --- > cpu I686_CPU > ident GENERIC 31,48d28 < < options KDB < options DDB < options INVARIANTS < options INVARIANT_SUPPORT < < options CPU_SOEKRIS < options CPU_GEODE < < options HZ=1000 < options DEVICE_POLLING < < options IPFIREWALL < options IPFIREWALL_VERBOSE < options IPFIREWALL_VERBOSE_LIMIT < options IPFIREWALL_DEFAULT_TO_ACCEPT < options DUMMYNET < options IPDIVERT mbsd05# > > > ip_off = 0, ip_ttl = 63 '?', ip_p = 17 '\021', ip_sum = 31921, ip_src = > > {s_addr = 67479744}, ip_dst = {s_addr = 84060352}} (kgdb) p *m > > $2 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc12f700e "E", > > mh_len = 40, mh_flags = 3, mh_type = 1}, M_dat = {MH = {MH_pkthdr = {rcvif > > = 0xc0f90000, len = 40, header = 0x0, csum_flags = 769, csum_data = 0, tags > > 40, there you have it - no need to fragment at all! > > > /usr/src/sys/netinet/ip_output.c:967 > > 967 m->m_next = m_copy(m0, off, len); > > (kgdb) l > > 962 len = ip->ip_len - off; > > 963 m->m_flags |= M_LASTFRAG; > > 964 } else > > 965 mhip->ip_off |= IP_MF; > > 966 mhip->ip_len = htons((u_short)(len + mhlen)); > > 967 m->m_next = m_copy(m0, off, len); > > 968 if (m->m_next == NULL) { /* copy failed */ > > 969 m_free(m); > > 970 error = ENOBUFS; /* ??? */ > > 971 ipstat.ips_odropped++; > > Just to make sure, we didn't touch the original packet at this point so the > above values are still the ones we based the (wrong) decision on. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 13:46:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A239216A41F; Sun, 24 Jul 2005 13:46:12 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09B1D43D55; Sun, 24 Jul 2005 13:46:11 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3E3B1.dip.t-dialin.net [84.163.227.177] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2Dk-1Dwgnx4Bz7-00083H; Sun, 24 Jul 2005 15:46:09 +0200 From: Max Laier To: freebsd-hackers@freebsd.org Date: Sun, 24 Jul 2005 15:46:01 +0200 User-Agent: KMail/1.8 References: <20050719034215.GB20752@asx01.verolan.com> <200507240027.54127.max@love2party.net> <20050724023845.GA15209@asx01.verolan.com> In-Reply-To: <20050724023845.GA15209@asx01.verolan.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3496715.Ok8sqIYstl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507241546.08255.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Edwin , Giorgos Keramidas Subject: Re: help w/panic under heavy load - 5.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2005 13:46:12 -0000 --nextPart3496715.Ok8sqIYstl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 24 July 2005 04:38, Edwin wrote: > If I understand correctly...(albeit an overly brief understanding :)) > > 1. ethernet packet comes in - stuck into an mbuf > 2. ether_demux calls ip_fastforward passing the mbuf struct > 3. mbuf struct is copied/munged into ip struct by mtod > 4. ntohs is called to change ip->ip_len to host byte order > incidentally - ip_len should be set to ntohs(ip->ip_len) > as well - it seems like neither one of those calls worked? > 5. also - the call to set hlen to ip->ip_hl <<2 didn't work out well > either - right? since hlen =3D -1057417216, and i think it's > supposed to be 20 (5*4) - am I correct there as well? 4. and 5. are strange but not of too much significance. Given that we got= =20 through the initial sanity checks and that neither is used further down, th= is=20 might jut be an optimization effect. You could try to mark ip_len as=20 volatile. > 6. due to ip->ip_len being in network byte order still a little > gremlin helps us to think we have a 10240 byte packet and we > need to fragment it... > 7. in ip_fragment - ip->ip_len is still 10240 - so we assume that we > need to make several fragments - however, the mbuf is correct > (len =3D 40) > 8. in ip_fragment - to create the 'second' fragment, we try to copy > 1480 bytes @ offset 1500 out of the mbuf that only has a valid > data length of 40-bytes??? That's what happens, yes. > Are we really looking for the cause of ip->ip_len not being in the correct > order @ the right time then? - in that case - there's two possibilities > that I see - and I don't think that ntohs not working (1) is too realisti= c, > so I would suppose we are looking for what flipped it in the first place? > > 1. either ntohs didn't work for some reason, or > 2. it was already in host order, and the ntohs call flipped it back to > network order Neither seems very likely. My guess is really *something* along the way=20 messing things up - pfil is the only suspect I have, right now. > If you feel that it's a ipfw/ipfil issue - I can easily take IPFIREWALL* > options out of the kernel and build a new one - just give me about 15 > minutes. Yes please and make sure it isn't loaded as a module either. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3496715.Ok8sqIYstl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC45ugXyyEoT62BG0RAtS1AJ9xYibWUEqzu7MT9dasOd5+b6ujcQCeMgZx U2/m9JEBc05ffYYLqcGA7h8= =l/Op -----END PGP SIGNATURE----- --nextPart3496715.Ok8sqIYstl-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 14:19:17 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 CE3B916A420 for ; Sun, 24 Jul 2005 14:19:17 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id A661543D5D for ; Sun, 24 Jul 2005 14:19:13 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 22949 invoked from network); 24 Jul 2005 14:16:05 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 24 Jul 2005 14:16:05 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6OEJCwL026328; Sun, 24 Jul 2005 10:19:12 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6OEJBRJ026327; Sun, 24 Jul 2005 10:19:11 -0400 Date: Sun, 24 Jul 2005 10:19:11 -0400 From: Edwin To: freebsd-hackers@freebsd.org Message-ID: <20050724141911.GA26240@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507240027.54127.max@love2party.net> <20050724023845.GA15209@asx01.verolan.com> <200507241546.08255.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200507241546.08255.max@love2party.net> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: Edwin , Max Laier Subject: Re: help w/panic under heavy load - 5.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2005 14:19:18 -0000 New kernel: ident D1-0723 (same as D1-0722 - but w/ IPFIREWALL* options removed) same traces asked for previously. Thanks again, /Edwin kgdb kernel.debug /usr/local/STORAGE/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc0460ef6 in db_fncall (dummy1=0, dummy2=0, dummy3=43, dummy4=0xc76bf9f4 "(úkÇ") at /usr/src/sys/ddb/db_command.c:531 #2 0xc0460d04 in db_command (last_cmdp=0xc08be624, cmd_table=0x0, aux_cmd_tablep=0xc083e324, aux_cmd_tablep_end=0xc083e340) at /usr/src/sys/ddb/db_command.c:349 #3 0xc0460dcc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc0462951 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc06277f2 in kdb_trap (type=3, code=0, tf=0xc76bfb30) at /usr/src/sys/kern/subr_kdb.c:468 #6 0xc07ad874 in trap (frame= {tf_fs = -949288936, tf_es = -1067319280, tf_ds = -1065287664, tf_edi = 1, tf_esi = -1065233792, tf_ebp = -949224592, tf_isp = -949224612, tf_ebx = -949224548, tf_edx = 0, tf_ecx = -1060921344, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067289229, tf_cs = -1065287672, tf_eflags = 658, tf_esp = -949224560, tf_ss = -1067377425}) at /usr/src/sys/i386/i386/trap.c:584 #7 0xc079deaa in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #8 0xc76b0018 in ?? () #9 0xc0620010 in sched_runnable () at /usr/src/sys/kern/sched_4bsd.c:641 #10 0xc0611cef in panic (fmt=0xc081d280 "m_copym, offset > size of mbuf chain") at /usr/src/sys/kern/kern_shutdown.c:550 #11 0xc064172c in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 #12 0xc0692b74 in ip_fragment (ip=0xc12f000e, m_frag=0xc76bfc6c, mtu=-1056775680, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 #13 0xc068f6e9 in ip_fastforward (m=0xc12e2300) at /usr/src/sys/netinet/ip_fastfwd.c:572 #14 0xc0672759 in ether_demux (ifp=0xc0f90000, m=0xc12e2300) at /usr/src/sys/net/if_ethersubr.c:770 #15 0xc06724f5 in ether_input (ifp=0xc0f90000, m=0xc12e2300) at /usr/src/sys/net/if_ethersubr.c:631 #16 0xc070a9e7 in sis_rxeof (sc=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1636 #17 0xc070ae6f in sis_intr (arg=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1841 #18 0xc0600130 in ithread_loop (arg=0xc0ec6880) at /usr/src/sys/kern/kern_intr.c:547 #19 0xc05ff5a4 in fork_exit (callout=0xc060000c , arg=0xc0ec6880, frame=0xc76bfd48) at /usr/src/sys/kern/kern_fork.c:791 #20 0xc079df0c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) f 13 #13 0xc068f6e9 in ip_fastforward (m=0xc12e2300) at /usr/src/sys/netinet/ip_fastfwd.c:572 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, (kgdb) l 567 m->m_pkthdr.csum_flags |= CSUM_IP; 568 /* 569 * ip_fragment expects ip_len and ip_off in host byte 570 * order but returns all packets in network byte order 571 */ 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, 573 (~ifp->if_hwassist & CSUM_DELAY_IP))) { 574 goto drop; 575 } 576 KASSERT(m != NULL, ("null mbuf and no error")); (kgdb) i loc ip = (struct ip *) 0xc12f000e m0 = (struct mbuf *) 0xc12f000e ro = {ro_rt = 0xc11ee420, ro_dst = {sa_len = 16 '\020', sa_family = 2 '\002', sa_data = "\000\000À¨\002\005\000\000\000\000\000\000\000"}} dst = (struct sockaddr_in *) 0xc76bfc3c ia = (struct in_ifaddr *) 0x0 ifa = (struct ifaddr *) 0x0 ifp = (struct ifnet *) 0xc0f91800 odest = {s_addr = 84060352} dest = {s_addr = 84060352} sum = 0 ip_len = 0 error = 84060352 hlen = -1057417216 mtu = 0 __func__ = "ip_fastforward" (kgdb) p *ip $1 = {ip_hl = 5, ip_v = 4, ip_tos = 0 '\0', ip_len = 10240, ip_id = 33436, ip_off = 0, ip_ttl = 64 '@', ip_p = 17 '\021', ip_sum = 59733, ip_src = {s_addr = 67479744}, ip_dst = {s_addr = 84060352}} (kgdb) p *m $2 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc12f000e "E", mh_len = 40, mh_flags = 3, mh_type = 1}, M_dat = {MH = {MH_pkthdr = {rcvif = 0xc0f90000, len = 40, header = 0x0, csum_flags = 769, csum_data = 0, tags = {slh_first = 0x0}}, MH_dat = {MH_ext = {ext_buf = 0xc12f0000 "", ext_free = 0, ext_args = 0x0, ext_size = 2048, ref_cnt = 0x0, ext_type = 3}, MH_databuf = "\000\000/Á\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\003", '\0' }}, M_databuf = "\000\000ùÀ(\000\000\000\000\000\000\000\001\003", '\0' , "/Á\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\003", '\0' }} (kgdb) p *ro.ro_rt $3 = {rt_nodes = {{rn_mklist = 0x0, rn_parent = 0xc11ee438, rn_bit = -1, rn_bmask = 0 '\0', rn_flags = 4 '\004', rn_u = {rn_leaf = {rn_Key = 0xc1069480 "\020\002", rn_Mask = 0x0, rn_Dupedkey = 0x0}, rn_node = { rn_Off = -1056533376, rn_L = 0x0, rn_R = 0x0}}}, {rn_mklist = 0x0, rn_parent = 0xc11ee120, rn_bit = 61, rn_bmask = 4 '\004', rn_flags = 4 '\004', rn_u = {rn_leaf = {rn_Key = 0x7
, rn_Mask = 0xc11ef000 "à\201üÀ8ä\036ÁÇÿ", rn_Dupedkey = 0xc11ee420}, rn_node = {rn_Off = 7, rn_L = 0xc11ef000, rn_R = 0xc11ee420}}}}, rt_gateway = 0xc1069490, rt_flags = 132101, rt_ifp = 0xc0f91800, rt_ifa = 0xc104f900, rt_rmx = {rmx_mtu = 1500, rmx_expire = 334076357, rmx_pksent = 7238}, rt_refcnt = 1, rt_genmask = 0x0, rt_llinfo = 0xc105d040 "`Ð\005Á", rt_gwroute = 0x0, rt_parent = 0xc11ef000, rt_mtx = {mtx_object = {lo_class = 0xc0876a9c, lo_name = 0xc08213a5 "rtentry", lo_type = 0xc08213a5 "rtentry", lo_flags = 4390912, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}} (kgdb) p *ifp $4 = {if_softc = 0xc0f91800, if_link = {tqe_next = 0xc0f90000, tqe_prev = 0xc08e1244}, if_xname = "sis0", '\0' , if_dname = 0xc0f2ecec "sis", if_dunit = 0, if_addrhead = { tqh_first = 0xc0ec0000, tqh_last = 0xc1038460}, if_klist = {kl_lock = 0xc08dae00, kl_list = { slh_first = 0x0}}, if_pcount = 0, if_carp = 0x0, if_bpf = 0x0, if_index = 1, if_timer = 5, if_nvlans = 0, if_flags = 34883, if_capabilities = 72, if_capenable = 72, if_linkmib = 0x0, if_linkmiblen = 0, if_data = { ifi_type = 6 '\006', ifi_physical = 0 '\0', ifi_addrlen = 6 '\006', ifi_hdrlen = 18 '\022', ifi_link_state = 2 '\002', ifi_recvquota = 0 '\0', ifi_xmitquota = 0 '\0', ifi_datalen = 80 'P', ifi_mtu = 1500, ifi_metric = 0, ifi_baudrate = 10000000, ifi_ipackets = 40, ifi_ierrors = 0, ifi_opackets = 7276, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 4728, ifi_obytes = 394534, ifi_imcasts = 30, ifi_omcasts = 24, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0, ifi_epoch = 0, ifi_lastchange = {tv_sec = 0, tv_usec = 0}}, if_multiaddrs = {tqh_first = 0xc0f94620, tqh_last = 0xc0fab5e0}, if_amcount = 0, if_output = 0xc0671b04 , if_input = 0xc0672298 , if_start = 0xc070b0f0 , if_ioctl = 0xc070be5c , if_watchdog = 0xc070bfe4 , if_init = 0xc070b440 , if_resolvemulti = 0xc0672b48 , if_spare1 = 0x0, if_spare2 = 0x0, if_spare3 = 0x0, if_spare_flags1 = 0, if_spare_flags2 = 0, if_snd = {ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 127, ifq_drops = 0, ifq_mtx = {mtx_object = {lo_class = 0xc0876a9c, lo_name = 0xc0f9180c "sis0", lo_type = 0xc082053b "if send queue", lo_flags = 196608, lo_list = { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, ifq_drv_head = 0x0, ifq_drv_tail = 0x0, ifq_drv_len = 0, ifq_drv_maxlen = 127, altq_type = 0, altq_flags = 1, altq_disc = 0x0, altq_ifp = 0xc0f91800, altq_enqueue = 0, altq_dequeue = 0, altq_request = 0, altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr = 0x0}, if_broadcastaddr = 0xc07d2ae0 "ÿÿÿÿÿÿ", lltables = 0x0, if_label = 0x0, if_prefixhead = {tqh_first = 0x0, tqh_last = 0xc0f91968}, if_afdata = {0x0 , 0xc0faaad0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, if_afdata_initialized = 1, if_afdata_mtx = { mtx_object = {lo_class = 0xc0876a9c, lo_name = 0xc082052b "if_afdata", lo_type = 0xc082052b "if_afdata", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, if_starttask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xc0670ec0 , ta_context = 0xc0f91800}} (kgdb) f 12 #12 0xc0692b74 in ip_fragment (ip=0xc12f000e, m_frag=0xc76bfc6c, mtu=-1056775680, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 967 m->m_next = m_copy(m0, off, len); (kgdb) i loc mhip = (struct ip *) 0xc102e240 m = (struct mbuf *) 0xc102e200 mhlen = 20 error = 0 hlen = 20 len = 1480 off = 1500 m0 = (struct mbuf *) 0xc12e2300 firstlen = 1480 mnext = (struct mbuf **) 0xc12e2304 nfrags = 1 (kgdb) exit Undefined command: "exit". Try "help". (kgdb) quit mbsd05# Max Laier (max@love2party.net) wrote: > > > If you feel that it's a ipfw/ipfil issue - I can easily take IPFIREWALL* > > options out of the kernel and build a new one - just give me about 15 > > minutes. > > Yes please and make sure it isn't loaded as a module either. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 15:42:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 F2E3B16A41F for ; Sun, 24 Jul 2005 15:42:01 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from stella.fs.ei.tum.de (stella.fs.ei.tum.de [129.187.54.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4EB743D5D for ; Sun, 24 Jul 2005 15:41:56 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from localhost (localhost [127.0.0.1]) by localhost.fs.ei.tum.de (Postfix) with ESMTP id 3FD068D7AA; Sun, 24 Jul 2005 17:41:53 +0200 (CEST) Received: from stella.fs.ei.tum.de ([127.0.0.1]) by localhost (stella [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29109-02; Sun, 24 Jul 2005 17:41:51 +0200 (CEST) Received: from [84.155.181.149] (p549BB595.dip.t-dialin.net [84.155.181.149]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by stella.fs.ei.tum.de (Postfix) with ESMTP id 8A4678D7A5; Sun, 24 Jul 2005 17:41:50 +0200 (CEST) In-Reply-To: <20050724141911.GA26240@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507240027.54127.max@love2party.net> <20050724023845.GA15209@asx01.verolan.com> <200507241546.08255.max@love2party.net> <20050724141911.GA26240@asx01.verolan.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-9-31149078" Message-Id: <5482ba855efad71b135ae3108352ce39@fs.ei.tum.de> Content-Transfer-Encoding: 7bit From: Simon 'corecode' Schubert Date: Sun, 24 Jul 2005 17:42:33 +0200 To: Edwin X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new at fs.ei.tum.de Cc: freebsd-hackers@freebsd.org, Max Laier Subject: Re: help w/panic under heavy load - 5.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2005 15:42:02 -0000 --Apple-Mail-9-31149078 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 24.07.2005, at 16:19, Edwin wrote: > (kgdb) f 13 > #13 0xc068f6e9 in ip_fastforward (m=3D0xc12e2300) at=20 > /usr/src/sys/netinet/ip_fastfwd.c:572 > (kgdb) i loc > ip =3D (struct ip *) 0xc12f000e > m0 =3D (struct mbuf *) 0xc12f000e > ro =3D {ro_rt =3D 0xc11ee420, ro_dst =3D {sa_len =3D 16 '\020', = sa_family =3D 2=20 > '\002', > sa_data =3D "\000\000=C0=A8\002\005\000\000\000\000\000\000\000"}} > dst =3D (struct sockaddr_in *) 0xc76bfc3c > ia =3D (struct in_ifaddr *) 0x0 > ifa =3D (struct ifaddr *) 0x0 > ifp =3D (struct ifnet *) 0xc0f91800 > odest =3D {s_addr =3D 84060352} > dest =3D {s_addr =3D 84060352} > sum =3D 0 > ip_len =3D 0 > error =3D 84060352 > hlen =3D -1057417216 > mtu =3D 0 > __func__ =3D "ip_fastforward" error =3D=3D 84060352 =3D=3D dest.s_addr hlen =3D=3D -1057417216 =3D=3D 0xc0f91800 =3D=3D ifp > (kgdb) f 12 > #12 0xc0692b74 in ip_fragment (ip=3D0xc12f000e, m_frag=3D0xc76bfc6c,=20= > mtu=3D-1056775680, if_hwassist_flags=3D0, sw_csum=3D1) > at /usr/src/sys/netinet/ip_output.c:967 > 967 m->m_next =3D m_copy(m0, off, len); > (kgdb) i loc > mhip =3D (struct ip *) 0xc102e240 > m =3D (struct mbuf *) 0xc102e200 > mhlen =3D 20 > error =3D 0 > hlen =3D 20 > len =3D 1480 > off =3D 1500 > m0 =3D (struct mbuf *) 0xc12e2300 > firstlen =3D 1480 > mnext =3D (struct mbuf **) 0xc12e2304 > nfrags =3D 1 mtu (parameter) =3D=3D -1056775680 =3D=3D 0xc102e200 =3D=3D m your stack (or gdb) seems seriously broken cheers simon --=20 Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low $$$ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ --Apple-Mail-9-31149078 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFC47btr5S+dk6z85oRAj5XAKDiihl/tLi3H9ly3FMYP1mjZOJnKQCfe+zw jk2/C+QYT5ZPIiJI2MrsR3A= =A1ST -----END PGP SIGNATURE----- --Apple-Mail-9-31149078-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 19:28:46 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 8B09F16A41F for ; Sun, 24 Jul 2005 19:28:46 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9A3C43D45 for ; Sun, 24 Jul 2005 19:28:45 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3D869.dip.t-dialin.net [84.163.216.105] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML21M-1Dwm9T2O1o-0002zA; Sun, 24 Jul 2005 21:28:43 +0200 From: Max Laier To: Simon 'corecode' Schubert Date: Sun, 24 Jul 2005 21:28:34 +0200 User-Agent: KMail/1.8 References: <20050719034215.GB20752@asx01.verolan.com> <20050724141911.GA26240@asx01.verolan.com> <5482ba855efad71b135ae3108352ce39@fs.ei.tum.de> In-Reply-To: <5482ba855efad71b135ae3108352ce39@fs.ei.tum.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1180782.GV4qP6AhaG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507242128.41197.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Edwin , freebsd-hackers@freebsd.org Subject: Re: help w/panic under heavy load - 5.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2005 19:28:46 -0000 --nextPart1180782.GV4qP6AhaG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 24 July 2005 17:42, Simon 'corecode' Schubert wrote: > On 24.07.2005, at 16:19, Edwin wrote: > > (kgdb) f 13 > > #13 0xc068f6e9 in ip_fastforward (m=3D0xc12e2300) at > > /usr/src/sys/netinet/ip_fastfwd.c:572 > > (kgdb) i loc > > ip =3D (struct ip *) 0xc12f000e > > m0 =3D (struct mbuf *) 0xc12f000e > > ro =3D {ro_rt =3D 0xc11ee420, ro_dst =3D {sa_len =3D 16 '\020', sa_fami= ly =3D 2 > > '\002', > > sa_data =3D "\000\000=C0=A8\002\005\000\000\000\000\000\000\000"}} > > dst =3D (struct sockaddr_in *) 0xc76bfc3c > > ia =3D (struct in_ifaddr *) 0x0 > > ifa =3D (struct ifaddr *) 0x0 > > ifp =3D (struct ifnet *) 0xc0f91800 > > odest =3D {s_addr =3D 84060352} > > dest =3D {s_addr =3D 84060352} > > sum =3D 0 > > ip_len =3D 0 > > error =3D 84060352 > > hlen =3D -1057417216 > > mtu =3D 0 > > __func__ =3D "ip_fastforward" > > error =3D=3D 84060352 =3D=3D dest.s_addr > hlen =3D=3D -1057417216 =3D=3D 0xc0f91800 =3D=3D ifp > > > (kgdb) f 12 > > #12 0xc0692b74 in ip_fragment (ip=3D0xc12f000e, m_frag=3D0xc76bfc6c, > > mtu=3D-1056775680, if_hwassist_flags=3D0, sw_csum=3D1) > > at /usr/src/sys/netinet/ip_output.c:967 > > 967 m->m_next =3D m_copy(m0, off, len); > > (kgdb) i loc > > mhip =3D (struct ip *) 0xc102e240 > > m =3D (struct mbuf *) 0xc102e200 > > mhlen =3D 20 > > error =3D 0 > > hlen =3D 20 > > len =3D 1480 > > off =3D 1500 > > m0 =3D (struct mbuf *) 0xc12e2300 > > firstlen =3D 1480 > > mnext =3D (struct mbuf **) 0xc12e2304 > > nfrags =3D 1 > > mtu (parameter) =3D=3D -1056775680 =3D=3D 0xc102e200 =3D=3D m > > your stack (or gdb) seems seriously broken Not necessarily. This can well be an effect of higher optimization levels. Edwin, what do you have for CFLAGS? Can you try to downgrade to "-O" for n= ow=20 so that we have a better chance to get a full view? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1180782.GV4qP6AhaG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC4+vpXyyEoT62BG0RAosVAJ9RntNVzk7FliR2lzV6KaSnFF/puwCcCqjN KSIzVQjcJHWIglOT6Q0BRtY= =kDbR -----END PGP SIGNATURE----- --nextPart1180782.GV4qP6AhaG-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 24 22:59:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 06C7D16A41F for ; Sun, 24 Jul 2005 22:59:44 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 85E0143D48 for ; Sun, 24 Jul 2005 22:59:43 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 6006 invoked from network); 24 Jul 2005 22:56:35 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 24 Jul 2005 22:56:35 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6OMxfxc028922; Sun, 24 Jul 2005 18:59:41 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6OMxeUd028921; Sun, 24 Jul 2005 18:59:40 -0400 Date: Sun, 24 Jul 2005 18:59:40 -0400 From: Edwin To: freebsd-hackers@freebsd.org Message-ID: <20050724225940.GA28529@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <20050724141911.GA26240@asx01.verolan.com> <5482ba855efad71b135ae3108352ce39@fs.ei.tum.de> <200507242128.41197.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507242128.41197.max@love2party.net> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: Edwin , Max Laier , Simon 'corecode' Schubert Subject: Re: help w/panic under heavy load - 5.4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2005 22:59:44 -0000 Max Laier (max@love2party.net) wrote: > > Edwin, what do you have for CFLAGS? Can you try to downgrade to "-O" for now > so that we have a better chance to get a full view? > Max, I have no CFLAGS or COPTFLAGS in /etc/make.conf - this was a basic kern-developer install on a blank PC. The only thing that's a little different about the box that i use to compile is that it's a dual processor machine - but no -j# options used in compilation of the kernel. the compile is proceding with the following as an example output from make/cc $ grep netinet /tmp/make.DEBUG1.output |grep fastfwd cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/ acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib /dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -incl ude opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/netinet/ip_fastfwd.c $ are you referring to the -fformat-extensions, -fno-common and -finline...etc optimizations as well? or just the -O v. -O2/-O3/-Os one? If yes to the -f* optimizations - besides commenting out parts of the makefiles - is there a 'normal' way to disable them? FWIW - I also had (I think) the same problem with the 5.3 release - but I never worked it out - just other things on my plate, so I don't believe it's a recent code change (ie. 5.4 timeframe) if it does turn out to be a code change. it also has something to do with the load on the box - I'm testing with small udp packets (using iperf) - if I step up the size - I have to step up the bandwidth in order to cause the panic. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 09:31:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 716D116A41F for ; Mon, 25 Jul 2005 09:31:28 +0000 (GMT) (envelope-from david@okeby.com) Received: from mail.iinet.net.au (mail-02.iinet.net.au [203.59.3.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 8BAFD43D48 for ; Mon, 25 Jul 2005 09:31:27 +0000 (GMT) (envelope-from david@okeby.com) Received: (qmail 20885 invoked from network); 25 Jul 2005 09:31:25 -0000 Received: from unknown (HELO ?192.168.10.70?) (203.59.135.107) by mail.iinet.net.au with SMTP; 25 Jul 2005 09:31:25 -0000 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: <4E380CDC-5198-4658-86FA-B8C1CF942AE8@okeby.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-hackers@freebsd.org From: David Okeby Date: Mon, 25 Jul 2005 17:31:23 +0800 X-Mailer: Apple Mail (2.733) X-Mailman-Approved-At: Mon, 25 Jul 2005 12:22:26 +0000 Subject: aac_pci.c Patch (support for HP ML110 G2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 09:31:28 -0000 This has been floating around on a google search for a while. Are there any plans to include it? It would be welcome functionality. I have tested it and it is working fine. Thanks Dave -- david@okeby.com > --- aac_pci.c.orig Mon Jul 25 20:11:34 2005 > +++ aac_pci.c Mon Jul 25 20:15:31 2005 > @@ -134,6 +134,8 @@ > "Adaptec SCSI RAID 2810SA"}, > {0x9005, 0x0285, 0x9005, 0x0293, AAC_HWIF_I960RX, > AAC_FLAGS_NO4GB, > "Adaptec SCSI RAID 21610SA"}, > + {0x9005, 0x0285, 0x103c, 0x3227, AAC_HWIF_I960RX, > AAC_FLAGS_NO4GB, > + "HP ML110 G2 (Adaptec 2610SA)"}, > {0x9005, 0x0286, 0x9005, 0x028c, AAC_HWIF_RKT, 0, > "Adaptec SCSI RAID 2230S"}, > {0x9005, 0x0286, 0x9005, 0x028d, AAC_HWIF_RKT, 0, From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 12:31:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 900A816A41F for ; Mon, 25 Jul 2005 12:31:23 +0000 (GMT) (envelope-from Achim_Leubner@adaptec.com) Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50D9843D45 for ; Mon, 25 Jul 2005 12:31:23 +0000 (GMT) (envelope-from Achim_Leubner@adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id j6PCVNc13876; Mon, 25 Jul 2005 05:31:23 -0700 Received: from nkse2k01.adaptec.com (nkse2k01.adaptec.com [172.28.193.32]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id j6PCVKg17423; Mon, 25 Jul 2005 05:31:20 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 25 Jul 2005 14:29:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: aac_pci.c Patch (support for HP ML110 G2) Thread-Index: AcWRE1P+grYtaEnSRqiFqxd9c/aGrwAAGUkQ From: "Leubner, Achim" To: "David Okeby" Cc: freebsd-hackers@freebsd.org Subject: RE: aac_pci.c Patch (support for HP ML110 G2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 12:31:23 -0000 Yes, there are plans to support the Adaptec 2610SA and other new Adaptec controllers. I already sent a patch to Scott Long and I think the support will be integrated soon after a test phase. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Achim Leubner Software Engineer / RAID drivers ICP vortex GmbH / Adaptec Inc. Phone: +49-351-8718291 =20 -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of David Okeby Sent: Montag, 25. Juli 2005 11:31 To: freebsd-hackers@freebsd.org Subject: aac_pci.c Patch (support for HP ML110 G2) This has been floating around on a google search for a while. Are =20 there any plans to include it? It would be welcome functionality. I have tested it and it is working fine. Thanks Dave -- david@okeby.com > --- aac_pci.c.orig Mon Jul 25 20:11:34 2005 > +++ aac_pci.c Mon Jul 25 20:15:31 2005 > @@ -134,6 +134,8 @@ > "Adaptec SCSI RAID 2810SA"}, > {0x9005, 0x0285, 0x9005, 0x0293, AAC_HWIF_I960RX, =20 > AAC_FLAGS_NO4GB, > "Adaptec SCSI RAID 21610SA"}, > + {0x9005, 0x0285, 0x103c, 0x3227, AAC_HWIF_I960RX, =20 > AAC_FLAGS_NO4GB, > + "HP ML110 G2 (Adaptec 2610SA)"}, > {0x9005, 0x0286, 0x9005, 0x028c, AAC_HWIF_RKT, 0, > "Adaptec SCSI RAID 2230S"}, > {0x9005, 0x0286, 0x9005, 0x028d, AAC_HWIF_RKT, 0, _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 12:35:36 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 4282C16A41F for ; Mon, 25 Jul 2005 12:35:36 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from camay.yandex.ru (camay.yandex.ru [213.180.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA68343D48 for ; Mon, 25 Jul 2005 12:35:35 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from YAMAIL (camay.yandex.ru) by mail.yandex.ru id ; Mon, 25 Jul 2005 16:35:20 +0400 Date: Mon, 25 Jul 2005 16:35:20 +0400 (MSD) From: "Felix-KM" Sender: Felix-KM@yandex.ru Message-Id: <42E4DC88.000006.21996@camay.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: Felix-KM@yandex.ru To: freebsd-hackers@freebsd.org X-Source-Ip: 82.179.191.126 X-Originating-Ip: unknown Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Felix-KM@yandex.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 12:35:36 -0000 I can't understand how to use the function copyout(). It is necessary to write the data from a device driver to the array defined in user program. I do it this way: #define IOCTL_GET_B _IOWR("F", 127, 0x4) ---- driver ---- struct my_softc { ... short unsigned int B; }; ... static int my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread *td) { struct my_softc *my_sc; int unit, error; unit = minor(dev); my_sc = (struct my_softc *)devclass_get_softc(my_devclass, unit); if (my_sc == NULL) return (ENXIO); switch(cmd) { ... case IOCTL_GET_B: error = copyout(&my_sc->B, data, sizeof(my_sc->B)); switch (error) { case 0: printf(" IOCTL_GET_B: %d\n", my_sc->B); break; case EFAULT: printf("EFAULT\n"); break; case EIO: printf("EIO\n"); break; case ENOMEM: printf("ENOMEM\n"); break; case ENOSPC: printf("ENOSPC\n"); break; } break; default: break; } return 0; } ---user program ---------------------- ... short unsigned int Data[32768]; int main(int argc, char *argv[]) { ... if (ioctl(fd0, IOCTL_GET_B, Data) == -1) err(1, "IOCTL_GET_B"); ... } ------- Here I get EFAULT. What have I done wrong? How can I do it correctly? From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 12:46:01 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3697D16A41F for ; Mon, 25 Jul 2005 12:46:01 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B98E43D53 for ; Mon, 25 Jul 2005 12:46:00 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from stevenp4 ([193.123.241.40]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.3.R) with ESMTP id md50001712863.msg for ; Mon, 25 Jul 2005 13:39:10 +0100 Message-ID: <003201c59116$af417da0$7f06000a@int.mediasurface.com> From: "Steven Hartland" To: "Leubner, Achim" , "David Okeby" References: Date: Mon, 25 Jul 2005 13:45:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Mon, 25 Jul 2005 13:39:10 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 193.123.241.40 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Mon, 25 Jul 2005 13:39:12 +0100 Cc: freebsd-hackers@freebsd.org Subject: Re: aac_pci.c Patch (support for HP ML110 G2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 12:46:01 -0000 Are these going to be back ported to 5.4 or is this going to be a 6.0 only thing? Steve / K ----- Original Message ----- From: "Leubner, Achim" Yes, there are plans to support the Adaptec 2610SA and other new Adaptec controllers. I already sent a patch to Scott Long and I think the support will be integrated soon after a test phase. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 12:53:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 5227016A41F for ; Mon, 25 Jul 2005 12:53:31 +0000 (GMT) (envelope-from stsp@stsp.in-berlin.de) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF83D43D49 for ; Mon, 25 Jul 2005 12:53:30 +0000 (GMT) (envelope-from stsp@stsp.in-berlin.de) X-Envelope-From: stsp@stsp.in-berlin.de Received: from dice.seeling33.de (e178181181.adsl.alicedsl.de [85.178.181.181]) (authenticated bits=0) by einhorn.in-berlin.de (8.12.10/8.12.10/Debian-4) with ESMTP id j6PCrROO002154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jul 2005 14:53:28 +0200 Received: by dice.seeling33.de (Postfix, from userid 1001) id 5AC5B33C3A; Mon, 25 Jul 2005 14:53:27 +0200 (CEST) Date: Mon, 25 Jul 2005 14:53:27 +0200 From: Stefan Sperling To: Felix-KM Message-ID: <20050725125327.GA2213@dice.seeling33.de> Mail-Followup-To: Felix-KM , freebsd-hackers@freebsd.org References: <42E4DC88.000006.21996@camay.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E4DC88.000006.21996@camay.yandex.ru> User-Agent: Mutt/1.4.2.1i X-Spam-Score: (-1.55) AWL,BAYES_00,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Cc: freebsd-hackers@freebsd.org Subject: Re: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 12:53:31 -0000 On Mon, Jul 25, 2005 at 04:35:20PM +0400, Felix-KM wrote: > I can't understand how to use the function copyout(). > It is necessary to write the data from a device driver to the > array defined in user program. > I do it this way: > > #define IOCTL_GET_B _IOWR("F", 127, 0x4) > Here I get EFAULT. > > What have I done wrong? How can I do it correctly? You may need to add your ioctl to another middle layer. For example, to add ioctls to network devices, I first added defines to sockio.h only, and it wouldn't work ("device not configured"). Then I found out that I had to add my ioctls to a rather large switch statement in if.c too. hope this helps, -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 12:55:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3467016A41F for ; Mon, 25 Jul 2005 12:55:24 +0000 (GMT) (envelope-from Achim_Leubner@adaptec.com) Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id E631C43D4C for ; Mon, 25 Jul 2005 12:55:23 +0000 (GMT) (envelope-from Achim_Leubner@adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id j6PCtLc19780; Mon, 25 Jul 2005 05:55:21 -0700 Received: from nkse2k01.adaptec.com (nkse2k01.adaptec.com [172.28.193.32]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id j6PCtIg25243; Mon, 25 Jul 2005 05:55:18 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 25 Jul 2005 14:53:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: aac_pci.c Patch (support for HP ML110 G2) Thread-Index: AcWRFpudPGmXn3ImS6+dg/2EUxz0ZAAAMl7Q From: "Leubner, Achim" To: "Steven Hartland" , "David Okeby" Cc: freebsd-hackers@freebsd.org Subject: RE: aac_pci.c Patch (support for HP ML110 G2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 12:55:24 -0000 Our plan is to integrate the patch into the 6.0-CURRENT and to make driver update packages for 5.3/5.4 to support the new controllers on these OS versions too. -----Original Message----- From: Steven Hartland [mailto:killing@multiplay.co.uk]=20 Sent: Montag, 25. Juli 2005 14:45 To: Leubner, Achim; David Okeby Cc: freebsd-hackers@freebsd.org Subject: Re: aac_pci.c Patch (support for HP ML110 G2) Are these going to be back ported to 5.4 or is this going to be a 6.0 only thing? Steve / K ----- Original Message -----=20 From: "Leubner, Achim" Yes, there are plans to support the Adaptec 2610SA and other new Adaptec controllers. I already sent a patch to Scott Long and I think the support will be integrated soon after a test phase. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 13:05:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 DDF5616A41F for ; Mon, 25 Jul 2005 13:05:29 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: from web52709.mail.yahoo.com (web52709.mail.yahoo.com [206.190.48.232]) by mx1.FreeBSD.org (Postfix) with SMTP id 67CDD43D48 for ; Mon, 25 Jul 2005 13:05:29 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 59035 invoked by uid 60001); 25 Jul 2005 13:05:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zo+6u6Gf6JTd8fTG6Q2f83VPmnEyq8+3RHhfRgBoUPPzRnd2wUq0e1/KGDg/8hFnoCum3cilQXYw/9mylA7qBxUFYEQCT2fnWUzQu/FJhBwfnHTDKF+KhVzeK6HV1uqJQPitJTX6GYEy80bWQ8fIOYSs2KPHDcLDUTrJJ/wjQyE= ; Message-ID: <20050725130528.59033.qmail@web52709.mail.yahoo.com> Received: from [64.186.168.226] by web52709.mail.yahoo.com via HTTP; Mon, 25 Jul 2005 06:05:28 PDT Date: Mon, 25 Jul 2005 06:05:28 -0700 (PDT) From: "Kamal R. Prasad" To: Felix-KM@yandex.ru, freebsd-hackers@freebsd.org In-Reply-To: <42E4DC88.000006.21996@camay.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 13:05:30 -0000 Im not sure of the bug in your code, but you have got to assume that copyout() would fail if the user/kernel addr passed to it is not accessible. regards -kamal --- Felix-KM wrote: > I can't understand how to use the function > copyout(). > It is necessary to write the data from a device > driver to the > array defined in user program. > I do it this way: > > #define IOCTL_GET_B _IOWR("F", 127, 0x4) > > ---- driver ---- > > struct my_softc { > ... > short unsigned int B; > }; > > ... > > static int > my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, > int flag, > > struct thread *td) > { > struct my_softc *my_sc; > int unit, error; > unit = minor(dev); > my_sc = (struct my_softc > *)devclass_get_softc(my_devclass, unit); > if (my_sc == NULL) > return (ENXIO); > switch(cmd) > { > ... > case IOCTL_GET_B: > error = copyout(&my_sc->B, data, > sizeof(my_sc->B)); > switch (error) > { > case 0: > printf(" IOCTL_GET_B: %d\n", my_sc->B); > break; > case EFAULT: > printf("EFAULT\n"); > break; > case EIO: > printf("EIO\n"); > break; > case ENOMEM: > printf("ENOMEM\n"); > break; > case ENOSPC: > printf("ENOSPC\n"); > break; > } > break; > default: > break; > } > return 0; > } > > ---user program ---------------------- > > ... > > short unsigned int Data[32768]; > > int > main(int argc, char *argv[]) > { ... > > if (ioctl(fd0, IOCTL_GET_B, Data) == -1) > err(1, "IOCTL_GET_B"); > > ... > } > > ------- > > Here I get EFAULT. > > What have I done wrong? How can I do it correctly? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant http://www.kamalprasad.com/ kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is. ------------------------------------------------------------ ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 13:21:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B6C6716A41F for ; Mon, 25 Jul 2005 13:21:43 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F81743D46 for ; Mon, 25 Jul 2005 13:21:42 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 1569A8C167; Mon, 25 Jul 2005 15:21:40 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17977-09; Mon, 25 Jul 2005 15:21:36 +0200 (CEST) Received: from firewall.demig (p50839592.dip0.t-ipconnect.de [80.131.149.146]) by server.absolute-media.de (Postfix) with ESMTP id 02905796D; Mon, 25 Jul 2005 15:21:34 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j6PDIjNB035525; Mon, 25 Jul 2005 15:18:45 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: , Date: Mon, 25 Jul 2005 15:18:44 +0200 Message-ID: <000101c5911b$62441260$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <42E4DC88.000006.21996@camay.yandex.ru> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: Subject: RE: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 13:21:43 -0000 > #define IOCTL_GET_B _IOWR("F", 127, 0x4) I think the third parameter to _IOWR should directly specify a type, e.g. _IOWR("F", 127, int) or _IOWR("F", 127, struct MyStruct). > > ---- driver ---- > > struct my_softc { > ... > short unsigned int B; > }; > > ... > > static int > my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, > struct thread *td) > { > struct my_softc *my_sc; > int unit, error; > unit = minor(dev); > my_sc = (struct my_softc *)devclass_get_softc(my_devclass, unit); > if (my_sc == NULL) > return (ENXIO); > switch(cmd) > { > ... > case IOCTL_GET_B: > error = copyout(&my_sc->B, data, sizeof(my_sc->B)); > switch (error) > { > case 0: > printf(" IOCTL_GET_B: %d\n", my_sc->B); > break; > case EFAULT: > printf("EFAULT\n"); > break; > case EIO: > printf("EIO\n"); > break; > case ENOMEM: > printf("ENOMEM\n"); > break; > case ENOSPC: > printf("ENOSPC\n"); > break; > } > break; > default: > break; > } > return 0; > } > > ---user program ---------------------- > > ... > > short unsigned int Data[32768]; > > int > main(int argc, char *argv[]) > { ... > > if (ioctl(fd0, IOCTL_GET_B, Data) == -1) > err(1, "IOCTL_GET_B"); > > ... > } > > ------- > > Here I get EFAULT. > > What have I done wrong? How can I do it correctly? The caddr_t data in your ioctl is already mapped into kernel memory. Look into the source of other device drivers. You'll find a lot of *(int *) data = ... So your copyout() has to fail because it tries to address memory which is not a part of your application's memory. >From errno(2): EFAULT: Bad address... I have no idea if it is possible for ioctls to have mapped more than a few 100 bytes for data exchange. You should use read and uiomove() instead. Norbert From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 14:14:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E815D16A447 for ; Mon, 25 Jul 2005 14:14:12 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from colgate.yandex.ru (colgate.yandex.ru [213.180.200.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 497F843D4C for ; Mon, 25 Jul 2005 14:14:12 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from YAMAIL (colgate.yandex.ru) by mail.yandex.ru id ; Mon, 25 Jul 2005 18:14:05 +0400 Date: Mon, 25 Jul 2005 18:14:05 +0400 (MSD) From: "Felix-KM" Sender: Felix-KM@yandex.ru Message-Id: <42E4F3AD.000001.28235@colgate.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: Felix-KM@yandex.ru To: NKoch@demig.de In-Reply-To: <000101c5911b$62441260$4801a8c0@ws-ew-3.W2KDEMIG> References: <000101c5911b$62441260$4801a8c0@ws-ew-3.W2KDEMIG> X-Source-Ip: 82.179.191.126 X-Originating-Ip: unknown Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: RE: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Felix-KM@yandex.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 14:14:13 -0000 >> #define IOCTL_GET_B _IOWR("F", 127, 0x4) > >I think the third parameter to _IOWR should directly specify a type, >e.g. _IOWR("F", 127, int) or _IOWR("F", 127, struct MyStruct). > >> >> ---- driver ---- >> >> struct my_softc { >> ... >> short unsigned int B; >> }; >> >> ... >> >> static int >> my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, >> struct thread *td) >> { >> struct my_softc *my_sc; >> int unit, error; >> unit = minor(dev); >> my_sc = (struct my_softc *)devclass_get_softc(my_devclass, unit); >> if (my_sc == NULL) >> return (ENXIO); >> switch(cmd) >> { >> ... >> case IOCTL_GET_B: >> error = copyout(&my_sc->B, data, sizeof(my_sc->B)); >> switch (error) >> { >> case 0: >> printf(" IOCTL_GET_B: %d\n", my_sc->B); >> break; >> case EFAULT: >> printf("EFAULT\n"); >> break; >> case EIO: >> printf("EIO\n"); >> break; >> case ENOMEM: >> printf("ENOMEM\n"); >> break; >> case ENOSPC: >> printf("ENOSPC\n"); >> break; >> } >> break; >> default: >> break; >> } >> return 0; >> } >> >> ---user program ---------------------- >> >> ... >> >> short unsigned int Data[32768]; >> >> int >> main(int argc, char *argv[]) >> { ... >> >> if (ioctl(fd0, IOCTL_GET_B, Data) == -1) >> err(1, "IOCTL_GET_B"); >> >> ... >> } >> >> ------- >> >> Here I get EFAULT. >> >> What have I done wrong? How can I do it correctly? > >The caddr_t data in your ioctl is already mapped into kernel >memory. Look into the source of other device drivers. You'll >find a lot of *(int *) data = ... >So your copyout() has to fail because it tries to address >memory which is not a part of your application's >memory. >>From errno(2): EFAULT: Bad address... > >I have no idea if it is possible for ioctls to have mapped more >than a few 100 bytes for data exchange. >You should use read and uiomove() instead. So if I get it right, it's impossible in FreeBSD to gain access to 64KB of user's program memory with ioctl? My situation is this - I have a device driver for Linux. My task is port it as it is (1:1) into FreeBSD. In the Linux driver Ioctl is realized with the macroses _put_user _get_user all over it. As I understand in FreeBSD their analogues are functions described in store(9), copy(9) and fetch(9). So the problem is that in my user program an array short unsigned int Data[32768] is defined. I need to gain access to the array(to each element of it) from device driver with Ioctl handler. Is it possible to do? If yes, then how it can be done? > >Norbert >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- çÄÅ ñÎÄÅËÓ.äÅÎØÇÉ - ÔÁÍ ÈÏÒÏÛÉÅ ÓËÉÄËÉ http://money.yandex.ru/discount/ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 14:27:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EAEFA16A420 for ; Mon, 25 Jul 2005 14:27:52 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B22043D55 for ; Mon, 25 Jul 2005 14:27:51 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j6PERjhc021926; Mon, 25 Jul 2005 17:27:46 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j6PERjPO026932; Mon, 25 Jul 2005 17:27:45 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j6PERjCJ026931; Mon, 25 Jul 2005 17:27:45 +0300 (EEST) Date: Mon, 25 Jul 2005 17:27:45 +0300 From: Giorgos Keramidas To: Felix-KM Message-ID: <20050725142745.GA26647@beatrix.daedalusnetworks.priv> References: <000101c5911b$62441260$4801a8c0@ws-ew-3.W2KDEMIG> <42E4F3AD.000001.28235@colgate.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E4F3AD.000001.28235@colgate.yandex.ru> Cc: NKoch@demig.de, freebsd-hackers@freebsd.org Subject: Re: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 14:27:53 -0000 On 2005-07-25 18:14, Felix-KM wrote: > >I have no idea if it is possible for ioctls to have mapped more than > >a few 100 bytes for data exchange. You should use read and uiomove() > >instead. > > So if I get it right, it's impossible in FreeBSD to gain access to > 64KB of user's program memory with ioctl? > > My situation is this - I have a device driver for Linux. My task is > port it as it is (1:1) into FreeBSD. > > In the Linux driver Ioctl is realized with the macroses _put_user > _get_user all over it. As I understand in FreeBSD their analogues are > functions described in store(9), copy(9) and fetch(9). > > So the problem is that in my user program an array short unsigned int > Data[32768] is defined. I need to gain access to the array(to each > element of it) from device driver with Ioctl handler. > > Is it possible to do? If yes, then how it can be done? A better alternative that doesn't involve copying huge amounts of data from userlevel to kernel space and vice versa is probably to pass just the address of the area with an ioctl() and then map the appropriate pages from the address space of the user process to an area where the kernel can access the data directly? From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 15:01:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 19C4C16A41F; Mon, 25 Jul 2005 15:01:39 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id A38C143D5D; Mon, 25 Jul 2005 15:01:36 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id D13D38C1C1; Mon, 25 Jul 2005 17:01:33 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23255-10; Mon, 25 Jul 2005 17:01:29 +0200 (CEST) Received: from firewall.demig (p50839592.dip0.t-ipconnect.de [80.131.149.146]) by server.absolute-media.de (Postfix) with ESMTP id 058DD8B933; Mon, 25 Jul 2005 17:01:28 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j6PEwtnY040780; Mon, 25 Jul 2005 16:58:55 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Giorgos Keramidas" , "Felix-KM" Date: Mon, 25 Jul 2005 16:58:55 +0200 Message-ID: <000001c59129$6099b560$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <20050725142745.GA26647@beatrix.daedalusnetworks.priv> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: freebsd-hackers@freebsd.org Subject: RE: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 15:01:39 -0000 > > > So if I get it right, it's impossible in FreeBSD to gain access to > > 64KB of user's program memory with ioctl? > > > > My situation is this - I have a device driver for Linux. My task is > > port it as it is (1:1) into FreeBSD. > > > > In the Linux driver Ioctl is realized with the macroses _put_user > > _get_user all over it. As I understand in FreeBSD their analogues are > > functions described in store(9), copy(9) and fetch(9). > > > > So the problem is that in my user program an array short unsigned int > > Data[32768] is defined. I need to gain access to the array(to each > > element of it) from device driver with Ioctl handler. > > > > Is it possible to do? If yes, then how it can be done? > > A better alternative that doesn't involve copying huge amounts of data > from userlevel to kernel space and vice versa is probably to pass just > the address of the area with an ioctl() and then map the appropriate > pages from the address space of the user process to an area where the > kernel can access the data directly? I think that could work (only an idea, not tested): struct Region { void * p; size_t s; }; #define IOBIG _IOWR ('b', 123, struct Region) userland: char data[1000]; struct Region r; r.p = data; r.s = sizeof data; int error = ioctl (fd, IOBIG, &r); kernel: int my_ioctl(..., caddr_t data, ...) { ... char data[1000]; ... return copyout(data, ((struct Region *) data)->p, ((struct Region *) data)->s); } Have a try and tell us if it works. Norbert From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 15:06:27 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG 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 D5DF316A41F for ; Mon, 25 Jul 2005 15:06:27 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA15343D48 for ; Mon, 25 Jul 2005 15:06:25 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [69.17.104.113]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j6PF6JnU031084; Mon, 25 Jul 2005 11:06:22 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Mon, 25 Jul 2005 11:06:19 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Felix-KM In-Reply-To: <42E4F3AD.000001.28235@colgate.yandex.ru> Message-ID: <20050725110347.W21555@sasami.jurai.net> References: <000101c5911b$62441260$4801a8c0@ws-ew-3.W2KDEMIG> <42E4F3AD.000001.28235@colgate.yandex.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [69.17.104.113]); Mon, 25 Jul 2005 11:06:22 -0400 (EDT) Cc: NKoch@demig.de, freebsd-hackers@FreeBSD.ORG Subject: RE: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 15:06:28 -0000 On Mon, 25 Jul 2005, Felix-KM wrote: > In the Linux driver Ioctl is realized with the macroses _put_user > _get_user all over it. As I understand in FreeBSD their analogues are > functions described in store(9), copy(9) and fetch(9). Linux doesn't provide any help for driver IOCTL routines, FreeBSD does. Just declare your IOCTLs correctly and the kernel will perform any copy in/out as specified by the _IOW/_IOR/_IOWR macros. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 15:55:56 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 48D5016A420 for ; Mon, 25 Jul 2005 15:55:56 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id B000B43D48 for ; Mon, 25 Jul 2005 15:55:53 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from stevenp4 ([193.123.241.40]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.3.R) with ESMTP id md50001713586.msg for ; Mon, 25 Jul 2005 16:48:59 +0100 Message-ID: <00be01c59131$345ca900$7f06000a@int.mediasurface.com> From: "Steven Hartland" To: "Leubner, Achim" , "David Okeby" References: Date: Mon, 25 Jul 2005 16:54:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Mon, 25 Jul 2005 16:48:59 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 193.123.241.40 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Mon, 25 Jul 2005 16:49:00 +0100 Cc: freebsd-hackers@freebsd.org Subject: Re: aac_pci.c Patch (support for HP ML110 G2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 15:55:56 -0000 Thanks for that we have ~40 new supermicro's with new Adaptec SATA controller's which we currently have to use windows on due to lack of 5.4 support. So this is very good news for us. Steve ----- Original Message ----- From: "Leubner, Achim" Our plan is to integrate the patch into the 6.0-CURRENT and to make driver update packages for 5.3/5.4 to support the new controllers on these OS versions too. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 20:06:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E23D416A41F for ; Mon, 25 Jul 2005 20:06:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB9A43D46 for ; Mon, 25 Jul 2005 20:06:37 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id D46944CE7D3; Mon, 25 Jul 2005 13:06:36 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96654-05; Mon, 25 Jul 2005 13:06:34 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by postoffice.vicor-nb.com (Postfix) with ESMTP id BF7124CE7FF; Mon, 25 Jul 2005 13:06:34 -0700 (PDT) Message-ID: <42E5464A.6070001@elischer.org> Date: Mon, 25 Jul 2005 13:06:34 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: Felix-KM@yandex.ru References: <000101c5911b$62441260$4801a8c0@ws-ew-3.W2KDEMIG> <42E4F3AD.000001.28235@colgate.yandex.ru> In-Reply-To: <42E4F3AD.000001.28235@colgate.yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: NKoch@demig.de, freebsd-hackers@freebsd.org Subject: Re: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 20:06:39 -0000 Felix-KM wrote: >>>#define IOCTL_GET_B _IOWR("F", 127, 0x4) >>> >>> >>I think the third parameter to _IOWR should directly specify a type, >>e.g. _IOWR("F", 127, int) or _IOWR("F", 127, struct MyStruct). >> >> >> >>>---- driver ---- >>> >>>struct my_softc { >>> ... >>> short unsigned int B; >>>}; >>> >>>... >>> >>>static int >>>my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, >>> struct thread *td) >>>{ >>> struct my_softc *my_sc; >>> int unit, error; >>> unit = minor(dev); >>> my_sc = (struct my_softc *)devclass_get_softc(my_devclass, unit); >>> if (my_sc == NULL) >>> return (ENXIO); >>> switch(cmd) >>> { >>> ... >>> case IOCTL_GET_B: >>> error = copyout(&my_sc->B, data, sizeof(my_sc->B)); >>> switch (error) >>> { >>> case 0: >>> printf(" IOCTL_GET_B: %d\n", my_sc->B); >>> break; >>> case EFAULT: >>> printf("EFAULT\n"); >>> break; >>> case EIO: >>> printf("EIO\n"); >>> break; >>> case ENOMEM: >>> printf("ENOMEM\n"); >>> break; >>> case ENOSPC: >>> printf("ENOSPC\n"); >>> break; >>> } >>> break; >>> default: >>> break; >>> } >>> return 0; >>>} >>> >>>---user program ---------------------- >>> >>>... >>> >>>short unsigned int Data[32768]; >>> >>>int >>>main(int argc, char *argv[]) >>>{ ... >>> >>> if (ioctl(fd0, IOCTL_GET_B, Data) == -1) >>> err(1, "IOCTL_GET_B"); >>> >>> ... >>>} >>> >>>------- >>> >>>Here I get EFAULT. >>> >>>What have I done wrong? How can I do it correctly? >>> >>> >>The caddr_t data in your ioctl is already mapped into kernel >>memory. Look into the source of other device drivers. You'll >>find a lot of *(int *) data = ... >>So your copyout() has to fail because it tries to address >>memory which is not a part of your application's >>memory. >>>From errno(2): EFAULT: Bad address... >> >>I have no idea if it is possible for ioctls to have mapped more >>than a few 100 bytes for data exchange. >>You should use read and uiomove() instead. >> >> > >So if I get it right, it's impossible in FreeBSD to gain access to 64KB of user's program memory with ioctl? > > no you do not get it right. you should pass in a pointer to your 64k object. ioccom.h describes the definition of the ioctl name. this includes: #define IOCPARM_MASK 0x1fff /* parameter length, at most 13 bits */ so the maximum that the system will AUTOMATICALLY COPYIN() is 8k For larger amounts you can always have the address as teh parameter and do the copyin yourself. in other words the automatically moved data would be only a smal structure specifying address and size, and you would use those parameters to copyin the larger structure. >My situation is this - I have a device driver for Linux. My task is port it as it is (1:1) into FreeBSD. > >In the Linux driver Ioctl is realized with the macroses _put_user _get_user all over it. As I understand in FreeBSD their analogues are functions described in store(9), copy(9) and fetch(9). > >So the problem is that in my user program an array short unsigned int Data[32768] is defined. I need to gain access to the array(to each element of it) from device driver with Ioctl handler. > >Is it possible to do? If yes, then how it can be done? > > > > >>Norbert >>_______________________________________________ >>freebsd-hackers@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >> > > > > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 23:14:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 15E0916A41F for ; Mon, 25 Jul 2005 23:14:49 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C7C443D53 for ; Mon, 25 Jul 2005 23:14:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6PNN8O5087172; Mon, 25 Jul 2005 17:23:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E57224.4090800@samsco.org> Date: Mon, 25 Jul 2005 17:13:40 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kamalp@acm.org References: <20050725130528.59033.qmail@web52709.mail.yahoo.com> In-Reply-To: <20050725130528.59033.qmail@web52709.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Felix-KM@yandex.ru, freebsd-hackers@freebsd.org Subject: Re: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 23:14:49 -0000 Kamal R. Prasad wrote: > Im not sure of the bug in your code, but you have got > to assume that copyout() would fail if the user/kernel > addr passed to it is not accessible. > > regards > -kamal > The whole point of copyin and copyout is to deal with copying to and from user virtual memory that might not be paged in at the moment. Your statement thus makes little sense. Scott From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 23:15:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 814B116A41F; Mon, 25 Jul 2005 23:15:49 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1181143D45; Mon, 25 Jul 2005 23:15:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6PNPBUO087185; Mon, 25 Jul 2005 17:25:11 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E5729F.1000800@samsco.org> Date: Mon, 25 Jul 2005 17:15:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <000101c5911b$62441260$4801a8c0@ws-ew-3.W2KDEMIG> <42E4F3AD.000001.28235@colgate.yandex.ru> <20050725142745.GA26647@beatrix.daedalusnetworks.priv> In-Reply-To: <20050725142745.GA26647@beatrix.daedalusnetworks.priv> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: NKoch@demig.de, Felix-KM , freebsd-hackers@freebsd.org Subject: Re: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 23:15:49 -0000 Giorgos Keramidas wrote: > On 2005-07-25 18:14, Felix-KM wrote: > >>>I have no idea if it is possible for ioctls to have mapped more than >>>a few 100 bytes for data exchange. You should use read and uiomove() >>>instead. >> >>So if I get it right, it's impossible in FreeBSD to gain access to >>64KB of user's program memory with ioctl? >> >>My situation is this - I have a device driver for Linux. My task is >>port it as it is (1:1) into FreeBSD. >> >>In the Linux driver Ioctl is realized with the macroses _put_user >>_get_user all over it. As I understand in FreeBSD their analogues are >>functions described in store(9), copy(9) and fetch(9). >> >>So the problem is that in my user program an array short unsigned int >>Data[32768] is defined. I need to gain access to the array(to each >>element of it) from device driver with Ioctl handler. >> >>Is it possible to do? If yes, then how it can be done? > > > A better alternative that doesn't involve copying huge amounts of data > from userlevel to kernel space and vice versa is probably to pass just > the address of the area with an ioctl() and then map the appropriate > pages from the address space of the user process to an area where the > kernel can access the data directly? > The kernel can see all of the user address space already, assuming that it's operating in the same process context as the user application (i.e. you haven't defered the ioctl call to a kthread, which is not normally the case). Mapping isn't the problem. Scott From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 25 23:42:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 ECA1E16A41F for ; Mon, 25 Jul 2005 23:42:37 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F63043D45 for ; Mon, 25 Jul 2005 23:42:33 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6PNpxHQ087304; Mon, 25 Jul 2005 17:52:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E578E7.7050307@samsco.org> Date: Mon, 25 Jul 2005 17:42:31 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felix-KM@yandex.ru References: <42E4DC88.000006.21996@camay.yandex.ru> In-Reply-To: <42E4DC88.000006.21996@camay.yandex.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2005 23:42:38 -0000 Felix-KM wrote: > I can't understand how to use the function copyout(). > It is necessary to write the data from a device driver to the > array defined in user program. > I do it this way: > > #define IOCTL_GET_B _IOWR("F", 127, 0x4) > What you've declared here is an ioctl that will copy in 4 bytes of user data on entry, and copy out 4 bytes back out on exit. The argument that you supply to the ioctl(2) must be a pointer to a 4 byte word that you want to copy. This probably isn't what you want. Based on your code snippets, you want: #define IOCTL_GET_B _IOW("F", 127, unsigned short) static int my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread *td) { unsigned short data; [...] case IOCTL_GET_B: *(unsigned short *)arg = data; break; [...] Similar code will work for all integral types, as well as simple structures. The generic ioctl layer will handle all of the copying magic for you. Copying compound structures (ones that have pointers to other data that you also want to copy) require explicit copyin or copyout operations on the pointers that are embedded into the struct. Likewise, copying arbitrary data that isn't a structure or integral type (like an array) also requires an explicit copy operation. You could do something like the following: struct mysubdata { int foo; int bar; }; struct mystruct { struct mysubdata *msd; }; #define IOCTL_SET_COMPOUNT_STRUCT _IOR("F", 123, struct mystruct) #define IOCTL_SET_BIGDATA _IO("F", 124") static int my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread *td) { struct mystruct *ms; struct mysubdata msd; char *bigdata *bd; [...] case IOCTL_SET_COMPOUNT_STRUCT: ms = *(struct mystruct *)arg; copyin(ms->msd, &msd, sizeof(struct mysubdata)); break; case IOCTL_SET_BIGDATA: bd = malloc(65536, M_DEVBUF, M_WAITOK); copyin(arg, bd, 65536); break; [...] Note that the BIGDATA ioctl doesn't copy in anything on its own. For ioctls like this, it's often convenient to pass a structure anyway that contains the size of the data to be copied in and a pointer to the data, like so: struct mybigdata { int datasize; char *bigdata; } #define IOCTL_SET_BIGDATA _IOR("B", 123, struct mybigdata) case IOCTL_GET_BIGDATA: mbd = *(struct mybigdata *)arg; bd = malloc(mbd->datasize, M_DEVBUF, M_WAITOK); copyin(mbd->bigdata, bd, mbd->datasize); break; Does this make sense? Fell free to contact me with questions on this or anything else. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 00:14:22 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 49A9416A41F for ; Tue, 26 Jul 2005 00:14:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE6AE43D45 for ; Tue, 26 Jul 2005 00:14:21 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6Q0Nlb7087416; Mon, 25 Jul 2005 18:23:48 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E5804D.4030206@samsco.org> Date: Mon, 25 Jul 2005 18:14:05 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felix-KM@yandex.ru References: <42E4DC88.000006.21996@camay.yandex.ru> <42E578E7.7050307@samsco.org> In-Reply-To: <42E578E7.7050307@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 00:14:22 -0000 Scott Long wrote: > Felix-KM wrote: > >> I can't understand how to use the function copyout(). >> It is necessary to write the data from a device driver to the >> array defined in user program. >> I do it this way: >> >> #define IOCTL_GET_B _IOWR("F", 127, 0x4) >> > > What you've declared here is an ioctl that will copy in 4 bytes of > user data on entry, and copy out 4 bytes back out on exit. The argument > that you supply to the ioctl(2) must be a pointer to a 4 byte word that > you want to copy. This probably isn't what you want. Based on your > code snippets, you want: > > #define IOCTL_GET_B _IOW("F", 127, unsigned short) > > static int my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int > flag, struct thread *td) > { > unsigned short data; > [...] > > case IOCTL_GET_B: > *(unsigned short *)arg = data; > break; > [...] > > > Similar code will work for all integral types, as well as simple > structures. The generic ioctl layer will handle all of the copying > magic for you. Copying compound structures (ones that have pointers > to other data that you also want to copy) require explicit copyin > or copyout operations on the pointers that are embedded into the > struct. Likewise, copying arbitrary data that isn't a structure or > integral type (like an array) also requires an explicit copy operation. > You could do something like the following: > > struct mysubdata { > int foo; > int bar; > }; > > struct mystruct { > struct mysubdata *msd; > }; > > #define IOCTL_SET_COMPOUNT_STRUCT _IOR("F", 123, struct mystruct) > #define IOCTL_SET_BIGDATA _IO("F", 124") > > static int my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int > flag, struct thread *td) > { > struct mystruct *ms; > struct mysubdata msd; > char *bigdata *bd; > > [...] > > case IOCTL_SET_COMPOUNT_STRUCT: > ms = *(struct mystruct *)arg; > copyin(ms->msd, &msd, sizeof(struct mysubdata)); > break; > case IOCTL_SET_BIGDATA: > bd = malloc(65536, M_DEVBUF, M_WAITOK); > copyin(arg, bd, 65536); > break; > [...] > > > Note that the BIGDATA ioctl doesn't copy in anything on its own. For > ioctls like this, it's often convenient to pass a structure anyway that > contains the size of the data to be copied in and a pointer to the data, > like so: > > struct mybigdata { > int datasize; > char *bigdata; > } > > #define IOCTL_SET_BIGDATA _IOR("B", 123, struct mybigdata) > > case IOCTL_GET_BIGDATA: > mbd = *(struct mybigdata *)arg; > bd = malloc(mbd->datasize, M_DEVBUF, M_WAITOK); > copyin(mbd->bigdata, bd, mbd->datasize); > break; > > Does this make sense? Fell free to contact me with questions on this or > anything else. > > Scott > Oops, I made a small but important mistake in these examples. When you use _IOR or _IOW, the data argument passed to your routine will be a pointer (in kernel address space) to the data that you specified, not a pointer to a pointer. So in the above example, you'd do: mbd = (struct mybigdata *)arg; not: mbd = *(struct mybigdata *)arg; For integral types, you'd still do: data = *(unsigned short *)arg; For ioctls that are specified with merely _IO, the data argument is a pointer in user address space. Technically you could just use bcopy on this, but the physical pages backing that address might have been swapped out in between the time the syscall was started and the time that your handler got called. The whole point of copyin/copyout is to safely and transparently handle this situation. Sorry for the confusion. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 03:05:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7E5DE16A41F for ; Tue, 26 Jul 2005 03:05:35 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10A9943D45 for ; Tue, 26 Jul 2005 03:05:34 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so989219wri for ; Mon, 25 Jul 2005 20:05:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cPVVfcIOzfctptz85Nzw5L+lxBmH9oLQ5zcxBy0UbULuF4qqLVfXxjBAUWw4rY0ASlvTccexUwbE+7q+QYzEYiIeAe3WEtu8yNFD2hT5do36u320Oq2migU98tsNJHPf0nmqls/pPz9ynPhpF8Jw/dz6SPJoYYiIucln/WYwf1M= Received: by 10.54.69.12 with SMTP id r12mr2417796wra; Mon, 25 Jul 2005 20:05:34 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Mon, 25 Jul 2005 20:05:34 -0700 (PDT) Message-ID: Date: Mon, 25 Jul 2005 22:05:34 -0500 From: Sam Pierson To: David Malone In-Reply-To: <200507211647.aa79456@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200507211647.aa79456@salmon.maths.tcd.ie> Cc: FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Pierson List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 03:05:35 -0000 > OK - you can probably achieve that by setting the retry limit to > be 1, setting CWmin to be very small. However, you'll need to make > sure that both machines transmissions are synchronised to better > than 20us (which is no mean feat), otherwise carrier sense will > foil your plan! I just had a lengthy discussion with a couple of guys about the 802.11 protocol. One had said that the random delays inserted before=20 transmission was one of the *IFS delays (can't remember which now), and that it was a standard 802.11 number, not a random=20 delay. We all came to the same conclusion as this list, that we=20 have to set the transmission attempts to 1 and that CWmin must be very small (like 1). =20 The thing he said was that if carrier sensing "sensed" that the channel was busy, it would not decrement the CW, effectively NOT transmitting this packet until the channel is clear. =20 Is the carrier sensing something done in the HAL, or is it embedded in the hardware itself? From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 07:46:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 489B116A41F for ; Tue, 26 Jul 2005 07:46:31 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from colgate.yandex.ru (colgate.yandex.ru [213.180.200.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB9D443D45 for ; Tue, 26 Jul 2005 07:46:30 +0000 (GMT) (envelope-from Felix-KM@yandex.ru) Received: from YAMAIL (colgate.yandex.ru) by mail.yandex.ru id ; Tue, 26 Jul 2005 11:46:23 +0400 Date: Tue, 26 Jul 2005 11:46:23 +0400 (MSD) From: "Felix-KM" Sender: Felix-KM@yandex.ru Message-Id: <42E5EA4F.00000A.07557@colgate.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: Felix-KM@yandex.ru To: NKoch@demig.de In-Reply-To: <000001c59129$6099b560$4801a8c0@ws-ew-3.W2KDEMIG> References: <000001c59129$6099b560$4801a8c0@ws-ew-3.W2KDEMIG> X-Source-Ip: 82.179.191.126 X-Originating-Ip: unknown Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: RE: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Felix-KM@yandex.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 07:46:31 -0000 > I think that could work (only an idea, not tested): > > > struct Region > { > void * p; > size_t s; > }; > > > #define IOBIG _IOWR ('b', 123, struct Region) > > > userland: > > char data[1000]; > struct Region r; > > r.p = data; > r.s = sizeof data; > int error = ioctl (fd, IOBIG, &r); > > > kernel: > int my_ioctl(..., caddr_t data, ...) > { > ... > char data[1000]; > ... > return copyout(data, ((struct Region *) data)->p, ((struct Region *) > data)->s); > } > > > Have a try and tell us if it works. > > > Norbert > Yes! Now the program works! I have changed the code in this way: struct Region { void * p; size_t s; }; #define IOBIG _IOWR ('b', 123, struct Region) ---- driver ---- struct my_softc { ... short unsigned int B; }; ... static int my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread *td) { struct my_softc *my_sc; int unit, error; unit = minor(dev); my_sc = (struct my_softc *)devclass_get_softc(my_devclass, unit); if (my_sc == NULL) return (ENXIO); switch(cmd) { ... case IOCTL_GET_B: error = copyout(&my_sc->B, (((struct Datas *)data)->d)+0x1850, sizeof(my_sc->B)); break; default: break; } return 0; } ---user program ---------------------- ... short unsigned int data[32768]; struct Region r; int main(int argc, char *argv[]) { ... r.p = data; r.s = sizeof data; if (ioctl(fd0, IOCTL_GET_B, &r) == -1) err(1, "IOCTL_GET_B"); ... } Now I have access to each element of the array (e.g. 0x1850). Thank you very much! From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 09:04:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1FAFC16A41F for ; Tue, 26 Jul 2005 09:04:44 +0000 (GMT) (envelope-from rink@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id B206E43D46 for ; Tue, 26 Jul 2005 09:04:43 +0000 (GMT) (envelope-from rink@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 0BCFDA2FF3; Tue, 26 Jul 2005 11:04:42 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 1796) id ED24D6433; Tue, 26 Jul 2005 11:04:41 +0200 (CEST) Date: Tue, 26 Jul 2005 11:04:41 +0200 From: Rink Springer To: freebsd-hackers@freebsd.org Message-ID: <20050726090441.GA77383@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline X-Editor: Vim http://www.vim.org/ X-Info: http://rink.nu/ X-Operating-System: FreeBSD 5.4-STABLE amd64 User-Agent: Mutt/1.5.9i Cc: xbox-linux-devel@lists.sourceforge.net, ed@fxq.nl Subject: FreeBSD ported to the XBox! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 09:04:44 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, Over the last 2 weeks, I have been working on a port of FreeBSD for the XBox. During this effort, Ed Schouten has given me assistance by reviewing patches and giving advice. The port is fully functional. The framebuffer is fully supported, same goes for sound and USB devices (such as an USB keyboard for the console). Only ethernet is missing, currently, as the binary only driver in /usr/ports/net/nvnet fails with an error 5, for some reason. Assistance there would be very welcome. I have made patches for FreeBSD 5.4-RELEASE and FreeBSD 6.0-BETA1. Currently, the port requires the Linux Cromwell BIOS (which was patched so it would understand FreeBSD kernel ELF files). More information on the patch can be found in the mail archives of xbox-linux, at http://sourceforge.net/mailarchive/forum.php?thread_id=3D7815806&forum_id= =3D9486. You will need the latest CVS version for it to work, or 2.40 + patches (patches can be found at the URL above) Also, a live CD has been created, which has 4 kernels: a 5.4-RELEASE and 6.0-BETA1 patched kernel with /dev/acd0 and /dev/ad0s1a root devices, a patched Cromwell BIOS (which you can load from a normal Cromwell BIOS), as well as the base installation files and kernel patches; as the framebuff= er driver isn't ready enough yet to provide proper ANSI support, installation should be done manually. The project's results (including patches, todo items etc) can be found at http://nexus.il.fontys.nl/ and http://freebsd.ilse.nl/xbox/. The patches are available there, including a BitTorrent file of the LiveCD (which is about 200MB). As the patches are so minimal (about 1000 lines, including sample kernel config), I hope they will be considered for 6.x-RELEASE or HEAD, as they can easily be integrated on a i386 CD without hurting anything. I would be happy to help with this effort. --=20 Rink P.W. Springer - http://rink.nu "God, root, what is difference?" - Pitr, Userfriendly --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC5fypb3O60uztv/8RAgApAKDHDJbHx4OFMq3R/azn1c/2HvXn9ACeIBlH W0HZUUm579OGpOxb1HLxk8Q= =aMNu -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 09:36:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B5D6A16A41F for ; Tue, 26 Jul 2005 09:36:42 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4620943D48 for ; Tue, 26 Jul 2005 09:36:42 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id AE6B58BCE5 for ; Tue, 26 Jul 2005 11:36:40 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03440-10 for ; Tue, 26 Jul 2005 11:36:36 +0200 (CEST) Received: from firewall.demig (p5083905E.dip0.t-ipconnect.de [80.131.144.94]) by server.absolute-media.de (Postfix) with ESMTP id DA87888B50 for ; Tue, 26 Jul 2005 11:36:35 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j6Q9YCL9003638 for ; Tue, 26 Jul 2005 11:34:12 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Freebsd-Hackers@Freebsd. Org" Date: Tue, 26 Jul 2005 11:34:11 +0200 Message-ID: <000001c591c5$2de9a980$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Subject: await & asleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 09:36:42 -0000 Hello. The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): "asleep (NULL, 0, NULL, 0)"? Any help appreciated. Norbert From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 14:13:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C1A7F16A41F for ; Tue, 26 Jul 2005 14:13:30 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id F033C43D48 for ; Tue, 26 Jul 2005 14:13:29 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 26 Jul 2005 15:13:28 +0100 (BST) To: Sam Pierson In-reply-to: Your message of "Mon, 25 Jul 2005 22:05:34 CDT." X-Request-Do: Date: Tue, 26 Jul 2005 15:13:27 +0100 From: David Malone Message-ID: <200507261513.aa10533@salmon.maths.tcd.ie> Cc: FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 14:13:30 -0000 > I just had a lengthy discussion with a couple of guys about the 802.11 > protocol. One had said that the random delays inserted before > transmission was one of the *IFS delays (can't remember which > now), and that it was a standard 802.11 number, not a random > delay. Yep - in 802.11b CWmin is fixed at 32 and the random number is chosen between 0 and CWmin-1 (unless you have a collision). The recent Atheros cards support adjusting CWmin as part of their WME/802.11e support. > The thing he said was that if carrier sensing "sensed" that the channel > was busy, it would not decrement the CW, effectively NOT transmitting > this packet until the channel is clear. That's correct, but it probably takes a few microseconds for the carries sense to kick in (if there wasn't a delay there would be almost no need for the random backoff). That's why you'll also have to have your transmissions synchronised very closely. > Is the carrier sensing something done in the HAL, or is it embedded > in the hardware itself? I'm afraid I don't know - Sam might. David. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 15:39:36 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B438016A41F for ; Tue, 26 Jul 2005 15:39:36 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32F7E43D49 for ; Tue, 26 Jul 2005 15:39:36 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6QFmqdY096268; Tue, 26 Jul 2005 09:48:53 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E65921.8060400@samsco.org> Date: Tue, 26 Jul 2005 09:39:13 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felix-KM@yandex.ru References: <000001c59129$6099b560$4801a8c0@ws-ew-3.W2KDEMIG> <42E5EA4F.00000A.07557@colgate.yandex.ru> In-Reply-To: <42E5EA4F.00000A.07557@colgate.yandex.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: NKoch@demig.de, freebsd-hackers@freebsd.org Subject: Re: how to use the function copyout() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 15:39:36 -0000 Felix-KM wrote: >>I think that could work (only an idea, not tested): >> >> >>struct Region >>{ >> void * p; >> size_t s; >>}; >> >> >>#define IOBIG _IOWR ('b', 123, struct Region) >> >> >>userland: >> >> char data[1000]; >> struct Region r; >> >> r.p = data; >> r.s = sizeof data; >> int error = ioctl (fd, IOBIG, &r); >> >> >>kernel: >> int my_ioctl(..., caddr_t data, ...) >> { >> ... >> char data[1000]; >> ... >> return copyout(data, ((struct Region *) data)->p, ((struct Region *) >>data)->s); >> } >> >> >>Have a try and tell us if it works. >> >> >>Norbert >> > > > Yes! Now the program works! > I have changed the code in this way: > > struct Region > { > void * p; > size_t s; > }; > > #define IOBIG _IOWR ('b', 123, struct Region) > Unless your ioctl handler is going to modify values in the Region struct and pass them back out to userland, you should just use _IOR instead of _IORW. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 15:45:59 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B5E3916A41F for ; Tue, 26 Jul 2005 15:45:59 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2452743D48 for ; Tue, 26 Jul 2005 15:45:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6QFtEgD096309; Tue, 26 Jul 2005 09:55:14 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E65A9F.4010504@samsco.org> Date: Tue, 26 Jul 2005 09:45:35 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norbert Koch References: <000001c591c5$2de9a980$4801a8c0@ws-ew-3.W2KDEMIG> In-Reply-To: <000001c591c5$2de9a980$4801a8c0@ws-ew-3.W2KDEMIG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: "Freebsd-Hackers@Freebsd. Org" Subject: Re: await & asleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 15:45:59 -0000 Norbert Koch wrote: > Hello. > > The functions await() and asleep() in kern_synch.c > are marked as EXPERIMENTAL/UNTESTED. > Is this comment still valid? Does anyone have used > those functions successfully? Should I better not > use them in my device driver code for RELENG_4? > How do I correctly cancel a request (as I should do > according to the man page): "asleep (NULL, 0, NULL, 0)"? > > Any help appreciated. > > Norbert The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 18:50:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7836B16A41F for ; Tue, 26 Jul 2005 18:50:23 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAF3A43D49 for ; Tue, 26 Jul 2005 18:50:20 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j6QIoIms067945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2005 11:50:20 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42E68733.5010502@errno.com> Date: Tue, 26 Jul 2005 11:55:47 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Malone References: <200507261513.aa10533@salmon.maths.tcd.ie> In-Reply-To: <200507261513.aa10533@salmon.maths.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Pierson , FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 18:50:23 -0000 David Malone wrote: >>I just had a lengthy discussion with a couple of guys about the 802.11 >>protocol. One had said that the random delays inserted before >>transmission was one of the *IFS delays (can't remember which >>now), and that it was a standard 802.11 number, not a random >>delay. > > > Yep - in 802.11b CWmin is fixed at 32 and the random number is > chosen between 0 and CWmin-1 (unless you have a collision). The > recent Atheros cards support adjusting CWmin as part of their > WME/802.11e support. Well "recent" is any 5212 or 5211 card so you're talking about any Atheros card except the 5210--which is not so recent. It may also be possible to program the 5210 but given how few of them are in use it's hardly worth the effort (and they'll never support WME). > > >>The thing he said was that if carrier sensing "sensed" that the channel >>was busy, it would not decrement the CW, effectively NOT transmitting >>this packet until the channel is clear. > > > That's correct, but it probably takes a few microseconds for the > carries sense to kick in (if there wasn't a delay there would > be almost no need for the random backoff). That's why you'll > also have to have your transmissions synchronised very closely. > > >>Is the carrier sensing something done in the HAL, or is it embedded >>in the hardware itself? > > > I'm afraid I don't know - Sam might. Hardware. Sam From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 22:43:43 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 484F316A41F for ; Tue, 26 Jul 2005 22:43:43 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id E180543D45 for ; Tue, 26 Jul 2005 22:43:42 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from [192.168.1.100] (rrcs-24-172-31-78.midsouth.biz.rr.com [24.172.31.78]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j6QMhdY4004904 for ; Tue, 26 Jul 2005 18:43:40 -0400 (EDT) Message-ID: <42E6BD5F.7020909@ec.rr.com> Date: Tue, 26 Jul 2005 18:46:55 -0400 From: jason henson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050426) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: using -ftracer stops buildworld at shutdown.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 22:43:43 -0000 Adding -ftracer to my make.conf causes problems with /src/sbin/shutdown/shutdown.c This is my make.conf settings CPUTYPE=athlon-xp CFLAGS=-O2 -pipe -ffast-math -funroll-loops -ftracer COPTFLAGES=-O2 -pipe -funroll-loops -ffast-math -ftracer Doing a little research I found these items: -ftracer Perform tail duplication to enlarge superblock size. This transformation simplifies the control flow of the function allowing other optimizations to do better job. Why do I get "warning: variable (or argument) `blah' might be clobbered by `longjmp' or `vfork'" and how do I fix it? When the C runtime executes a longjmp, the flow of control passes back to the last setjmp that was executed. In the process, the stack (which contains arguments and local variables) must be 'unwound', that is, returned to the exact same state that it was in when setjmp was executed. Unfortunately, due to optimizations such as storing the value of a variable in a register instead of on the stack, the compiler cannot always guarantee that the stack will be restored precisely to its original state. Thus some local variables and/or arguments can be 'clobbered'. To avoid this warning, the variables and/or arguments should be prevented from being optimized by declaring them as volatile. So I sprinkled some volatiles around, but mostly got more errors that said "gcc volatile discards qualifiers from pointer target type" in the fprintf functions. The error went away after I removed -ftracer, but from what I have read it would be advantageous to change the variable pf to be stored on the stack and not in a register. That is if it is not stored on the stack. I did a search of all the listed include files in shutdown.c and found no matches for pf. Anyone one have any thoughts or insights on this? Am I completely off in left field? Jason ===> sbin/shutdown (all) cc -O2 -pipe -DNOPROFILE -ffast-math -ftracer -funroll-loops -march=athlon-xp -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/sbin/shutdown/shutdown.c /usr/src/sbin/shutdown/shutdown.c: In function `timewarn': /usr/src/sbin/shutdown/shutdown.c:276: warning: variable 'pf' might be clobbered by `longjmp' or `vfork' *** Error code 1 Stop in /usr/src/sbin/shutdown. *** Error code 1 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 23:26:27 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 E6AE216A41F for ; Tue, 26 Jul 2005 23:26:27 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id B46FD43D53 for ; Tue, 26 Jul 2005 23:26:21 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id C6369322D6B for ; Wed, 27 Jul 2005 01:26:20 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 088C6405B; Wed, 27 Jul 2005 01:26:45 +0200 (CEST) Date: Wed, 27 Jul 2005 01:26:45 +0200 From: Jeremie Le Hen To: freebsd-hackers@FreeBSD.org Message-ID: <20050726232645.GN1610@obiwan.tataz.chchile.org> References: <20050705153933.GP73907@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050705153933.GP73907@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.9i Cc: Subject: Re: ProPolice symbols in libc or libssp ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 23:26:28 -0000 On Tue, Jul 05, 2005 at 05:39:33PM +0200, Jeremie Le Hen wrote: > Hi hackers, > > I'm still working on integrating the ProPolice patch in FreeBSD CURRENT. > A small reminder : > The ProPolice patch prevents from stack-based buffer overflows > but setting a canary between character arrays and the return > address stored in the stack. In addition, automatic variables > are reordered so that pointers stands before buffers. > > ProPolice (aka Stack Smashing Protector / SSP) needs two symbols to > work correctly ("__guard" which is the canary initialized before main() > is started, and "__stack_smash_handler" which is the function called > when a buffer overflow is detected ; furthermore, a private contructor > is provided to fill __guard). The original patch stores them in libgcc > but since FreeBSD only provides a static libgcc, this will lead to have > those compiled into all binaries, which is not something acceptable, IMO. > > Numerous patches porting ProPolice to newer versions of FreeBSD store > these symbols in libc, so they are dynamically linked. That's what I > did too and it worked quite well. > > However, Victor Balada Diaz tested the patch for me and reported that > it breaks Opera compiled for RELENG_4 because the latter is linked > against libc (compat one) and libz. The problem is that the libz > version against which Opera is dynamically linked is not residing in > compat/ and _needs_ ProPolice symbols which are obviously not in the > compat libc. > > Another solution taht exists, the one used by the Hardened Debian > project, is to have a libssp containing these two symbols. I implemented libssp to circumvent the above problem without thinking that, in fact, this would not help at all. Binaries compiled for older FreeBSD branches (such as RELENG_4) won't indeed be linked against libssp anyway :). If someone who has the ProPolice patch installed (and on by default) compiles ports/misc/compat4x, the latter will be protected and will therefore require __guard and __stack_smash_handler symbols. However since the older binary will have not been linked against libssp, the symbols won't be found. In fact, the same thing will happen too for native binaries that have been built before the ProPolice patch being applied on the source tree. Being full of enthusiasm, I checked if by chance libraries could have dynamic object dependencies. It appears this is not the case, but since I'm neither a GCC nor binutils hacker, maybe there is a way to achieve this. This is the purpose of this email ? Is it possible to tell that a library needs other shared objects to run ? If yes, how do I do this ? Is there another way I didn't think about to circumvent this problem ? Advices are *very* welcome. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 00:02:54 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 AFDB716A41F for ; Wed, 27 Jul 2005 00:02:54 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32C1143D49 for ; Wed, 27 Jul 2005 00:02:54 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (storm.stura.uni-rostock.de [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 3E23235707 for ; Wed, 27 Jul 2005 02:02:52 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 1F969542E; Wed, 27 Jul 2005 02:00:55 +0200 (CEST) Date: Wed, 27 Jul 2005 02:00:54 +0200 From: Joerg Sonnenberger To: freebsd-hackers@FreeBSD.org Message-ID: <20050727000054.GA15018@britannica.bec.de> Mail-Followup-To: freebsd-hackers@FreeBSD.org References: <20050705153933.GP73907@obiwan.tataz.chchile.org> <20050726232645.GN1610@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050726232645.GN1610@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.6i Cc: Subject: Re: ProPolice symbols in libc or libssp ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 00:02:54 -0000 On Wed, Jul 27, 2005 at 01:26:45AM +0200, Jeremie Le Hen wrote: > Being full of enthusiasm, I checked if by chance libraries could have > dynamic object dependencies. It appears this is not the case, but > since I'm neither a GCC nor binutils hacker, maybe there is a way to > achieve this. This is the purpose of this email ? What you have been smoking? Dynamic libraries surely can depend on other objects :-) Just link libc with -lssp, given that libssp should be self-contained or any other library you want to have propolice in against ssp. Static libraries are not an issue either, since you can simply add the object file. If you look around, you might even find some programs which allow you to add the dependency into an existing library, which would be perfect for libc. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 05:32:08 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 9239216A41F for ; Wed, 27 Jul 2005 05:32:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21F8043D53 for ; Wed, 27 Jul 2005 05:32:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6R5VRtK011720; Tue, 26 Jul 2005 23:31:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 26 Jul 2005 23:32:27 -0600 (MDT) Message-Id: <20050726.233227.25163764.imp@bsdimp.com> To: rink@stack.nl From: "M. Warner Losh" In-Reply-To: <20050726090441.GA77383@stack.nl> References: <20050726090441.GA77383@stack.nl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, xbox-linux-devel@lists.sourceforge.net, ed@fxq.nl Subject: Re: FreeBSD ported to the XBox! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 05:32:08 -0000 In message: <20050726090441.GA77383@stack.nl> Rink Springer writes: : Over the last 2 weeks, I have been working on a port of FreeBSD for the : XBox. During this effort, Ed Schouten has given me assistance by : reviewing patches and giving advice. Way Cool! Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 06:51:46 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 4706C16A41F for ; Wed, 27 Jul 2005 06:51:46 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 988BA43D48 for ; Wed, 27 Jul 2005 06:51:45 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id A4F148C500; Wed, 27 Jul 2005 08:51:44 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27648-09; Wed, 27 Jul 2005 08:51:39 +0200 (CEST) Received: from firewall.demig (p50839235.dip0.t-ipconnect.de [80.131.146.53]) by server.absolute-media.de (Postfix) with ESMTP id 002C88C4FE; Wed, 27 Jul 2005 08:51:38 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j6R6mwFo068916; Wed, 27 Jul 2005 08:48:58 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Scott Long" Date: Wed, 27 Jul 2005 08:48:57 +0200 Message-ID: <001801c59277$432fd960$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <42E65A9F.4010504@samsco.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: "Freebsd-Hackers@Freebsd. Org" Subject: RE: await & asleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 06:51:46 -0000 > > The functions await() and asleep() in kern_synch.c > > are marked as EXPERIMENTAL/UNTESTED. > > Is this comment still valid? Does anyone have used > > those functions successfully? Should I better not > > use them in my device driver code for RELENG_4? > > How do I correctly cancel a request (as I should do > > according to the man page): "asleep (NULL, 0, NULL, 0)"? > > The await family was removed in 5.x and beyond, so trying to > use them in 4.x will make your driver very unportable. There > are better ways than await to handle delayed events. Ok, my [classical] situation is this: 1. an interrupt handler writes into a queue 2. a read function reading from the queue pseudo code using asleep()/await() (no error handling): read() { forever { while ! empty_queue() { uiomove(&uio, ...); if (uio->uio_resid == 0) { return 0; } } asleep(& read_queue, ...); if (empty_queue ()) { error = await (...); } else { asleep (NULL, ...); } } } If I want to do that with plain tsleep() I have to use spl??() to lock the empty_queue() call and not lose a wakeup() from the interrupt handler. But if I add error checks the code becomes very ugly compared to the solution above. I never wrote a driver under 5.X. As I understand I would use a mutex to access the queue and call msleep() to sleep with the mutex unlocked. (That seems to simulate pthread_cond_timedwait(), doesn't it?) pseudo code: read() { forever { while ! empty_queue() { uiomove(&uio, ...); if (uio->uio_resid == 0) { return 0; } } mtx_lock (&mutex); if (empty_queue ()) { error = msleep (&queue, &mutex, ...); }; mtx_unlock (&mutex); } } How would you suggest to do that under 4.X in an _elegant_ way w/o asleep/await? Norbert From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 13:02:18 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 90AD716A41F for ; Wed, 27 Jul 2005 13:02:18 +0000 (GMT) (envelope-from loader@freebsdmall.com) Received: from mail.freebsdmall.com (ns1.freebsdmall.com [69.50.233.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B3FB43D86 for ; Wed, 27 Jul 2005 13:02:18 +0000 (GMT) (envelope-from loader@freebsdmall.com) Received: by mail.freebsdmall.com (Postfix, from userid 2136) id 2A90F1CE5C; Wed, 27 Jul 2005 06:02:18 -0700 (PDT) X-Mailer: emacs 22.0.50.1 (via feedmail 8 I) To: Rink Springer References: <20050726090441.GA77383@stack.nl> From: loader X-GPG-Public-Key: http://www.freebsdmall.com/~loader/loader.asc X-GPG-Key-ID: 1024D/0277E075 X-GPG-Key-Fingerprint: F8A0 A354 5D97 B175 7FC9 15DC 0771 07CF 0277 E075 Date: Wed, 27 Jul 2005 21:20:47 +0000 In-Reply-To: <20050726090441.GA77383@stack.nl> (Rink Springer's message of "Tue, 26 Jul 2005 11:04:41 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org, xbox-linux-devel@lists.sourceforge.net, ed@fxq.nl Subject: Re: FreeBSD ported to the XBox! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 13:02:18 -0000 Rink Springer writes: > Hello everyone, > > Over the last 2 weeks, I have been working on a port of FreeBSD for the > XBox. During this effort, Ed Schouten has given me assistance by > reviewing patches and giving advice. > Great, thanks for your work. I got my XBOX with an Aladdin modchip. Today I downloaded the LiveCD and tried to boot from it, but failed. (I don't have the Cromwell BIOS installed on my XBOX ). Then I booted XBOX with GentooX install CD (Home edition), and replaced GentooX CD with FreeBSD XBOX live CD after it booted into GentooX Loader, selected CD option, then the XBOX was try to boot from it, I can see there's four choices (FreeBSD 5.4 ... CD/HDD, FreeBSD 6.0-BETA1 ... CD/HDD). I tried all of them, it just stopped there, it didn't show any FreeBSD boot messages. Thank you for portting FreeBSD to XBOX. XD Regards, loader From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 13:31:50 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 1378016A420 for ; Wed, 27 Jul 2005 13:31:50 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from viefep12-int.chello.at (viefep12-int.chello.at [213.46.255.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13A6E43D53 for ; Wed, 27 Jul 2005 13:31:48 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at ([213.47.85.26]) by viefep12-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050727133146.RTLZ1672.viefep12-int.chello.at@wombat.fafoe.narf.at>; Wed, 27 Jul 2005 15:31:46 +0200 Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 84C98A3; Wed, 27 Jul 2005 15:31:35 +0200 (CEST) Date: Wed, 27 Jul 2005 15:31:35 +0200 From: Stefan Farfeleder To: jason henson Message-ID: <20050727133133.GA560@wombat.fafoe.narf.at> Mail-Followup-To: jason henson , hackers@freebsd.org References: <42E6BD5F.7020909@ec.rr.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <42E6BD5F.7020909@ec.rr.com> User-Agent: Mutt/1.5.9i Cc: hackers@freebsd.org Subject: Re: using -ftracer stops buildworld at shutdown.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 13:31:50 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 26, 2005 at 06:46:55PM -0400, jason henson wrote: > To avoid this warning, the variables and/or arguments should be > prevented from being optimized by declaring them as volatile. > > So I sprinkled some volatiles around, but mostly got more errors that > said "gcc volatile discards qualifiers from pointer target type" in the > fprintf functions. Replacing line 276 with 'FILE *volatile pf;' fixes the warning. But the usage of {long,set}jmp() is wrong anyway since timeout() can jump back into timewarn() while that isn't executed at all. Stefan --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="shutdown.c.diff" Index: shutdown.c =================================================================== RCS file: /home/ncvs/src/sbin/shutdown/shutdown.c,v retrieving revision 1.28 diff -I.svn -u -r1.28 shutdown.c --- shutdown.c 25 Jan 2005 08:40:51 -0000 1.28 +++ shutdown.c 27 Jul 2005 13:24:29 -0000 @@ -273,7 +273,7 @@ { static int first; static char hostname[MAXHOSTNAMELEN + 1]; - FILE *pf; + FILE *volatile pf; char wcmd[MAXPATHLEN + 4]; if (!first++) --6TrnltStXW4iwmi0-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 13:44:35 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 21D3F16A41F for ; Wed, 27 Jul 2005 13:44:35 +0000 (GMT) (envelope-from rink@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE39143D49 for ; Wed, 27 Jul 2005 13:44:34 +0000 (GMT) (envelope-from rink@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id A5E81A2FFC; Wed, 27 Jul 2005 15:44:32 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 1796) id 800F169BD; Wed, 27 Jul 2005 15:44:32 +0200 (CEST) Date: Wed, 27 Jul 2005 15:44:32 +0200 From: Rink Springer To: Ludvig Strigeus Message-ID: <20050727134432.GA10142@stack.nl> References: <4285cd45050727063146c054d4@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <4285cd45050727063146c054d4@mail.gmail.com> X-Editor: Vim http://www.vim.org/ X-Info: http://rink.nu/ X-Operating-System: FreeBSD 5.4-STABLE amd64 User-Agent: Mutt/1.5.9i Cc: hackers@freebsd.org, ed@fxq.nl Subject: Re: Problem with pic16l_setled X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 13:44:35 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ludvig, * Ludvig Strigeus (strigeus@gmail.com) wrote: > Hi! >=20 > I see this code: >=20 > +ENTRY(pic16l_setled) > + push %ebp > + mov %esp,%ebp > + > + movl 0x8(%ebp),%ebx > + orl $0x800,%ebx > + call pic16l_ledhlp > + movl $0x701,%ebx > + call pic16l_ledhlp > + > + leave > + ret >=20 > With the standard x86 calling convention, you're not supposed to > modify ebx, esi or edi without saving them first. Try adding a > push/pop ebx around. I doubt this is the problem (I've looked at other .s files like i386/i386/support.s, function ssdtosd, and they don't seem to do this). You see, in C, I call the function like this (for example): void pic16l_setled(unsigned int val); pic16l_setled (0x1234); And it gets assembled to: pushl $0x1234 call pic16l_setled But it should be assembled to: pushl $0x1234 call pic16l_setled add $4,%esp /* ditch the parameter */ I don't know why it doesn't do this :( > +ENTRY(pic16l_reboot) > + pushl $0x01 > + pushl $0x02 > + pushl $0x20 > + call pic16l_setbyte > + ret > > You're forgetting to adjust the stack here.. you should add 12 to esp > before returning. > Same thing in pic16l_poweroff. Indeed, very correct! Since there functions plainly reboot / halt, I never noticed this, but you are indeed correct. I'll fix it in a new patchset. > I've never done any FBSD dev, so i could be wrong...but it's worth a try. Thank you very much for your time! I've CC-ed this discussion to hackers@, perhaps someone knows more about this ? --=20 Rink P.W. Springer - http://rink.nu "God, root, what is difference?" - Pitr, Userfriendly --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC54/Ab3O60uztv/8RAhUJAKC+mqa+HBIpL7b1GGdU83BJ/2hlqgCgoDfm bLoynyNAnMhVLOzn6FRh2cQ= =7ilb -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 14:11:42 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 401BF16A420 for ; Wed, 27 Jul 2005 14:11:42 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id B112C43D46 for ; Wed, 27 Jul 2005 14:11:41 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id DDE548C7F9; Wed, 27 Jul 2005 16:11:38 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19582-01; Wed, 27 Jul 2005 16:11:34 +0200 (CEST) Received: from firewall.demig (p50839235.dip0.t-ipconnect.de [80.131.146.53]) by server.absolute-media.de (Postfix) with ESMTP id 17D4D8C34D; Wed, 27 Jul 2005 16:11:33 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j6RE9pSp064469; Wed, 27 Jul 2005 16:09:51 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Rink Springer" , "Ludvig Strigeus" Date: Wed, 27 Jul 2005 16:09:51 +0200 Message-ID: <000701c592b4$dadcd000$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20050727134432.GA10142@stack.nl> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: hackers@freebsd.org, ed@fxq.nl Subject: RE: Problem with pic16l_setled X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 14:11:42 -0000 > You see, in C, I call the function like this (for example): > > void pic16l_setled(unsigned int val); > pic16l_setled (0x1234); > > And it gets assembled to: > > pushl $0x1234 > call pic16l_setled > > But it should be assembled to: > > pushl $0x1234 > call pic16l_setled > add $4,%esp /* ditch the parameter */ Usually gcc collects stack cleanups. See -fno-defer-pop. Norbert From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 15:36:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 28C8616A41F for ; Wed, 27 Jul 2005 15:36:04 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C39CF43D62 for ; Wed, 27 Jul 2005 15:36:03 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j6RFZwmR009580; Wed, 27 Jul 2005 11:35:58 -0400 (EDT) Date: Wed, 27 Jul 2005 11:35:58 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Norbert Koch In-Reply-To: <001801c59277$432fd960$4801a8c0@ws-ew-3.W2KDEMIG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: "Freebsd-Hackers@Freebsd. Org" , Scott Long Subject: RE: await & asleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 15:36:04 -0000 On Wed, 27 Jul 2005, Norbert Koch wrote: > > > The functions await() and asleep() in kern_synch.c > > > are marked as EXPERIMENTAL/UNTESTED. > > > Is this comment still valid? Does anyone have used > > > those functions successfully? Should I better not > > > use them in my device driver code for RELENG_4? > > > How do I correctly cancel a request (as I should do > > > according to the man page): "asleep (NULL, 0, NULL, 0)"? > > > > The await family was removed in 5.x and beyond, so trying to > > use them in 4.x will make your driver very unportable. There > > are better ways than await to handle delayed events. Well, there's tsleep() and wakeup() for FreeBSD < 5.0. Other than that, what else can you do? These functions are deprecated in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should really use those instead of tsleep() and wakeup(). It seems the kernel in -current is still using tsleep() and wakeup() in some places. I thought we got rid of all these... -- DE From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 16:35:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 67F0916A41F; Wed, 27 Jul 2005 16:35:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8F5D43D45; Wed, 27 Jul 2005 16:35:27 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6RGiWgW007413; Wed, 27 Jul 2005 10:44:32 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E7B7B5.30708@samsco.org> Date: Wed, 27 Jul 2005 10:35:01 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Norbert Koch , "Freebsd-Hackers@Freebsd. Org" Subject: Re: await & asleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 16:35:28 -0000 Daniel Eischen wrote: > On Wed, 27 Jul 2005, Norbert Koch wrote: > > >>>>The functions await() and asleep() in kern_synch.c >>>>are marked as EXPERIMENTAL/UNTESTED. >>>>Is this comment still valid? Does anyone have used >>>>those functions successfully? Should I better not >>>>use them in my device driver code for RELENG_4? >>>>How do I correctly cancel a request (as I should do >>>>according to the man page): "asleep (NULL, 0, NULL, 0)"? >>> >>>The await family was removed in 5.x and beyond, so trying to >>>use them in 4.x will make your driver very unportable. There >>>are better ways than await to handle delayed events. > > > Well, there's tsleep() and wakeup() for FreeBSD < 5.0. Other > than that, what else can you do? These functions are deprecated > in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should > really use those instead of tsleep() and wakeup(). > > It seems the kernel in -current is still using tsleep() and > wakeup() in some places. I thought we got rid of all these... > ???? Can you explain why tsleep and wakeup should no longer be used? I wasn't aware that they were formally deprecated. Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 16:54:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7E80916A41F for ; Wed, 27 Jul 2005 16:54:54 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23BC343D49 for ; Wed, 27 Jul 2005 16:54:54 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j6RGs61D007205; Wed, 27 Jul 2005 12:54:08 -0400 (EDT) Date: Wed, 27 Jul 2005 12:54:06 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Scott Long In-Reply-To: <42E7B7B5.30708@samsco.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Norbert Koch , "Freebsd-Hackers@Freebsd. Org" Subject: Re: await & asleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 16:54:54 -0000 On Wed, 27 Jul 2005, Scott Long wrote: > Daniel Eischen wrote: > > On Wed, 27 Jul 2005, Norbert Koch wrote: > > > > > >>>>The functions await() and asleep() in kern_synch.c > >>>>are marked as EXPERIMENTAL/UNTESTED. > >>>>Is this comment still valid? Does anyone have used > >>>>those functions successfully? Should I better not > >>>>use them in my device driver code for RELENG_4? > >>>>How do I correctly cancel a request (as I should do > >>>>according to the man page): "asleep (NULL, 0, NULL, 0)"? > >>> > >>>The await family was removed in 5.x and beyond, so trying to > >>>use them in 4.x will make your driver very unportable. There > >>>are better ways than await to handle delayed events. > > > > > > Well, there's tsleep() and wakeup() for FreeBSD < 5.0. Other > > than that, what else can you do? These functions are deprecated > > in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should > > really use those instead of tsleep() and wakeup(). > > > > It seems the kernel in -current is still using tsleep() and > > wakeup() in some places. I thought we got rid of all these... > > > > ???? Can you explain why tsleep and wakeup should no longer be > used? I wasn't aware that they were formally deprecated. My mistake then. I thought they were deprecated when mutex and CVs were introduced. There is no need for them except for compatability, and the priority argument of tsleep() doesn't have any meaning any longer, right? -- DE From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 17:01:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 2305E16A438; Wed, 27 Jul 2005 17:01:15 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BA5543D58; Wed, 27 Jul 2005 17:01:14 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6RH9Pmt007525; Wed, 27 Jul 2005 11:09:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E7BD9F.6060401@samsco.org> Date: Wed, 27 Jul 2005 11:00:15 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Norbert Koch , "Freebsd-Hackers@Freebsd. Org" Subject: Re: await & asleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 17:01:15 -0000 Daniel Eischen wrote: > On Wed, 27 Jul 2005, Scott Long wrote: > > >>Daniel Eischen wrote: >> >>>On Wed, 27 Jul 2005, Norbert Koch wrote: >>> >>> >>> >>>>>>The functions await() and asleep() in kern_synch.c >>>>>>are marked as EXPERIMENTAL/UNTESTED. >>>>>>Is this comment still valid? Does anyone have used >>>>>>those functions successfully? Should I better not >>>>>>use them in my device driver code for RELENG_4? >>>>>>How do I correctly cancel a request (as I should do >>>>>>according to the man page): "asleep (NULL, 0, NULL, 0)"? >>>>> >>>>>The await family was removed in 5.x and beyond, so trying to >>>>>use them in 4.x will make your driver very unportable. There >>>>>are better ways than await to handle delayed events. >>> >>> >>>Well, there's tsleep() and wakeup() for FreeBSD < 5.0. Other >>>than that, what else can you do? These functions are deprecated >>>in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should >>>really use those instead of tsleep() and wakeup(). >>> >>>It seems the kernel in -current is still using tsleep() and >>>wakeup() in some places. I thought we got rid of all these... >>> >> >>???? Can you explain why tsleep and wakeup should no longer be >>used? I wasn't aware that they were formally deprecated. > > > My mistake then. I thought they were deprecated when mutex and > CVs were introduced. There is no need for them except for compatability, Incorrect. A mutex is not a replacement for sleep. CV's and semaphores implement some of what tsleep does, but tsleep is absolutely appropriate when you want to sleep for an event (like disk i/o completing) and don't need to worry about mutexes. Not every inch of the kernel needs to be covered by mutexes, Giant or otherwise. > and the priority argument of tsleep() doesn't have any meaning > any longer, right? > I thought it did, but John can give the definitive answer. Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 17:25:25 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 2699416A41F for ; Wed, 27 Jul 2005 17:25:25 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1FC543D55 for ; Wed, 27 Jul 2005 17:25:24 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j6RHPMxL007032; Wed, 27 Jul 2005 13:25:22 -0400 (EDT) Date: Wed, 27 Jul 2005 13:25:22 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Scott Long In-Reply-To: <42E7BD9F.6060401@samsco.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Norbert Koch , "Freebsd-Hackers@Freebsd. Org" Subject: Re: await & asleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 17:25:25 -0000 On Wed, 27 Jul 2005, Scott Long wrote: > Daniel Eischen wrote: > > > > > My mistake then. I thought they were deprecated when mutex and > > CVs were introduced. There is no need for them except for compatability, > > Incorrect. A mutex is not a replacement for sleep. CV's and semaphores > implement some of what tsleep does, but tsleep is absolutely appropriate > when you want to sleep for an event (like disk i/o completing) and don't > need to worry about mutexes. Not every inch of the kernel needs to be > covered by mutexes, Giant or otherwise. Traditionally, you did splXXX() then tsleep(). But splXXX() has been deprecated and you need to use mutexes for protection. If you are going to sleep for an event, that is cv_wait() and friends and you use the mutex for protection. It's hard to imagine that queueing disk I/O requests and their completions don't need mutexes (or lockmgr?) for protection, but I'll take your word for it. -- DE From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 20:05:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 22BCA16A41F for ; Wed, 27 Jul 2005 20:05:57 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 387A243D5E for ; Wed, 27 Jul 2005 20:05:54 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id i21so245372wra for ; Wed, 27 Jul 2005 13:05:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dQbVg48LnRs8OSuruoGsDQrS9fnWhkEDNSt4alM1yCxqMUNJZOS7XkGOjcn3L2gCkiRRS3o70hwZRmoUhA7m5J/CnLdBgBoYIvzVjhEuOCGNmytmoCQ94fEIDlazjRi43Laez2I1IwhbeY86Zo02eIqDSogfL9lax/IqGhlv3Fo= Received: by 10.54.67.8 with SMTP id p8mr472388wra; Wed, 27 Jul 2005 13:05:53 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Wed, 27 Jul 2005 13:05:53 -0700 (PDT) Message-ID: Date: Wed, 27 Jul 2005 15:05:53 -0500 From: Sam Pierson To: Sam Leffler In-Reply-To: <42E03E5B.80905@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200507211849.aa11934@salmon.maths.tcd.ie> <42E03E5B.80905@errno.com> Cc: David Malone , FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Pierson List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 20:05:57 -0000 On 7/21/05, Sam Leffler wrote: > You need to set cwmin on the tx q as David describes. Be sure to set > the parameters you set into the hardware; check the wme update code for > the correct logic. For the other thing just set the tx descriptor to do > 1 try. >=20 > Sam So like in ath_tx_start: =09ath_hal_setuptxdesc(ah, ds =09=09, pktlen=09=09/* packet length */ =09=09, hdrlen=09=09/* header length */ =09=09, atype=09=09=09/* Atheros packet type */ =09=09, ni->ni_txpower=09/* txpower */ -->=09 , txrate, 0=09=09/* series 0 rate/tries */ /* originally: txrate, try0 */ =09=09, keyix=09=09=09/* key cache index */ =09=09, sc->sc_txantenna=09/* antenna mode */ =09=09, flags=09=09=09/* flags */ =09=09, ctsrate=09=09/* rts/cts rate */ =09=09, ctsduration=09=09/* rts/cts duration */ =09); This is still just for the first tx desc though. The following bit then comes: =09if (try0 !=3D ATH_TXMAXTRY) =09=09ath_rate_setupxtxdesc(sc, an, ds, shortPreamble, rix); Should I nix this? -Sam From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 22:45:36 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 CF6AA16A41F for ; Wed, 27 Jul 2005 22:45:36 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D9D843D46 for ; Wed, 27 Jul 2005 22:45:35 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id i22so280671wra for ; Wed, 27 Jul 2005 15:45:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PZSLKyo3we+DfeON13HtOgCzLR9GdwpRvE0fj1oEN50quH7leV9MY6FuHFIxVIdUOwFTtEHh2bBeqW9lIlHFiFQeUwQWXZHOVaztQKGiEli+HdXV/HNTO33wdoKfsa/rjKRUg0bXSyqFcH6ajfu56/Lk4i3ssaq8D9PKAOBrIuA= Received: by 10.54.32.18 with SMTP id f18mr534955wrf; Wed, 27 Jul 2005 15:45:26 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Wed, 27 Jul 2005 15:45:26 -0700 (PDT) Message-ID: Date: Wed, 27 Jul 2005 17:45:26 -0500 From: Sam Pierson To: David Malone In-Reply-To: <200507261513.aa10533@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200507261513.aa10533@salmon.maths.tcd.ie> Cc: FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Pierson List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 22:45:36 -0000 On 7/26/05, David Malone wrote: > That's correct, but it probably takes a few microseconds for the > carries sense to kick in (if there wasn't a delay there would > be almost no need for the random backoff). That's why you'll > also have to have your transmissions synchronised very closely. > David. Since my project is running in adhoc mode, I noticed that there is a LOT of noise being generated by the two machines I want to use in order to generate a collision. The noise is the adhoc beacon being broadcast. Clearly they need to talk to each other, but I'd really like to quiet down the channel so I can attempt this collision. I found this in if_ath: /* NB: the beacon interval is kept internally in TU's */ and this in /sys/contrib/dev/ath/ah_desc.h =09HAL_TX_QUEUE_BEACON=09=3D 2,=09=09/* beacon xmit q */ =09HAL_TX_QUEUE_CAB=09=3D 3,=09=09/* "crap after beacon" xmit q */ and... # cat ah.h | grep interval * beacon interval (given in TU's) can also include flags u_int32_t bs_intval; /* beacon interval+flags */ #define HAL_BEACON_PERIOD 0x0000ffff /* beacon interval period *= / I think the carrier sensing is kicking in because the channel is not quiet due to the beacons. Do the tx q things matter? seems like the=20 hal_beacon_period would be the most important line, but I don't see how that flag (if it is one) can be used. -Sam From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 23:38:20 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 00F1716A41F for ; Wed, 27 Jul 2005 23:38:20 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A99443D48 for ; Wed, 27 Jul 2005 23:38:19 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id 94A3E323191 for ; Thu, 28 Jul 2005 01:38:18 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 59B5E405B; Thu, 28 Jul 2005 01:38:42 +0200 (CEST) Date: Thu, 28 Jul 2005 01:38:42 +0200 From: Jeremie Le Hen To: freebsd-hackers@FreeBSD.org Message-ID: <20050727233842.GW1610@obiwan.tataz.chchile.org> References: <20050705153933.GP73907@obiwan.tataz.chchile.org> <20050726232645.GN1610@obiwan.tataz.chchile.org> <20050727000054.GA15018@britannica.bec.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+jhVVhN62yS6hEJ8" Content-Disposition: inline In-Reply-To: <20050727000054.GA15018@britannica.bec.de> User-Agent: Mutt/1.5.9i Cc: Subject: Re: ProPolice symbols in libc or libssp ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 23:38:20 -0000 --+jhVVhN62yS6hEJ8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > Being full of enthusiasm, I checked if by chance libraries could have > > dynamic object dependencies. It appears this is not the case, but > > since I'm neither a GCC nor binutils hacker, maybe there is a way to > > achieve this. This is the purpose of this email ? > > What you have been smoking? Dynamic libraries surely can depend on other > objects :-) Just link libc with -lssp, given that libssp should be > self-contained or any other library you want to have propolice in > against ssp. Static libraries are not an issue either, since you can > simply add the object file. If you look around, you might even find some > programs which allow you to add the dependency into an existing library, > which would be perfect for libc. (Sorry, you guys are maybe fed up with ProPolice and I'm sending a huge mail again, but I have three questions. Nevertheless, I would be glad if someone with some bigger experience could take some time to answer them.) Eheh, I've not been smoking anything, maybe should I. ;-) 1) In fact I've been misleaded because I modified the GCC configuration (FBSD_LIB_SPEC in contrib/gcc/config/freebsd-spec.h) to make it automatically link against libssp and I supposed wrongly this would link programs _and_ libraries with libssp. When buildworld was completed, I checked this with ldd(1), that's why I thought it wasn't possible to have libraries depending on other objects (installworld not done that's why libssp is not resolved) : %%% jarjarbinks# ldd /usr/obj/usr/src/bin/cat/cat /usr/obj/usr/src/bin/cat/cat: libssp.so.1 => not found (0x0) libc.so.6 => /lib/libc.so.6 (0x3137b000) jarjarbinks# ldd /usr/obj/usr/src/lib/libz/libz.so.3 /usr/obj/usr/src/lib/libz/libz.so.3: %%% It seems that LIB_SPEC macro content is used only when linking programs, not libraries, although the GCC Internals book states that it is used whenever the linker is used [1]. I can understand that each library should not be linked against libc, and that's why ld(1) isn't called with LIB_SPEC macro when linking shared libraries. But how should I do to have shared libraries linked against libssp ? Use LDADD make variable (see question 2) ? 2) Secondly, after digging a bit more, I thought that I could replace the GCC's freebsd-spec.h hack by using the LDADD make variable. The advantage is that it will make import of next GCC release easier. Furthermore, it would make me sure that libraries are really linked with libssp (see question 1). The drawback is that this will be a mess for ports to handle this because their tree is used through numerous FreeBSD major branches : this would require to test that "${CC} ${CFLAGS}" actually handles stack protector and add -lssp depending on the result. Additionaly, I would say that only GCC is able to really know when it is needed to link against libssp or not, since the make system will either have a weak assumption of this or need some black magic as described above for ports. 3) Finally, my libssp requires libc because I use sysctl(3), syslog(3) and a few other functions. I resolved the problem of circular dependancies with weak dependancies : libc includes libssp source file but with different symbol names to avoid conflicts. Then I create weak references for the real SSP symbols names (see attached patch for an illustration). OTOH, while I was documenting on GCC, I saw they use something like "-lgcc -lc -lgcc" (see macro LINK_GCC_C_SEQUENCE_SPEC from [1]). Is it something possible for libssp, or is it simply a hack that should be avoided ? If you are still reading at this point, thanks :-). I hope to not have forgotten anything or I will need to post again :). Regards, [1] http://gcc.gnu.org/onlinedocs/gccint/Driver.html -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --+jhVVhN62yS6hEJ8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="libssp.diff" Index: lib/Makefile =================================================================== RCS file: /nfs/obiwan/cvs/src/lib/Makefile,v retrieving revision 1.206 diff -u -p -u -p -r1.206 Makefile --- lib/Makefile 14 Jul 2005 17:59:50 -0000 1.206 +++ lib/Makefile 26 Jul 2005 16:41:42 -0000 @@ -32,8 +32,8 @@ SUBDIR= ${_csu} libcom_err libcrypt libk libipx libkiconv libmagic libmemstat libmenu ${_libmilter} ${_libmp} \ ${_libncp} ${_libngatm} libopie libpam libpanel libpcap \ libpmc ${_libpthread} ${_libsdp} ${_libsm} ${_libsmb} ${_libsmdb} \ - ${_libsmutil} libstand libtelnet ${_libthr} ${_libthread_db} libufs \ - libugidfw ${_libusbhid} ${_libvgl} libwrap liby libz ${_bind} + ${_libsmutil} libssp libstand libtelnet ${_libthr} ${_libthread_db} \ + libufs libugidfw ${_libusbhid} ${_libvgl} libwrap liby libz ${_bind} .if exists(${.CURDIR}/csu/${MACHINE_ARCH}-elf) _csu=csu/${MACHINE_ARCH}-elf Index: lib/libc/sys/Makefile.inc =================================================================== RCS file: /nfs/obiwan/cvs/src/lib/libc/sys/Makefile.inc,v retrieving revision 1.113 diff -u -p -u -p -r1.113 Makefile.inc --- lib/libc/sys/Makefile.inc 7 Jul 2005 18:17:55 -0000 1.113 +++ lib/libc/sys/Makefile.inc 26 Jul 2005 19:02:49 -0000 @@ -2,7 +2,7 @@ # $FreeBSD: src/lib/libc/sys/Makefile.inc,v 1.113 2005/07/07 18:17:55 jhb Exp $ # sys sources -.PATH: ${.CURDIR}/${MACHINE_ARCH}/sys ${.CURDIR}/sys +.PATH: ${.CURDIR}/${MACHINE_ARCH}/sys ${.CURDIR}/sys ${.CURDIR}/../libssp # Include the generated makefile containing the *complete* list # of syscall names in MIASM. @@ -23,6 +23,9 @@ SRCS+= ftruncate.c lseek.c mmap.c pread. # Add machine dependent asm sources: SRCS+=${MDASM} +# Include libssp symbols. +SRCS+= ssp.c + # Look though the complete list of syscalls (MIASM) for names that are # not defined with machine dependent implementations (MDASM) and are # not declared for no generation of default code (NOASM). Add each Index: lib/libssp/Makefile =================================================================== RCS file: lib/libssp/Makefile diff -N lib/libssp/Makefile --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ lib/libssp/Makefile 26 Jul 2005 18:42:21 -0000 @@ -0,0 +1,14 @@ +# +# $Id$ +# + +SHLIB_MAJOR= 1 +LIB= ssp +SHLIBDIR?= /lib + +SRCS= ssp.c +CFLAGS+= -DLIBSSP + +PRECIOUSLIB= + +.include Index: lib/libssp/ssp.c =================================================================== RCS file: lib/libssp/ssp.c diff -N lib/libssp/ssp.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ lib/libssp/ssp.c 27 Jul 2005 09:03:17 -0000 @@ -0,0 +1,118 @@ +/* + * Copyright (c) 2002 Hiroaki Etoh, Federico G. Schwindt, and Miodrag Vallat. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN + * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + */ + +#if defined(LIBC_SCCS) && !defined(list) +static char rcsid[] = "$OpenBSD: stack_protector.c,v 1.7 2004/09/14 22:19:30 deraadt Exp $"; +#endif + +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * Largest pointers of FreeBSD supported architectures are 64bits. + * Let's say it's 2 * sizeof(long). + */ +#define __GUARD_SIZE 2 + +#ifdef LIBSSP +long ___ssp_guard[__GUARD_SIZE] = { 0 }; +void ___ssp_stack_smash_handler(char func[], + int damaged __attribute__((unused))); +__weak_reference(___ssp_guard, __guard); +__weak_reference(___ssp_stack_smash_handler, __stack_smash_handler); +#else +long ___guard[__GUARD_SIZE] = { 0 }; +void ___stack_smash_handler(char func[], + int damaged __attribute__((unused))); +__weak_reference(___guard, __guard); +__weak_reference(___stack_smash_handler, __stack_smash_handler); +#endif +static void __guard_setup(void) __attribute__ ((constructor)); + +static void +__guard_setup(void) +{ + int i, mib[2]; + size_t len; +#ifdef LIBSSP + long *guard = ___ssp_guard; +#else + long *guard = ___guard; +#endif + + if (guard[0] != 0) + return; + mib[0] = CTL_KERN; + mib[1] = KERN_ARND; + + len = sizeof(long); + for (i = 0; i < __GUARD_SIZE; i++) + if (sysctl(mib, 2, &guard[i], &len, NULL, 0) == -1) { + /* Use the terminator canary as a fallback method. */ + ((char *)guard)[0] = '\0'; + ((char *)guard)[1] = '\0'; + ((char *)guard)[2] = '\n'; + ((char *)guard)[3] = '\xff'; + break; + } +} + +void +#ifdef LIBSSP +___ssp_stack_smash_handler(char func[], int damaged) +#else +___stack_smash_handler(char func[], int damaged) +#endif +{ + const char message[] = "stack overflow in function %s"; + struct sigaction sa; + sigset_t mask; + + /* Immediately block all signal handlers from running code. */ + sigfillset(&mask); + sigdelset(&mask, SIGABRT); + sigprocmask(SIG_BLOCK, &mask, NULL); + + /* This may fail on a chroot jail, though luck. */ + syslog(LOG_CRIT, message, func); + + bzero(&sa, sizeof(struct sigaction)); + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + sa.sa_handler = SIG_DFL; + sigaction(SIGABRT, &sa, NULL); + + kill(getpid(), SIGABRT); + + _exit(127); +} --+jhVVhN62yS6hEJ8-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 23:45:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 89EB016A41F for ; Wed, 27 Jul 2005 23:45:37 +0000 (GMT) (envelope-from uvarovsl@mail.pnpi.spb.ru) Received: from mail.lsi.ru (mail.lsi.ru [212.58.192.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D2BD43D45 for ; Wed, 27 Jul 2005 23:45:36 +0000 (GMT) (envelope-from uvarovsl@mail.pnpi.spb.ru) Received: by mail.lsi.ru (Postfix, from userid 426) id CF12B386DA2; Thu, 28 Jul 2005 03:45:35 +0400 (MSD) Received: from [10.0.0.3] (unknown [212.58.210.222]) by mail.lsi.ru (Postfix) with ESMTP id 6F540386D92 for ; Thu, 28 Jul 2005 03:45:34 +0400 (MSD) Message-ID: <42E81D52.1020909@mail.pnpi.spb.ru> Date: Thu, 28 Jul 2005 03:48:34 +0400 From: Sergey Uvarov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: file locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 23:45:37 -0000 Hello hackers, man page for flock(2) and fcntl(2) reads that a system call returns EOPNOTSUPP if file descriptor refers to an object that does not support file locking. However, it seems that it is not always true. For example, if underlying object is a device or a fifo returned error code depends on type of lock. When I look at sources of VOP_ADVLOCK for fifo (sys/fs/fifofs/fifo_vnops.c, fifo_advlock() function) I see the following line: ... return (ap->a_flags & F_FLOCK ? EOPNOTSUPP : EINVAL); ... I.e. for freebsd locks EOPNOTSUPP error code is returned. It is correct. But for posix locks EINVAL error code is returned. Is it correct? Thanks you in advance, Sergey. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 04:11:16 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6C3E016A41F; Thu, 28 Jul 2005 04:11:16 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A85943D48; Thu, 28 Jul 2005 04:11:16 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6S497Na031990; Wed, 27 Jul 2005 22:09:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 27 Jul 2005 22:10:09 -0600 (MDT) Message-Id: <20050727.221009.70219624.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <42E7BD9F.6060401@samsco.org> References: <42E7BD9F.6060401@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: deischen@freebsd.org, NKoch@demig.de, freebsd-hackers@freebsd.org Subject: Re: await & asleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 04:11:16 -0000 In message: <42E7BD9F.6060401@samsco.org> Scott Long writes: : > and the priority argument of tsleep() doesn't have any meaning : > any longer, right? : > : : I thought it did, but John can give the definitive answer. Priority is still useful. It is the same priority that msleep uses. tsleep is completely equivalent to msleep with a null mtx parameter. The priority field is indeed used: /* * Adjust this thread's priority. */ mtx_lock_spin(&sched_lock); sched_prio(td, priority & PRIMASK); mtx_unlock_spin(&sched_lock); msleep is a different primitive that cv_wait and friends. cv_wait enforces good mutex practices and generally should be used... Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 07:59:36 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 05A3E16A41F for ; Thu, 28 Jul 2005 07:59:36 +0000 (GMT) (envelope-from gemini@geminix.org) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9898543D62 for ; Thu, 28 Jul 2005 07:59:35 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <42E89060.3060700@geminix.org> Date: Thu, 28 Jul 2005 09:59:28 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050726 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rink Springer References: <4285cd45050727063146c054d4@mail.gmail.com> <20050727134432.GA10142@stack.nl> In-Reply-To: <20050727134432.GA10142@stack.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51 (FreeBSD)) id 1Dy3If-0002y2-Pc; Thu, 28 Jul 2005 09:59:29 +0200 Cc: hackers@freebsd.org, Ludvig Strigeus , ed@fxq.nl Subject: Re: Problem with pic16l_setled X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 07:59:36 -0000 Rink Springer wrote: > * Ludvig Strigeus (strigeus@gmail.com) wrote: > >>I see this code: >> >>+ENTRY(pic16l_setled) >>+ push %ebp >>+ mov %esp,%ebp >>+ >>+ movl 0x8(%ebp),%ebx >>+ orl $0x800,%ebx >>+ call pic16l_ledhlp >>+ movl $0x701,%ebx >>+ call pic16l_ledhlp >>+ >>+ leave >>+ ret >> >>With the standard x86 calling convention, you're not supposed to >>modify ebx, esi or edi without saving them first. Try adding a >>push/pop ebx around. > > I doubt this is the problem (I've looked at other .s files like > i386/i386/support.s, function ssdtosd, and they don't seem to do this). Well, at least in 'support.s' of RELENG_4 register ebx _does_ get pushed onto the stack in function 'ssdtosd'. I suppose this is true also for the other FreeBSD branches. If you call a function from the C level only registers eax, edx and ecx may be altered without preserving their original contents on the stack (or wherever else). That is, in C the calling level expects that the other registers survive a function call unharmed. As pointed out that's the standard x86 calling convention which applies to all x86 compilers, not just GCC. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 27 13:41:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 522BB16A41F for ; Wed, 27 Jul 2005 13:41:57 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3485E43D5D for ; Wed, 27 Jul 2005 13:41:53 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 80EE617027; Wed, 27 Jul 2005 15:41:52 +0200 (CEST) Date: Wed, 27 Jul 2005 15:41:52 +0200 From: Ed Schouten To: loader Message-ID: <20050727134152.GJ80282@hoeg.nl> References: <20050726090441.GA77383@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6v9BRtpmy+umdQlo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Thu, 28 Jul 2005 12:14:36 +0000 Cc: freebsd-hackers@freebsd.org, xbox-linux-devel@lists.sourceforge.net, Rink Springer Subject: Re: FreeBSD ported to the XBox! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 13:41:57 -0000 --6v9BRtpmy+umdQlo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * loader wrote: > I got my XBOX with an Aladdin modchip. Today I downloaded the LiveCD > and tried to boot from it, but failed. (I don't have the Cromwell BIOS > installed on my XBOX ). Then I booted XBOX with GentooX install CD (Home = edition), > and replaced GentooX CD with FreeBSD XBOX live CD after it booted into=20 > GentooX Loader, selected CD option, then the XBOX was try to boot from it= ,=20 > I can see there's four choices (FreeBSD 5.4 ... CD/HDD,=20 > FreeBSD 6.0-BETA1 ... CD/HDD). I tried all of them, it just stopped there= ,=20 > it didn't show any FreeBSD boot messages. Well, the GentooX bootloader doesn't support ELF files yet. If I recall correctly, Rink has also put a patched Cromwell binary on the CD, so you could chainload it from within the GentooX loader. Good luck! Yours, --=20 Ed Schouten --6v9BRtpmy+umdQlo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC548gmVI4SHXwmhERAsaxAJ4wBeIeasY6XRz+hSEfPZBRHK8/RQCbBVNK 1tWY9lE/JJqQqze80Lh3j+Y= =Sg7c -----END PGP SIGNATURE----- --6v9BRtpmy+umdQlo-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 15:52:50 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 6F5B116A421 for ; Thu, 28 Jul 2005 15:52:50 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8741843D48 for ; Thu, 28 Jul 2005 15:52:49 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 95E11EB429E for ; Thu, 28 Jul 2005 23:52:46 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 8142A136325 for ; Thu, 28 Jul 2005 23:52:44 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14353-20 for ; Thu, 28 Jul 2005 23:52:34 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 5A6FC133510; Thu, 28 Jul 2005 23:52:34 +0800 (CST) Date: Thu, 28 Jul 2005 23:52:34 +0800 From: Xin LI To: freebsd-hackers@FreeBSD.org Message-ID: <20050728155234.GA14880@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: [RFC] Add usr/ports to BSD.usr.mtree X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 15:52:50 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear folks, It seems that /usr/ports is not part of our BSD.usr.mtree tree. Is there any reason for this? I'm willing to add it to the mtree if nobody objects. Thanks for your comments! Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC6P9C/cVsHxFZiIoRAjEEAJ9ywFN5hLEJWkPhpOFA5gLouCfonwCgiSKg YWlXfYZKl6qmLCD+5YPondM= =YREZ -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 16:09:38 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 D837616A41F for ; Thu, 28 Jul 2005 16:09:38 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86A5643D62 for ; Thu, 28 Jul 2005 16:09:37 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id F2A3535707 for ; Thu, 28 Jul 2005 18:09:32 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 80416543F; Thu, 28 Jul 2005 18:07:32 +0200 (CEST) Date: Thu, 28 Jul 2005 18:07:32 +0200 From: Joerg Sonnenberger To: freebsd-hackers@FreeBSD.org Message-ID: <20050728160732.GA964@britannica.bec.de> Mail-Followup-To: freebsd-hackers@FreeBSD.org References: <20050728155234.GA14880@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050728155234.GA14880@frontfree.net> User-Agent: Mutt/1.5.6i Cc: Subject: Re: [RFC] Add usr/ports to BSD.usr.mtree X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 16:09:39 -0000 On Thu, Jul 28, 2005 at 11:52:34PM +0800, Xin LI wrote: > It seems that /usr/ports is not part of our BSD.usr.mtree tree. Is > there any reason for this? I'm willing to add it to the mtree if > nobody objects. (a) Not everybody uses third party build infrastructures. (b) Not everybody uses ports, some use pkgsrc. (c) Why should ports be placed in /usr/ports? On my systems it normally was under /home, allowing /usr to be much smaller. Joerg From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 22:14:25 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 75E5016A41F for ; Thu, 28 Jul 2005 22:14:25 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1619343D45 for ; Thu, 28 Jul 2005 22:14:25 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id 53586C050; Fri, 29 Jul 2005 00:14:24 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 047AB405B; Fri, 29 Jul 2005 00:14:48 +0200 (CEST) Date: Fri, 29 Jul 2005 00:14:47 +0200 From: Jeremie Le Hen To: Joerg Sonnenberger Message-ID: <20050728221447.GF68965@obiwan.tataz.chchile.org> References: <20050705153933.GP73907@obiwan.tataz.chchile.org> <20050726232645.GN1610@obiwan.tataz.chchile.org> <20050727000054.GA15018@britannica.bec.de> <20050727233842.GW1610@obiwan.tataz.chchile.org> <20050728023239.GA21179@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050728023239.GA21179@britannica.bec.de> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@FreeBSD.org, Jeremie Le Hen Subject: Re: ProPolice symbols in libc or libssp ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 22:14:25 -0000 > Make sure you patch the right place and _not_ the shared part. Does the > attached patch work for you? Yes, this worked, thank you ! This implies that libssp must be linked with -nodefaultlibs option to avoid linking itself against libssp. But this also prevents it from being linked against libgcc. Is it something harmful or not (in other words should I manually add -lgcc to LDFLAGS) ? Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 28 22:32:38 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 D1F0316A41F for ; Thu, 28 Jul 2005 22:32:38 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66F3C43D48 for ; Thu, 28 Jul 2005 22:32:38 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id E964535707 for ; Fri, 29 Jul 2005 00:32:34 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 21BAC53ED; Fri, 29 Jul 2005 00:30:31 +0200 (CEST) Date: Fri, 29 Jul 2005 00:30:30 +0200 From: Joerg Sonnenberger To: freebsd-hackers@FreeBSD.org Message-ID: <20050728223030.GA4570@britannica.bec.de> Mail-Followup-To: freebsd-hackers@FreeBSD.org References: <20050705153933.GP73907@obiwan.tataz.chchile.org> <20050726232645.GN1610@obiwan.tataz.chchile.org> <20050727000054.GA15018@britannica.bec.de> <20050727233842.GW1610@obiwan.tataz.chchile.org> <20050728023239.GA21179@britannica.bec.de> <20050728221447.GF68965@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050728221447.GF68965@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.6i Cc: Subject: Re: ProPolice symbols in libc or libssp ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 22:32:38 -0000 On Fri, Jul 29, 2005 at 12:14:47AM +0200, Jeremie Le Hen wrote: > > Make sure you patch the right place and _not_ the shared part. Does the > > attached patch work for you? > > Yes, this worked, thank you ! This implies that libssp must be linked > with -nodefaultlibs option to avoid linking itself against libssp. But > this also prevents it from being linked against libgcc. Is it > something harmful or not (in other words should I manually add -lgcc to > LDFLAGS) ? The problem with linking -lssp is that you normally want to aovid the circular dependency with libc. For static libraries that's not a problem, but for dynamic loading it is a bit nasty. One idea is to build libssp similiar to RTLD by directly linking the necessary parts of libc in, you can use a linker script to hide the symbols. For linking -lssp itself, you could try to exploit "-fno-stack-protector" and use that to not link libssp into. Joerg From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 03:22:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3D87316A41F; Fri, 29 Jul 2005 03:22:23 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAE8443D49; Fri, 29 Jul 2005 03:22:22 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.23] (andersonbox3.centtech.com [192.168.42.23]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j6T3ML7v072396; Thu, 28 Jul 2005 22:22:21 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42E9A0E7.40703@centtech.com> Date: Thu, 28 Jul 2005 22:22:15 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Pointers for understanding vfs/buffer/filesystem architecture X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 03:22:23 -0000 I've very interested in learning about FreeBSD's implementation of vfs/buffer cache/fs archicture. I've read through mckusick@'s chapter in the Design and Implmentation of FreeBSD book, and I've read the UNIX Filesystems book cover to cover. What I'd like to see/read/understand, is how FreeBSD in particular is put together in this regard, and then I'd like to go about writing a very very simple filesystem as a learning excercise. Can anyone give me some pointers? Would anyone be willing to guide me along in my quest by answering questions (off list if preferred, or on list), etc? Thanks in advance for the hints/input! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 04:24:59 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 D660716A41F for ; Fri, 29 Jul 2005 04:24:59 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id E501043D48 for ; Fri, 29 Jul 2005 04:24:58 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A1345EB45D4 for ; Fri, 29 Jul 2005 12:24:54 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 4E247137514; Fri, 29 Jul 2005 12:24:52 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39156-12; Fri, 29 Jul 2005 12:24:45 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 6271C132F57; Fri, 29 Jul 2005 12:24:44 +0800 (CST) Date: Fri, 29 Jul 2005 12:24:44 +0800 From: Xin LI To: Joerg Sonnenberger Message-ID: <20050729042444.GA39960@frontfree.net> References: <20050728155234.GA14880@frontfree.net> <20050728160732.GA964@britannica.bec.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <20050728160732.GA964@britannica.bec.de> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: freebsd-hackers@FreeBSD.org Subject: Re: [RFC] Add usr/ports to BSD.usr.mtree X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 04:24:59 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Joerg, On Thu, Jul 28, 2005 at 06:07:32PM +0200, Joerg Sonnenberger wrote: > On Thu, Jul 28, 2005 at 11:52:34PM +0800, Xin LI wrote: > > It seems that /usr/ports is not part of our BSD.usr.mtree tree. Is > > there any reason for this? I'm willing to add it to the mtree if > > nobody objects. > > (a) Not everybody uses third party build infrastructures. > (b) Not everybody uses ports, some use pkgsrc. > (c) Why should ports be placed in /usr/ports? On my systems it normally > was under /home, allowing /usr to be much smaller.=20 Thanks for sharing your viewpoints. Mine is a bit different: - Not everyone wants to build the system, especially the large companies that utilize some sort of binary update mechainsm. - Having an empty /usr/ports does not block the user from using pkgsrc or others, and it is possible to use ln(1) if the mtree entry is marked "nochange". Also, the default setting is to use /usr/ports as PORTSDIR. My points to have /usr/ports in the mtree is for convience that users creating a jail that is intended to mount the ports tree from the host system, without having to create their own in every instances. What do you think about this? Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC6a+M/cVsHxFZiIoRAvNsAJwJam1ytvgzIdBmGij09/tPsdhLWQCghXzD V8tZQF2qjya+lltXWkGMyOs= =a5RQ -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 05:10:36 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 0C13B16A41F; Fri, 29 Jul 2005 05:10:36 +0000 (GMT) (envelope-from rmaglasang@infoweapons.com) Received: from ws2.infoweapons.com (ws2.infoweapons.com [203.177.161.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4A9143D49; Fri, 29 Jul 2005 05:10:34 +0000 (GMT) (envelope-from rmaglasang@infoweapons.com) Received: from [10.3.1.41] ([10.3.1.41]) by ws2.infoweapons.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jul 2005 13:09:57 +0800 Message-ID: <42E9BC12.2050401@infoweapons.com> Date: Fri, 29 Jul 2005 13:18:10 +0800 From: "Ronnel P. Maglasang" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers , freebsd-geom , freebsd-security Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2005 05:09:57.0281 (UTC) FILETIME=[C3502110:01C593FB] Cc: Subject: booting gbde-encrypted filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 05:10:36 -0000 Hello, I think there was already a thread on this. I just want to raise the question again if anyone has successfully booted an gdbe-encrypted filesystem (everything encrypted except the bootloader). The passphrase is entered at the bootloader prompt or embedded in the bootloader. I appreciate any tips. Thanks, - ronnel From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 05:11:33 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 3273216A41F for ; Fri, 29 Jul 2005 05:11:33 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06A2143D4C for ; Fri, 29 Jul 2005 05:11:32 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 4C3FFEB45DF for ; Fri, 29 Jul 2005 13:11:30 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id A1EB313759F; Fri, 29 Jul 2005 13:11:28 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40493-10; Fri, 29 Jul 2005 13:11:21 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id BD6AE13711D; Fri, 29 Jul 2005 13:11:20 +0800 (CST) Date: Fri, 29 Jul 2005 13:11:20 +0800 From: Xin LI To: Joerg Sonnenberger Message-ID: <20050729051120.GA40830@frontfree.net> References: <20050728155234.GA14880@frontfree.net> <20050728160732.GA964@britannica.bec.de> <20050729042444.GA39960@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20050729042444.GA39960@frontfree.net> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: freebsd-hackers@FreeBSD.org Subject: Re: [RFC] Add usr/ports to BSD.usr.mtree X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 05:11:33 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 29, 2005 at 12:24:44PM +0800, Xin LI wrote: > Thanks for sharing your viewpoints. Mine is a bit different: > - Not everyone wants to build the system, especially the large companies > that utilize some sort of binary update mechainsm. Oops, I mean /usr/obj here. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC6bp4/cVsHxFZiIoRAoP5AJ0e5itv51JREszLXEUiXNB5fqHVPACeKF4X TwdDlM5XjGXv1yu5dimWqdA= =OZQp -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 06:54:00 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 ADF2A16A420; Fri, 29 Jul 2005 06:54:00 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id C940F43D46; Fri, 29 Jul 2005 06:53:59 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id D91B4ACAF1; Fri, 29 Jul 2005 08:53:57 +0200 (CEST) Date: Fri, 29 Jul 2005 08:53:57 +0200 From: Pawel Jakub Dawidek To: "Ronnel P. Maglasang" Message-ID: <20050729065357.GA617@darkness.comp.waw.pl> References: <42E9BC12.2050401@infoweapons.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <42E9BC12.2050401@infoweapons.com> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 Cc: freebsd-security , freebsd-hackers , freebsd-geom Subject: Re: booting gbde-encrypted filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 06:54:00 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 29, 2005 at 01:18:10PM +0800, Ronnel P. Maglasang wrote: +> Hello, +>=20 +> I think there was already a thread on this. I just +> want to raise the question again if anyone has successfully +> booted an gdbe-encrypted filesystem (everything encrypted except +> the bootloader). The passphrase is entered at the bootloader prompt +> or embedded in the bootloader. This is not not possible with current GBDE. I've patches which allows this here: http://people.freebsd.org/~pjd/patches/gbde.patch --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFC6dKFForvXbEpPzQRAi03AKCrskTtDsmZFMMECdVKRC4WvDUAlwCdFZok TQ9ygQCYujsqduk/oF61RLs= =DTQv -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 07:55:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6661016A41F; Fri, 29 Jul 2005 07:55:58 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 061E543D45; Fri, 29 Jul 2005 07:55:57 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id A1D77323387; Fri, 29 Jul 2005 09:55:56 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 68690405B; Fri, 29 Jul 2005 09:56:19 +0200 (CEST) Date: Fri, 29 Jul 2005 09:56:18 +0200 From: Jeremie Le Hen To: Pawel Jakub Dawidek Message-ID: <20050729075618.GI68965@obiwan.tataz.chchile.org> References: <42E9BC12.2050401@infoweapons.com> <20050729065357.GA617@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050729065357.GA617@darkness.comp.waw.pl> User-Agent: Mutt/1.5.9i Cc: freebsd-security , freebsd-geom , freebsd-hackers , "Ronnel P. Maglasang" Subject: Re: booting gbde-encrypted filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 07:55:58 -0000 > This is not not possible with current GBDE. > I've patches which allows this here: > > http://people.freebsd.org/~pjd/patches/gbde.patch This is great. Do you intend to commit it someday ? I know the GELI framework allows to use an encrypted root partition, but it would be interesting for GBDE users to be provided such a fonctionnality. Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 08:00:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3AB8116A41F; Fri, 29 Jul 2005 08:00:48 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id A76EA43D49; Fri, 29 Jul 2005 08:00:47 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 06F40ACE06; Fri, 29 Jul 2005 10:00:36 +0200 (CEST) Date: Fri, 29 Jul 2005 10:00:36 +0200 From: Pawel Jakub Dawidek To: Jeremie Le Hen Message-ID: <20050729080035.GB609@darkness.comp.waw.pl> References: <42E9BC12.2050401@infoweapons.com> <20050729065357.GA617@darkness.comp.waw.pl> <20050729075618.GI68965@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline In-Reply-To: <20050729075618.GI68965@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 Cc: freebsd-security , freebsd-geom , freebsd-hackers , "Ronnel P. Maglasang" Subject: Re: booting gbde-encrypted filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 08:00:48 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 29, 2005 at 09:56:18AM +0200, Jeremie Le Hen wrote: +> > This is not not possible with current GBDE. +> > I've patches which allows this here: +> >=20 +> > http://people.freebsd.org/~pjd/patches/gbde.patch +>=20 +> This is great. Do you intend to commit it someday ? I know the GELI +> framework allows to use an encrypted root partition, but it would be +> interesting for GBDE users to be provided such a fonctionnality. I sent those patches to phk@ few months ago now. If he decided to add such functionality he is welcome to use them:) I'm not going to commit it by myself. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFC6eIjForvXbEpPzQRAocWAJ9Jdxg14xsif8Du8F/VAy1jQZuJ6ACgrO2Q v+SfXaZk4Bfyf/1cyzlvFCM= =zJgB -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 11:52:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E1DFA16A41F; Fri, 29 Jul 2005 11:52:43 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BDF643D45; Fri, 29 Jul 2005 11:52:43 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id A2E38BC66; Fri, 29 Jul 2005 11:52:41 +0000 (UTC) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 29 Jul 2005 13:45:48 +0200." <20050729134548.1cc28dr8gg0k4k0g@netchild.homeip.net> Date: Fri, 29 Jul 2005 13:52:40 +0200 Message-ID: <94252.1122637960@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: freebsd-security , "Ronnel P. Maglasang" , Pawel Jakub Dawidek , freebsd-hackers , freebsd-geom Subject: Re: booting gbde-encrypted filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 11:52:44 -0000 In message <20050729134548.1cc28dr8gg0k4k0g@netchild.homeip.net>, Alexander Leidinger writes: >Pawel Jakub Dawidek wrote: > >> This is not not possible with current GBDE. >> I've patches which allows this here: >> >> http://people.freebsd.org/~pjd/patches/gbde.patch > >I fail to see how this allows an encryted root-FS, it doesn't add gbde >support to boot0(ext) or to the loader. It needs access to an unencrypted >kernel. I don't think this is what Ronnel had in mind (overlooking the fact >that his suggestion to save the passphrase in the loader is insecure). There is a difference between loading the kernel from an encrypted volume (very hard!) and mounting the root filesystem from an encrypted volume (possible with pawels patch. Now of course, if your kernel has been trojaned, you're in trouble, but then again, most people just worry about their data if the machine gets stolen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 11:46:01 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B079516A41F; Fri, 29 Jul 2005 11:46:01 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FDDB43D48; Fri, 29 Jul 2005 11:46:00 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd26.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1DyTJO-000064-01; Fri, 29 Jul 2005 13:45:58 +0200 Received: from Andro-Beta.Leidinger.net (SOkMxYZp8eZNCzlKsWqx3CHvPocSdyqG6GSmeL7Q+uOaz6fbFdncsW@[84.165.201.169]) by fwd26.sul.t-online.de with esmtp id 1DyTJL-18HMzA0; Fri, 29 Jul 2005 13:45:55 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j6TBjmAw061039; Fri, 29 Jul 2005 13:45:48 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.31 ([141.113.101.31]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Fri, 29 Jul 2005 13:45:48 +0200 Message-ID: <20050729134548.1cc28dr8gg0k4k0g@netchild.homeip.net> X-Priority: 3 (Normal) Date: Fri, 29 Jul 2005 13:45:48 +0200 From: Alexander Leidinger To: Pawel Jakub Dawidek References: <42E9BC12.2050401@infoweapons.com> <20050729065357.GA617@darkness.comp.waw.pl> In-Reply-To: <20050729065357.GA617@darkness.comp.waw.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-ID: SOkMxYZp8eZNCzlKsWqx3CHvPocSdyqG6GSmeL7Q+uOaz6fbFdncsW@t-dialin.net X-TOI-MSGID: 82a2a4a0-6caf-4639-9241-f63ea2662f16 X-Mailman-Approved-At: Fri, 29 Jul 2005 12:40:37 +0000 Cc: freebsd-security , freebsd-geom , freebsd-hackers , "Ronnel P. Maglasang" Subject: Re: booting gbde-encrypted filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 11:46:01 -0000 Pawel Jakub Dawidek wrote: > This is not not possible with current GBDE. > I've patches which allows this here: > > http://people.freebsd.org/~pjd/patches/gbde.patch I fail to see how this allows an encryted root-FS, it doesn't add gbde support to boot0(ext) or to the loader. It needs access to an unencrypted kernel. I don't think this is what Ronnel had in mind (overlooking the fact that his suggestion to save the passphrase in the loader is insecure). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 The man who can smile when things go wrong has thought of someone he can blame it on. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 13:08:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 155CA16A442 for ; Fri, 29 Jul 2005 13:08:13 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A06343D45 for ; Fri, 29 Jul 2005 13:08:11 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.zoral.local (root@kostik.zoral.local [10.1.1.38]) by fw.zoral.com.ua (8.13.3/8.13.1) with ESMTP id j6TD84CD093299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jul 2005 16:08:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.zoral.local (kostik@localhost [127.0.0.1]) by deviant.zoral.local (8.13.3/8.13.3) with ESMTP id j6TD8woE061884 for ; Fri, 29 Jul 2005 16:08:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.zoral.local (8.13.3/8.13.3/Submit) id j6TD8wX6061883 for freebsd-hackers@freebsd.org; Fri, 29 Jul 2005 16:08:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.zoral.local: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Jul 2005 16:08:58 +0300 From: Kostik Belousov To: freebsd-hackers@freebsd.org Message-ID: <20050729130858.GD905@deviant.zoral.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on fw.zoral.com.ua Subject: swap reservation accounting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 13:08:13 -0000 Hello everyone, I developed the patch for 7-CURRENT (also should apply cleanly to 6) that implements swap reservation accounting and allows to cap the allocation of anonymous memory to the available swap. Effectively, this allows to optionally turn off overcommit feature of the VM. Besides this, per-user swap reservation limits could be enforced. Corresponding capability is added to the login.conf database. For some description of the implementation, TODO list and patch itself, please see http://kostikbel.narod.ru This is my first touch of the FreeBSD code, you valuable comments and reviews would be greatly appreciated. Best regards, Kostik Belousov From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 14:45:51 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 E994916A41F for ; Fri, 29 Jul 2005 14:45:51 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B85243D49 for ; Fri, 29 Jul 2005 14:45:51 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (storm.stura.uni-rostock.de [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 507FC35707 for ; Fri, 29 Jul 2005 16:45:50 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 29CC85410; Fri, 29 Jul 2005 16:43:49 +0200 (CEST) Date: Fri, 29 Jul 2005 16:43:49 +0200 From: Joerg Sonnenberger To: freebsd-hackers@FreeBSD.org Message-ID: <20050729144349.GC1002@britannica.bec.de> Mail-Followup-To: freebsd-hackers@FreeBSD.org References: <20050728155234.GA14880@frontfree.net> <20050728160732.GA964@britannica.bec.de> <20050729042444.GA39960@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050729042444.GA39960@frontfree.net> User-Agent: Mutt/1.5.6i Cc: Subject: Re: [RFC] Add usr/ports to BSD.usr.mtree X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 14:45:52 -0000 On Fri, Jul 29, 2005 at 12:24:44PM +0800, Xin LI wrote: > My points to have /usr/ports in the mtree is for convience that users > creating a jail that is intended to mount the ports tree from the host > system, without having to create their own in every instances. What > do you think about this? My point of view is that it blurs the distinction between base system and local extensions. It surely is convient, but I often scratch my head when I find empty directories on my system. Don't you start to wonder what those directories exist for? Back to the given example of mounting ports into multiple jails, wouldn't you normally have the ports tree only in one jail and use that for all building? The dinoex scripts come to my mind. Joerg From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 15:33:49 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 D379616A41F for ; Fri, 29 Jul 2005 15:33:49 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 632A443D48 for ; Fri, 29 Jul 2005 15:33:48 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 2F7E3EB4483 for ; Fri, 29 Jul 2005 23:33:46 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id CA8D6135572; Fri, 29 Jul 2005 23:33:43 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52787-06; Fri, 29 Jul 2005 23:33:37 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 90621136104; Fri, 29 Jul 2005 23:33:35 +0800 (CST) Date: Fri, 29 Jul 2005 23:33:35 +0800 From: Xin LI To: Joerg Sonnenberger Message-ID: <20050729153335.GA52464@frontfree.net> References: <20050728155234.GA14880@frontfree.net> <20050728160732.GA964@britannica.bec.de> <20050729042444.GA39960@frontfree.net> <20050729144349.GC1002@britannica.bec.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20050729144349.GC1002@britannica.bec.de> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: freebsd-hackers@FreeBSD.org Subject: Re: [RFC] Add usr/ports to BSD.usr.mtree X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 15:33:50 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Joerg, On Fri, Jul 29, 2005 at 04:43:49PM +0200, Joerg Sonnenberger wrote: > On Fri, Jul 29, 2005 at 12:24:44PM +0800, Xin LI wrote: > > My points to have /usr/ports in the mtree is for convience that users > > creating a jail that is intended to mount the ports tree from the host > > system, without having to create their own in every instances. What > > do you think about this? >=20 > My point of view is that it blurs the distinction between base system > and local extensions. It surely is convient, but I often scratch my > head when I find empty directories on my system. Don't you start to > wonder what those directories exist for? I think I won't if the directory is a well-known one... But I buy your "blur the distinction between base system and local extension" :-) > Back to the given example of mounting ports into multiple jails, > wouldn't you normally have the ports tree only in one jail and use that > for all building? The dinoex scripts come to my mind. This seems to be true only when the jail is provided for one single administrator. For a virtual hosting environment, you will want to run different OS versions inside jail (the development hosting box runs FreeBSD 6.0, 5.4, 5.3, 4.11 and 4.8 inside different jails), and just let the users to choose which application they want. Of course this needs some tricks like WRKDIRPREFIX tweaking inside every jails, and FETCH_CMD to point a hook that fetches all distfiles on behalf of the user, with all read-only ports tree. I will think about other solutions of the usr/ports handling, then. Thanks for the input! Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC6kxP/cVsHxFZiIoRAuymAJ9xGKb1PnFQeSoE73PRxeWHrKjt1gCeKxQ3 PaCDe4JkAqIEsBF8c4gzfok= =3Bzt -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 17:41:26 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 9322816A420 for ; Fri, 29 Jul 2005 17:41:26 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1E7043D4C for ; Fri, 29 Jul 2005 17:41:25 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.3/8.13.3) with ESMTP id j6THfOB6047411 for ; Fri, 29 Jul 2005 21:41:24 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 29 Jul 2005 21:41:24 +0400 (MSD) From: Dmitry Morozovsky To: freebsd-hackers@FreeBSD.org Message-ID: <20050729211719.C95340@woozle.rinet.ru> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (woozle.rinet.ru [0.0.0.0]); Fri, 29 Jul 2005 21:41:24 +0400 (MSD) Cc: Subject: mfs/mdconfig under RELENG_5: malloc vs swap-backed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 17:41:26 -0000 Dear colleagues, can anyone please point me why mdconfig method for tmpmfs is malloc-backed instead of swap-backed, and it is hardcoded into rc.subr? Are swap-backed file systems so inefficient? If no, why not move -M to /etc/defaultc/rc.conf so admin can override this behaviour? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 23:16:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 BA2B116A41F for ; Fri, 29 Jul 2005 23:16:14 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 043C243D45 for ; Fri, 29 Jul 2005 23:16:12 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j6TNG9BS071554 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 30 Jul 2005 01:16:11 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j6TNFkJ7090258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jul 2005 01:15:46 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j6TNFjsV043751; Sat, 30 Jul 2005 01:15:45 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j6TNFjMp043750; Sat, 30 Jul 2005 01:15:45 +0200 (CEST) (envelope-from ticso) Date: Sat, 30 Jul 2005 01:15:44 +0200 From: Bernd Walter To: Dmitry Morozovsky Message-ID: <20050729231544.GX26656@cicely12.cicely.de> References: <20050729211719.C95340@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050729211719.C95340@woozle.rinet.ru> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: mfs/mdconfig under RELENG_5: malloc vs swap-backed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 23:16:14 -0000 On Fri, Jul 29, 2005 at 09:41:24PM +0400, Dmitry Morozovsky wrote: > Dear colleagues, > > can anyone please point me why mdconfig method for tmpmfs > is malloc-backed instead of swap-backed, and it is hardcoded into rc.subr? > > Are swap-backed file systems so inefficient? If no, why not move -M to > /etc/defaultc/rc.conf so admin can override this behaviour? Diskless systems may not have swap - the default is required as is. Don't know about beeing hardcoded. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 30 12:19:25 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3A16816A41F for ; Sat, 30 Jul 2005 12:19:25 +0000 (GMT) (envelope-from daxiawj@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACB6A43D45 for ; Sat, 30 Jul 2005 12:19:24 +0000 (GMT) (envelope-from daxiawj@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so625855nzo for ; Sat, 30 Jul 2005 05:19:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:in-reply-to:references:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=LSjBs7CiCw6RC2tECuAjpx3+Tl75srzh0kgs8n5sOFHuzDOXXvFC340/Q0ifdwTReloyH2JUhX5DIIiKPv6pPBdOpO3u+oc9tVxqEuoRlkoNXRRnTIOPpCG8B2TynbdJ+jle2phGT3/wa0YuWL6htkt4DCyO+gFjVbZiigsAN8Y= Received: by 10.36.71.2 with SMTP id t2mr3787848nza; Sat, 30 Jul 2005 05:19:24 -0700 (PDT) Received: from ?222.94.3.209? ([222.94.3.209]) by mx.gmail.com with ESMTP id 15sm807405nzp.2005.07.30.05.19.22; Sat, 30 Jul 2005 05:19:24 -0700 (PDT) From: Wang Jun To: freebsd-hackers@freebsd.org In-Reply-To: <20050730120022.81B4316A41F@hub.freebsd.org> References: <20050730120022.81B4316A41F@hub.freebsd.org> Content-Type: text/plain; charset=gbk Organization: Nanjing Uni. Atmos. Dep. Date: Sat, 30 Jul 2005 20:22:59 +0800 Message-Id: <1122726180.8394.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 8bit Subject: unsubscribe X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daxiawj@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2005 12:19:25 -0000 unsubscribe > ÔÚ 2005-07-30ÁùµÄ 12:00 +0000£¬freebsd-hackers-request@freebsd.orgд µÀ£º > Send freebsd-hackers mailing list submissions to > freebsd-hackers@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > or, via email, send a message with subject or body 'help' to > freebsd-hackers-request@freebsd.org > > You can reach the person managing the list at > freebsd-hackers-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-hackers digest..." > Today's Topics: > > 1. Re: booting gbde-encrypted filesystem (Alexander Leidinger) > 2. swap reservation accounting (Kostik Belousov) > 3. Re: [RFC] Add usr/ports to BSD.usr.mtree (Joerg Sonnenberger) > 4. Re: [RFC] Add usr/ports to BSD.usr.mtree (Xin LI) > 5. mfs/mdconfig under RELENG_5: malloc vs swap-backed > (Dmitry Morozovsky) > 6. Re: mfs/mdconfig under RELENG_5: malloc vs swap-backed > (Bernd Walter) > µç×ÓÓʼþ ¸½¼þ > ÔÚ 2005-07-30ÁùµÄ 12:00 +0000£¬freebsd-hackers-request@freebsd.orgд > µÀ£º > > Pawel Jakub Dawidek wrote: > > > > > This is not not possible with current GBDE. > > > I've patches which allows this here: > > > > > > http://people.freebsd.org/~pjd/patches/gbde.patch > > > > I fail to see how this allows an encryted root-FS, it doesn't add gbde > > support to boot0(ext) or to the loader. It needs access to an unencrypted > > kernel. I don't think this is what Ronnel had in mind (overlooking the fact > > that his suggestion to save the passphrase in the loader is insecure). > > > > Bye, > > Alexander. > > > µç×ÓÓʼþ ¸½¼þ > ÔÚ 2005-07-30ÁùµÄ 12:00 +0000£¬freebsd-hackers-request@freebsd.orgд > µÀ£º > > Hello everyone, > > > > I developed the patch for 7-CURRENT (also should apply cleanly to 6) > > that implements swap reservation accounting and allows to cap the > > allocation of anonymous memory to the available swap. Effectively, > > this allows to optionally turn off overcommit feature of the VM. > > > > Besides this, per-user swap reservation limits could be > > enforced. Corresponding capability is added to the login.conf database. > > > > For some description of the implementation, TODO list and patch > > itself, please see http://kostikbel.narod.ru > > > > This is my first touch of the FreeBSD code, you valuable comments and > > reviews would be greatly appreciated. > > > > Best regards, > > Kostik Belousov > > > > > µç×ÓÓʼþ ¸½¼þ > ÔÚ 2005-07-30ÁùµÄ 12:00 +0000£¬freebsd-hackers-request@freebsd.orgд > µÀ£º > > On Fri, Jul 29, 2005 at 12:24:44PM +0800, Xin LI wrote: > > > My points to have /usr/ports in the mtree is for convience that users > > > creating a jail that is intended to mount the ports tree from the host > > > system, without having to create their own in every instances. What > > > do you think about this? > > > > My point of view is that it blurs the distinction between base system > > and local extensions. It surely is convient, but I often scratch my > > head when I find empty directories on my system. Don't you start to > > wonder what those directories exist for? > > > > Back to the given example of mounting ports into multiple jails, > > wouldn't you normally have the ports tree only in one jail and use that > > for all building? The dinoex scripts come to my mind. > > > > Joerg > > > µç×ÓÓʼþ ¸½¼þ > ÔÚ 2005-07-30ÁùµÄ 12:00 +0000£¬freebsd-hackers-request@freebsd.orgд > µÀ£º > > Hi, Joerg, > > > > On Fri, Jul 29, 2005 at 04:43:49PM +0200, Joerg Sonnenberger wrote: > > > On Fri, Jul 29, 2005 at 12:24:44PM +0800, Xin LI wrote: > > > > My points to have /usr/ports in the mtree is for convience that users > > > > creating a jail that is intended to mount the ports tree from the host > > > > system, without having to create their own in every instances. What > > > > do you think about this? > > > > > > My point of view is that it blurs the distinction between base system > > > and local extensions. It surely is convient, but I often scratch my > > > head when I find empty directories on my system. Don't you start to > > > wonder what those directories exist for? > > > > I think I won't if the directory is a well-known one... But I buy > > your "blur the distinction between base system and local extension" :-) > > > > > Back to the given example of mounting ports into multiple jails, > > > wouldn't you normally have the ports tree only in one jail and use that > > > for all building? The dinoex scripts come to my mind. > > > > This seems to be true only when the jail is provided for one single > > administrator. For a virtual hosting environment, you will want to > > run different OS versions inside jail (the development hosting box > > runs FreeBSD 6.0, 5.4, 5.3, 4.11 and 4.8 inside different jails), > > and just let the users to choose which application they want. Of > > course this needs some tricks like WRKDIRPREFIX tweaking > > inside every jails, and FETCH_CMD to point a hook that fetches > > all distfiles on behalf of the user, with all read-only ports tree. > > > > I will think about other solutions of the usr/ports handling, then. > > Thanks for the input! > > > > Cheers, > µç×ÓÓʼþ ¸½¼þ > ÔÚ 2005-07-30ÁùµÄ 12:00 +0000£¬freebsd-hackers-request@freebsd.orgд > µÀ£º > > Dear colleagues, > > > > can anyone please point me why mdconfig method for tmpmfs > > is malloc-backed instead of swap-backed, and it is hardcoded into rc.subr? > > > > Are swap-backed file systems so inefficient? If no, why not move -M to > > /etc/defaultc/rc.conf so admin can override this behaviour? > > > > Sincerely, > > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > > ------------------------------------------------------------------------ > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > > ------------------------------------------------------------------------ > > > µç×ÓÓʼþ ¸½¼þ > ÔÚ 2005-07-30ÁùµÄ 12:00 +0000£¬freebsd-hackers-request@freebsd.orgд > µÀ£º > > On Fri, Jul 29, 2005 at 09:41:24PM +0400, Dmitry Morozovsky wrote: > > > Dear colleagues, > > > > > > can anyone please point me why mdconfig method for tmpmfs > > > is malloc-backed instead of swap-backed, and it is hardcoded into rc.subr? > > > > > > Are swap-backed file systems so inefficient? If no, why not move -M to > > > /etc/defaultc/rc.conf so admin can override this behaviour? > > > > Diskless systems may not have swap - the default is required as is. > > Don't know about beeing hardcoded. > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Wang Jun@ Atmos. Dep. of NJU. China. GNU is Not Unix, BSD is Powerful, Ada is Beautiful, Nju is Graceful. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 30 14:34:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 BCE6616A41F for ; Sat, 30 Jul 2005 14:34:49 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17CC943D46 for ; Sat, 30 Jul 2005 14:34:48 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 3707 invoked by uid 1003); 30 Jul 2005 14:35:13 -0000 Received: from ryans@gamersimpact.com by mailserv1.neuroflux.com by uid 89 with qmail-scanner-1.22 (clamscan: 0.65. spamassassin: 2.60. Clear:RC:1(63.229.214.54):. Processed in 1.321158 secs); 30 Jul 2005 14:35:13 -0000 Received: from unknown (HELO ?192.168.0.3?) (63.229.214.54) by mailserv1.neuroflux.com with SMTP; 30 Jul 2005 14:35:12 -0000 Message-ID: <42EB9005.8080200@gamersimpact.com> Date: Sat, 30 Jul 2005 09:34:45 -0500 From: Ryan Sommers User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <42E9A0E7.40703@centtech.com> In-Reply-To: <42E9A0E7.40703@centtech.com> Content-Type: text/plain; charset=x-gbk; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2005 14:34:49 -0000 Eric Anderson wrote: > I've very interested in learning about FreeBSD's implementation of > vfs/buffer cache/fs archicture. I've read through mckusick@'s chapter > in the Design and Implmentation of FreeBSD book, and I've read the UNIX > Filesystems book cover to cover. > > What I'd like to see/read/understand, is how FreeBSD in particular is > put together in this regard, and then I'd like to go about writing a > very very simple filesystem as a learning excercise. > > Can anyone give me some pointers? Would anyone be willing to guide me > along in my quest by answering questions (off list if preferred, or on > list), etc? > > Thanks in advance for the hints/input! > Eric > > Best place would be the source code itself. I think the nullfs implementation would be a good place (src/sys/fs/nullfs). I thought I also remembered some little article on writing an FS for freebsd, finding it is eluding me though. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 30 15:24:16 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6CDF916A41F; Sat, 30 Jul 2005 15:24:16 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34B1E43D45; Sat, 30 Jul 2005 15:24:16 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j6U6gn5m057456; Fri, 29 Jul 2005 23:42:50 -0700 (PDT) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j6U6ghCF057455; Fri, 29 Jul 2005 23:42:43 -0700 (PDT) (envelope-from www) Date: Fri, 29 Jul 2005 23:42:43 -0700 (PDT) Message-Id: <200507300642.j6U6ghCF057455@marlena.vvi.at> To: anderson@centtech.com From: "ALeine" Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2005 15:24:16 -0000 Eric Anderson wrote: > I've very interested in learning about FreeBSD's implementation > of vfs/buffer cache/fs archicture. You may want to download the following graphical overview of the UFS/FFS filesystem that was made by Poul-Henning Kamp earlier this year, it's very useful: http://phk.freebsd.dk/misc/ufs.pdf If you want to print it out you'll need 18 sheets of paper. You may also want to use something like doxygen (devel/doxygen in the ports tree) to generate source code graphs and make browsing through source code easier. Another resource that you may find helpful is Robert Watson's FXR site: http://fxr.watson.org ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 30 19:59:40 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 6F46216A41F for ; Sat, 30 Jul 2005 19:59:40 +0000 (GMT) (envelope-from jbaggs@san.rr.com) Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 290B843D45 for ; Sat, 30 Jul 2005 19:59:40 +0000 (GMT) (envelope-from jbaggs@san.rr.com) Received: from [10.0.10.5] (cpe-24-165-11-242.san.res.rr.com [24.165.11.242]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id j6UJxbFf025945 for ; Sat, 30 Jul 2005 12:59:38 -0700 (PDT) Message-ID: <42EBDC29.2070603@san.rr.com> Date: Sat, 30 Jul 2005 12:59:37 -0700 From: Jeremy Baggs User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050725) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: UFS endian-ness X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2005 19:59:40 -0000 I was wondering if anyone has done any recent work with, or knows how (non-)trival it would be adding support for mounting big-endian UFS filesystems, such as the one in use on os X. Jeremy From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 30 20:17:57 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 0C60116A41F for ; Sat, 30 Jul 2005 20:17:57 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A019043D45 for ; Sat, 30 Jul 2005 20:17:56 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 504F935707 for ; Sat, 30 Jul 2005 22:17:55 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id DB8B25440; Sat, 30 Jul 2005 22:15:49 +0200 (CEST) Date: Sat, 30 Jul 2005 22:15:48 +0200 From: Joerg Sonnenberger To: hackers@freebsd.org Message-ID: <20050730201548.GA19593@britannica.bec.de> Mail-Followup-To: hackers@freebsd.org References: <42EBDC29.2070603@san.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42EBDC29.2070603@san.rr.com> User-Agent: Mutt/1.5.6i Cc: Subject: Re: UFS endian-ness X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2005 20:17:57 -0000 On Sat, Jul 30, 2005 at 12:59:37PM -0700, Jeremy Baggs wrote: > I was wondering if anyone has done any recent work with, or knows how > (non-)trival it would be adding support for mounting big-endian UFS > filesystems, such as the one in use on os X. Check NetBSD, I think they have that. Joerg From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 30 22:50:56 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 410C916A421 for ; Sat, 30 Jul 2005 22:50:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67D9743D46 for ; Sat, 30 Jul 2005 22:50:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j6UMo4xO074656; Sat, 30 Jul 2005 16:50:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 30 Jul 2005 16:50:54 -0600 (MDT) Message-Id: <20050730.165054.99724167.imp@bsdimp.com> To: jbaggs@san.rr.com From: "M. Warner Losh" In-Reply-To: <42EBDC29.2070603@san.rr.com> References: <42EBDC29.2070603@san.rr.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: UFS endian-ness X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2005 22:50:56 -0000 In message: <42EBDC29.2070603@san.rr.com> Jeremy Baggs writes: : I was wondering if anyone has done any recent work with, or knows how : (non-)trival it would be adding support for mounting big-endian UFS : filesystems, such as the one in use on os X. It is trivial. NetBSD just does the swapping on input or output and the diffs to do it were small. Warner