From owner-freebsd-current Sun Dec 9 1:50:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 4B44037B419 for ; Sun, 9 Dec 2001 01:50:06 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id KAA23743 for freebsd-current@FreeBSD.ORG; Sun, 9 Dec 2001 10:50:04 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fB99LTB46175 for freebsd-current@FreeBSD.ORG; Sun, 9 Dec 2001 10:21:29 +0100 (MET) (envelope-from j) Date: Sun, 9 Dec 2001 10:21:29 +0100 From: Joerg Wunsch To: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011209102129.F97235@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-current@FreeBSD.ORG References: <200112082356.fB8NuII32772@uriah.heep.sax.de> <20011209010912.F405A39EC@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011209010912.F405A39EC@overcee.netplex.com.au>; from peter@wemm.org on Sat, Dec 08, 2001 at 05:09:11PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As Peter Wemm wrote: > There shouldn't *be* bootblocks on non-boot disks. > > dd if=/dev/zero of=/dev/da$n count=1 > > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". All my disks have bootblocks and (spare) boot partitions. All the bootblocks are DD mode. I don't see any point in using obsolete fdisk tables. (There's IMHO only one purpose obsolete fdisk tables are good for, co-operation with other operating systems in the same machine. None of my machines uses anything else than FreeBSD.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 3: 0: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from FLA9Aaa003.fko.mesh.ad.jp (FLA9Aaa003.fko.mesh.ad.jp [61.193.66.195]) by hub.freebsd.org (Postfix) with SMTP id 8487C37B41B for ; Sun, 9 Dec 2001 03:00:01 -0800 (PST) Message-ID: <20011209.1944240894.babaq@haisin-010002-if.syo-ten.com> Date: Sun, 09 Dec 2001 19:44:27 +0900 From: haisin-010002@if.syo-ten.com Subject: =?ISO-2022-JP?B?GyRCkXQlaSVWISYlXiU4JUQlL5BzGyhC?= MIME-Version: 1.0 X-Mail-Agent: BSMTP DLL Jan 13 2001 by Tatsuo Baba Content-Type: text/plain; charset=ISO-2022-JP To: undisclosed-recipients:; Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG $B$"$C$?$+$$29$b$j;}$C$F$^$9$+!)(B $B4($$?4$rKd$a$F$/$l$k$=$s$J=P2q$$$,$3$3$K$O$"$j$^$9!#(B $B$?$a$7$K$"$J$?$N5$;}$A$r=q$-9~$s$G$4$i$s(B $B4j$$$O$+$J$i$:3p$$$^$9$h!*(B Http://www.if-j.net $B=P2q$$7O%5%$%H!V%$%U!W$G$9!#(B $B$"$J$?$KKbK!$r%F%/%^%/%^%d%3%s‘{(B $B=w@-L5NA$5$i$K%-%c%C%7%g%P%C%/!*(B $BCK@-$b#3#0%]%$%s%HL5NACf!*(B $B7HBSEEOC$+$4<+Bp$NEEOCHV9f$GEPO?$7$F$/$@$5$$!#(B $B%"%I%l%9EyHs8x3+$G$9$N$G0B?4$7$F$4MxMQ$/$@$5$$!#(B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 3: 3:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by hub.freebsd.org (Postfix) with ESMTP id 7002E37B416 for ; Sun, 9 Dec 2001 03:03:07 -0800 (PST) Received: by teletubbie.het.net.je (Postfix, from userid 500) id 2C0981B251; Sun, 9 Dec 2001 12:03:06 +0100 (CET) Date: Sun, 9 Dec 2001 12:03:05 +0100 To: freebsd-current@FreeBSD.ORG Subject: Re: send_packet: No buffer space available Message-ID: <20011209120305.B77884@teletubbie.het.net.je> References: <20011121160116.GA6891@webcom.it> <20011121184318.A64569@technokratis.com> <20011126164901.GA554@webcom.it> <20011126131407.A7467@technokratis.com> <20011126182007.GB554@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011126182007.GB554@webcom.it>; from andrea@webcom.it on Mon, Nov 26, 2001 at 07:20:07PM +0100 From: walter@belgers.com (Walter Belgers) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andrea Campi wrote: > > Well, you're sending out packets faster than your hardware can > > transmit them. > So, at least now we know what to answer if the question arises again (I > has several people who send 'me too' emails to me). I was having the same problem on my 4.4-RELEASE box. After swapping the Digital (dc) ethernet card for a 3COM (xl) one (and getting rid of a few bogus route entries), the messages stopped appearing and the system has been running fine ever since. I haven't checked if the digital card works well in another box, so I'm not sure if it's the driver, the card or the route entries. Cheers, Walter. -- Walter Belgers "Si hoc signum legere potes, operis boni in rebus walter@belgers.com Latinis alacribus et fructuosis potiri potes!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 4: 1:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id AF4BD37B416 for ; Sun, 9 Dec 2001 04:01:41 -0800 (PST) Received: (qmail 44737 invoked by uid 1001); 9 Dec 2001 12:01:39 +0000 (GMT) To: joerg_wunsch@uriah.heep.sax.de, j@uriah.heep.sax.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c From: sthaug@nethelp.no In-Reply-To: Your message of "Sun, 9 Dec 2001 10:21:29 +0100" References: <20011209102129.F97235@uriah.heep.sax.de> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 09 Dec 2001 13:01:39 +0100 Message-ID: <44735.1007899299@verdi.nethelp.no> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) There are very good reasons NOT to use DD mode if you use certain types of Adaptec SCSI controllers - they simply won't boot from DD. Aside from that, FreeBSD needs to have *one* recommendation for disks, anything else creates too much confusion. It is certainly my impression that the recommendation has been NOT using DD for the IA32 architecture for quite a while now. (The other day a coworker of mine wanted to use DD for some IBM DTLA disks, because he'd heard that the disks performed better that way - something to do with scatter-gather not working right unless you used DD. I'm highly skeptical about this since I have my own measurements from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they show the disks performing extremely well. Anybody else want to comment on this?) Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 4:23:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id A163337B416 for ; Sun, 9 Dec 2001 04:23:12 -0800 (PST) Received: from cain.gsoft.com.au (root@midget.dons.net.au [203.31.81.7]) by midget.dons.net.au (8.11.6/8.11.6) with ESMTP id fB9CN0M81383; Sun, 9 Dec 2001 22:53:01 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.5.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <44735.1007899299@verdi.nethelp.no> Date: Sun, 09 Dec 2001 22:52:58 +1030 (CST) From: "Daniel O'Connor" To: sthaug@nethelp.no Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Cc: freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 09-Dec-2001 sthaug@nethelp.no wrote: > (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you used > DD. I'm highly skeptical about this since I have my own measurements > from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they > show the disks performing extremely well. Anybody else want to comment > on this?) Sounds like an Old Wives Tale to me. I don't understand the need some people have for using something that is labelled as DANGEROUS. No, it won't hurt your cats but you may lose hair from using it, and for what benefit? NONE! --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 6:51:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id AB8C737B417 for ; Sun, 9 Dec 2001 06:51:44 -0800 (PST) Received: (from mckay@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id fB9Epi902020 for freebsd-current@freebsd.org; Sun, 9 Dec 2001 06:51:44 -0800 (PST) (envelope-from mckay) Date: Sun, 9 Dec 2001 06:51:44 -0800 (PST) From: Message-Id: <200112091451.fB9Epi902020@freefall.freebsd.org> To: freebsd-current@freebsd.org Subject: Patch to cp to correct PR#27970 and PR#31633, for review Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! Normally, I'd just commit this and wait for the flak, but since I'm changing the default behaviour when copying directories, I thought people might care. This patch fixes PR#27970 (directory times not preserved with -p) and PR#31633 (non-empty read-only directories not copied). It does so by setting times and permissions on directories in the post-order phase of the file hierarchy traversal. Review point 1: there is a minor functional change with this patch: umask is now applied to copied directories (assuming -p not specified) $ umask 027 $ mkdir foo $ chmod 777 foo $ cp -r foo bar1 $ patchedcp -r foo bar2 $ ls -ld foo bar? drwxrwxrwx 2 mckay wheel 512 10 Dec 00:29 foo drwxrwxrwx 2 mckay wheel 512 10 Dec 00:29 bar1 drwxr-x--- 2 mckay wheel 512 10 Dec 00:29 bar2 $ I believe the new behaviour is correct. It follows SUSv2, and matches GNU cp. I know of nothing that will fail with this change. Review point 2: in order to avoid a chmod() per directory in the normal case, there is a complicated conditional to set curr->fts_number. If I changed this to simply: curr->fts_number = dne; then readability and testability would be enhanced, at the cost of a couple of unnecessary chmod() system calls. I'm leaning towards ditching the conditional. Anybody against? I'll commit this is a day or two, unless there are any problems. Also, there are a number of other open PRs against cp which I hope to commit fixes for. In particular PR#17389 should be fixed. Oh, and the typo fix to util.c is sort of a freebie. :-) Stephen. PS Some people use -audit for code reviews. But the charter claims it is for security auditing. Which is right? Index: cp.c =================================================================== RCS file: /cvs/src/bin/cp/cp.c,v retrieving revision 1.27 diff -u -r1.27 cp.c --- cp.c 2001/06/19 15:41:54 1.27 +++ cp.c 2001/12/09 14:50:39 @@ -248,7 +248,15 @@ FTSENT *curr; int base = 0, dne, badcp, nlen, rval; char *p, *target_mid; + mode_t mask; + /* + * Keep an inverted copy of the umask, for use in correcting + * permissions on created directories when not using -p. + */ + mask = ~umask(0777); + umask(~mask); + if ((ftsp = fts_open(argv, fts_options, mastercmp)) == NULL) err(1, NULL); for (badcp = rval = 0; (curr = fts_read(ftsp)) != NULL; badcp = 0) { @@ -264,8 +272,6 @@ warnx("%s: directory causes a cycle", curr->fts_path); badcp = rval = 1; continue; - case FTS_DP: /* Ignore, continue. */ - continue; } /* @@ -323,6 +329,25 @@ STRIP_TRAILING_SLASH(to); } + if (curr->fts_info == FTS_DP) { + /* + * We are finished copying to this directory. If + * -p is in effect, set permissions and timestamps. + * Otherwise, if we created this directory, set the + * correct permissions, limited by the umask. + */ + if (pflag) + rval = setfile(curr->fts_statp, 0); + else if (curr->fts_number) { + mode_t perm = curr->fts_statp->st_mode & mask; + if (chmod(to.p_path, perm)) { + warn("chmod: %s", to.p_path); + rval = 1; + } + } + continue; + } + /* Not an error but need to remember it happened */ if (stat(to.p_path, &to_stat) == -1) dne = 1; @@ -376,16 +401,19 @@ err(1, "%s", to.p_path); } /* - * If not -p and directory didn't exist, set it to be - * the same as the from directory, umodified by the - * umask; arguably wrong, but it's been that way - * forever. + * Arrange to correct directory permissions later + * (in the post-order phase) if this is a new + * directory and the permissions aren't the final + * ones we want yet. Note that mkdir() does not + * honour setuid, setgid nor sticky bits, but we + * normally want to preserve them on directories. */ - if (pflag && setfile(curr->fts_statp, 0)) - badcp = rval = 1; - else if (dne) - (void)chmod(to.p_path, - curr->fts_statp->st_mode); + { + mode_t mode = curr->fts_statp->st_mode; + curr->fts_number = dne && + ((mode & (S_ISUID|S_ISGID|S_ISTXT)) || + ((mode | S_IRWXU) & mask) != (mode & mask)); + } break; case S_IFBLK: case S_IFCHR: Index: utils.c =================================================================== RCS file: /cvs/src/bin/cp/utils.c,v retrieving revision 1.31 diff -u -r1.31 utils.c --- utils.c 2001/06/19 15:41:54 1.31 +++ utils.c 2001/12/09 14:17:28 @@ -293,7 +293,7 @@ if (!gotstat || fs->st_mode != ts.st_mode) if (fd ? fchmod(fd, fs->st_mode) : chmod(to.p_path, fs->st_mode)) { - warn("chown: %s", to.p_path); + warn("chmod: %s", to.p_path); rval = 1; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 10:50:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id D334937B416 for ; Sun, 9 Dec 2001 10:50:44 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id TAA03571 for freebsd-current@FreeBSD.ORG; Sun, 9 Dec 2001 19:50:43 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fB9Ik6H56560 for freebsd-current@FreeBSD.ORG; Sun, 9 Dec 2001 19:46:06 +0100 (MET) (envelope-from j) Date: Sun, 9 Dec 2001 19:46:06 +0100 From: Joerg Wunsch To: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011209194606.I97235@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-current@FreeBSD.ORG References: <20011209102129.F97235@uriah.heep.sax.de> <44735.1007899299@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44735.1007899299@verdi.nethelp.no>; from sthaug@nethelp.no on Sun, Dec 09, 2001 at 01:01:39PM +0100 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As sthaug@nethelp.no wrote: > There are very good reasons NOT to use DD mode if you use certain > types of Adaptec SCSI controllers - they simply won't boot from DD. Never seen. All my SCSI controllers so far booted from my disks (obviously :). I figure from Peter's comment in that piece of code that the original (386BSD 0.0 inherited) DD mode fake fdisk table apparently had some poor (faked) values inside that could upset some BIOSes. That's bad, and IMHO we should fix what could be fixed, but without dropping that feature entirely (see below). Still, it's my opinion that these BIOSes are simply broken: interpretation of the fdisk table has always been in the realm of the boot block itself. The BIOS should decide whether a disk is bootable or not by looking at the 0x55aa signature at the end, nothing else. Think of the old OnTrack Disk Manager that extended the fdisk table to 16 slots -- nothing the BIOS could ever even handle. It was in the realm of the boot block to interpret it. > Aside from that, FreeBSD needs to have *one* recommendation for > disks, anything else creates too much confusion. DD mode has never been a recommendation. It is for those who know what it means. I'm only against the idea to silently drop support for it... fdisk tables are something that has been designed in the previous millenium, and i think nobody is going to argue about it that they are rather a mis-design from the beginning (or even no design at all, but an ad-hoc implementation). Two different values for the same (which could become conflicting, thus making disks unportable between different controllers), not enough value space to even remotely cover the disks of our millenium, enforcement of something they call `geometry' which isn't even remotely related to the disks' geometry anymore at all, far too few possible entries anyway, ... FreeBSD is in a position where it doesn't strictly require the existence of such an obsoleted implementation detail, so we should users leave the freedom of decision. Again, it has never been the recommendation (well, at least not after 386BSD 0.0 :), and i normally wouldn't recommend it to the innocent user. But we should not break it either. > (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you > used DD. [...]) As much as i personally prefer DD mode: that's an urban legend. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 10:50:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 96FB137B419 for ; Sun, 9 Dec 2001 10:50:47 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id TAA03572 for freebsd-current@FreeBSD.ORG; Sun, 9 Dec 2001 19:50:46 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fB9IoDk56599 for freebsd-current@FreeBSD.ORG; Sun, 9 Dec 2001 19:50:13 +0100 (MET) (envelope-from j) Date: Sun, 9 Dec 2001 19:50:13 +0100 From: Joerg Wunsch To: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011209195013.J97235@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-current@FreeBSD.ORG References: <44735.1007899299@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from doconnor@gsoft.com.au on Sun, Dec 09, 2001 at 10:52:58PM +1030 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As Daniel O'Connor wrote: > I don't understand the need some people have for using something > that is labelled as DANGEROUS. Historically, it hasn't been labelled that, it only later became common terminology for it -- in the typical half-joking manner. > No, it won't hurt your cats but you may lose hair from using it, and > for what benefit? NONE! See my other reply about fdisk tables: they are a misdesign from the beginning. The single most wanted feature it buys you is the ability to completely forget the term `geometry' with your disks: the very first sectors of a disk always have the same BIOS int 0x13 representation, regardless of what your BIOS/controller thinks the `geometry' might be. Thus, those disks are basically portable between controller BIOSes. (Modulo those newer broken BIOSes that believe eggs must be smarter than hens -- see my other article for an opinion.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 12:10: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id DF74037B405 for ; Sun, 9 Dec 2001 12:10:00 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB9KFJe01121; Sun, 9 Dec 2001 12:15:21 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112092015.fB9KFJe01121@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Joerg Wunsch Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c In-reply-to: Your message of "Sun, 09 Dec 2001 10:21:29 +0100." <20011209102129.F97235@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Dec 2001 12:15:19 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > As Peter Wemm wrote: > > > There shouldn't *be* bootblocks on non-boot disks. > > > > dd if=/dev/zero of=/dev/da$n count=1 > > > > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". > > All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) Since I tire of seeing people hit this ignorant opinion in the list archives, I'll just offer the rational counterpoints. - The MBR partition table is not "obsolete", it's a part of the PC architecture specification. - You omit the fact that many peripheral device vendors' BIOS code looks for the MBR partition table, and will fail if it's not present or incorrect. You do realise that "DD" mode does include a (invalid) MBR partition table (now valid, courtesy of a long-needed fix), right? I'd love to never hear those invalid, unuseful, misleading opinions from you again. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 12:13:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 255BA37B416 for ; Sun, 9 Dec 2001 12:13:42 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB9KIpe01166; Sun, 9 Dec 2001 12:18:52 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112092018.fB9KIpe01166@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: sthaug@nethelp.no Cc: joerg_wunsch@uriah.heep.sax.de, j@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c In-reply-to: Your message of "Sun, 09 Dec 2001 13:01:39 +0100." <44735.1007899299@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Dec 2001 12:18:51 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you used > DD. I'm highly skeptical about this since I have my own measurements > from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they > show the disks performing extremely well. Anybody else want to comment > on this?) Since scatter-gather has nothing to do with the disk (it's a feature of the disk controller's interface to host memory), I think this coworker of yours is delusional. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 12:28:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id F257537B416 for ; Sun, 9 Dec 2001 12:28:09 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB9KXQe01376; Sun, 9 Dec 2001 12:33:28 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112092033.fB9KXQe01376@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Yiping Chen Cc: "'current@FreeBSD.org'" Subject: Re: Question about Freebsd driver In-reply-to: Your message of "Fri, 07 Dec 2001 22:43:28 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Dec 2001 12:33:26 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I have a question about Freebsd driver. If we want to support some > options in driver(like speed and duplex mode setting) , user can use this > option to change driver configurations. I am not sure whether freebsd > driver support driver parameter or something else. Can you give me some > suggestions? Thanks!! From the question, I infer that you are referring to Ethernet device drivers. In the FreeBSD model, devices fit into one or more of a set of classes. Each class has an established, device-independant mechanism for controlling driver parameters. In the case of Ethernet drivers, parameters are controlled via the driver's ioctl interface. You should be able to find good examples of this in the source for other drivers similar to your own. If you have more specific questions, please feel free to ask them here. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 14:18:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from web73.ntx.net (x182.ntx.net [209.1.144.182]) by hub.freebsd.org (Postfix) with ESMTP id 94B8D37B416 for ; Sun, 9 Dec 2001 14:18:12 -0800 (PST) Received: (from www@localhost) by web73.ntx.net (8.8.5/8.8.5) id OAA12087; Sun, 9 Dec 2001 14:13:30 -0800 (PST) Date: Sun, 9 Dec 2001 14:13:30 -0800 (PST) Message-Id: <200112092213.OAA12087@web73.ntx.net> To: Consumer@isp.com From: MakeMoneyOnline@isp.com () Subject: Six-figure income from home, guaranteed! Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Below is the result of your feedback form. It was submitted by (MakeMoneyOnline@isp.com) on Sunday, December 9, 2001 at 14:13:28 --------------------------------------------------------------------------- To whom it may concern: Are you looking to make money online? If you're either looking for a job, tired of your existing job, eager for more pay, or just anxious to have the added freedom and independence that comes with working at home, this email could change your life. We can teach you (in under a half-hour) how to pull in a six-figure income from home... GUARANTEED, or your money back. Click below for more info http://www.instantempires.net/money2/ --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 14:20:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 00D8937B444 for ; Sun, 9 Dec 2001 14:20:08 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id XAA06033 for freebsd-current@freebsd.org; Sun, 9 Dec 2001 23:20:07 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fB9M0J660085; Sun, 9 Dec 2001 23:00:19 +0100 (MET) (envelope-from j) Date: Sun, 9 Dec 2001 23:00:19 +0100 (MET) Message-Id: <200112092200.fB9M0J660085@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <20011209102129.F97235@uriah.heep.sax.de> <200112092015.fB9KFJe01121@mass.dis.org> From: j@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c X-Original-Newsgroups: local.freebsd.current To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > - The MBR partition table is not "obsolete", it's a part of the PC > architecture specification. Its design is antique. Or rather: it's missing a design. See other mail for the reasons. For FreeBSD, it's obsolete since we don't need to rely on fdisk slices. (Or rather: it's optional. We can make good use of it when it's there, but we don't need to insist on it being there.) > You do realise that "DD" mode does include a (invalid) MBR partition > table (now valid, courtesy of a long-needed fix), right? Yes, of course, one that is basically ignored by everything. It has always been there, back since 386BSD 0.1. 386BSD 0.0 didn't recognize fdisk tables at all, but could only live on a disk by its own (as any other BSD before used to). > I'd love to never hear those invalid, unuseful, misleading opinions > from you again. ETOOMANYATTRIBUTES? :-) As long as you keep the feature of DD mode intact, i won't argue. If people feel like creating disks that aren't portable to another controller, they should do. I don't like this idea. But to be honest, see my other article: i never argued to make this the default or a recommended strategy in any form. It should only remain intact at all. Back to the subject, the current warning however, is pointless, and has the major drawback to potentially hide important console messages. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 14:50: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 8D55737B416 for ; Sun, 9 Dec 2001 14:50:05 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id fB9Mo4K15663 for current@freebsd.org; Sun, 9 Dec 2001 22:50:04 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id fB9MmjU34838 for ; Sun, 9 Dec 2001 22:48:45 GMT (envelope-from mark@grondar.za) Message-Id: <200112092248.fB9MmjU34838@grimreaper.grondar.org> To: current@freebsd.org Subject: *HEADS UP!* This means you! Date: Sun, 09 Dec 2001 22:48:44 +0000 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Now that I have your attention, please listen up, this may have some far-reaching consequences. We currently have 2 telnet sources in the src/ tree; src/crypto/telnet and the "base" telnet spread around in (src/*/*telnet*/). The "base" telnet is a complete subset of src/crypto telnet, and as a consequence of this, I want to remove the base telnet bits from the src/ tree. (Just the source, not the build infrastructure). This will be accomplished by removing the "base" sources, and building telnet without defining the AUTHENTICATION and ENCRYPTION macros. These macros are currently used with unifdef to make (by hand) the "base" telnet stuff). I'm not sure when I'll make the commit, but it will be soonish, with due fanfare. Those of you who believe that you may be in trouble with your government by having crypto in your posession (as opposed to using it), please let me know ASAP! This will make src/crypto mandatory if you want telnet(d). This will _not_ make crypto _use_ mandatory. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 16:20:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 4CDC637B41B for ; Sun, 9 Dec 2001 16:20:27 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 9FB3B786E7; Mon, 10 Dec 2001 10:50:25 +1030 (CST) Date: Mon, 10 Dec 2001 10:50:25 +1030 From: Greg Lehey To: Daniel O'Connor Cc: sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011210105025.H83634@monorchid.lemis.com> References: <44735.1007899299@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 22:52:58 +1030, Daniel O'Connor wrote: > > On 09-Dec-2001 sthaug@nethelp.no wrote: >> (The other day a coworker of mine wanted to use DD for some IBM DTLA >> disks, because he'd heard that the disks performed better that way - >> something to do with scatter-gather not working right unless you used >> DD. I'm highly skeptical about this since I have my own measurements >> from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they >> show the disks performing extremely well. Anybody else want to comment >> on this?) > > Sounds like an Old Wives Tale to me. > > I don't understand the need some people have for using something that is > labelled as DANGEROUS. I don't understand the need some people have for labelling something as DANGEROUS when it works nearly all the time. We don't have many disks which are shared between different platforms, but that will change. As you know, I have the ability to hot swap disks between an RS/6000 platform and an ia32 platform. The RS/6000 disks will never have a Microsoft partition table on them. They will have BSD partition tables on them. Why call this dangerous? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 16:27:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 7606237B41B; Sun, 9 Dec 2001 16:27:05 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id D4756786E6; Mon, 10 Dec 2001 10:57:03 +1030 (CST) Date: Mon, 10 Dec 2001 10:57:03 +1030 From: Greg Lehey To: Joerg Wunsch , Mike Smith Cc: freebsd-current@FreeBSD.ORG Subject: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011210105703.I83634@monorchid.lemis.com> References: <20011209102129.F97235@uriah.heep.sax.de> <200112092015.fB9KFJe01121@mass.dis.org> <20011209102129.F97235@uriah.heep.sax.de> <44735.1007899299@verdi.nethelp.no> <20011209194606.I97235@uriah.heep.sax.de> <44735.1007899299@verdi.nethelp.no> <20011209195013.J97235@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200112092015.fB9KFJe01121@mass.dis.org> <20011209194606.I97235@uriah.heep.sax.de> <20011209195013.J97235@uriah.heep.sax.de> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 12:15:19 -0800, Mike Smith wrote: >> As Peter Wemm wrote: >> >>> There shouldn't *be* bootblocks on non-boot disks. >>> >>> dd if=/dev/zero of=/dev/da$n count=1 >>> >>> Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". >> >> All my disks have bootblocks and (spare) boot partitions. All the >> bootblocks are DD mode. I don't see any point in using obsolete fdisk >> tables. (There's IMHO only one purpose obsolete fdisk tables are good >> for, co-operation with other operating systems in the same machine. >> None of my machines uses anything else than FreeBSD.) > > Since I tire of seeing people hit this ignorant opinion in the list > archives, I'll just offer the rational counterpoints. > > - The MBR partition table is not "obsolete", it's a part of the PC > architecture specification. And if it's part of the PC architecture specification, it can't be obsolete? I dont see any contradiction here. > - You omit the fact that many peripheral device vendors' BIOS code looks > for the MBR partition table, and will fail if it's not present or > incorrect. What do you mean by "peripheral device"? I've never heard of disk drives having a BIOS. If you're talking about host adaptors, it's you who omit what Jörg says about it: No, on the contrary, he went into some detail on this point: On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: > > > Still, it's my opinion that these BIOSes are simply broken: > interpretation of the fdisk table has always been in the realm of the > boot block itself. The BIOS should decide whether a disk is bootable > or not by looking at the 0x55aa signature at the end, nothing else. > Think of the old OnTrack Disk Manager that extended the fdisk table to > 16 slots -- nothing the BIOS could ever even handle. It was in the > realm of the boot block to interpret it. > I agree with Jörg on this. > I'd love to never hear those invalid, unuseful, misleading opinions > from you again. I'd love to never have to see this level of invective poured onto what was previously a calm discussion. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 16:41:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 624D537B419 for ; Sun, 9 Dec 2001 16:41:24 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBA0fNa72560; Sun, 9 Dec 2001 17:41:23 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBA0fLM15940; Sun, 9 Dec 2001 17:41:22 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112100041.fBA0fLM15940@harmony.village.org> To: "Alan Edmonds" Subject: Re: wi driver: firmware %i.%i problem? Cc: current@freebsd.org In-reply-to: Your message of "Sat, 08 Dec 2001 23:42:36 GMT." References: Date: Sun, 09 Dec 2001 17:41:21 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message "Alan Edmonds" writes: : I'm not sure if the %i is a problem the kernel printf or I didn't checkin the small patch to the kernel printf for %i support yet. Ignore it for now. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 16:42:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 8C4B737B416 for ; Sun, 9 Dec 2001 16:42:14 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBA0g8a72568; Sun, 9 Dec 2001 17:42:08 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBA0g7M15960; Sun, 9 Dec 2001 17:42:07 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112100042.fBA0g7M15960@harmony.village.org> To: Alfred Perlstein Subject: Re: wi driver: firmware %i.%i problem? Cc: Alan Edmonds , current@freebsd.org In-reply-to: Your message of "Sat, 08 Dec 2001 17:47:42 CST." <20011208174742.L92148@elvis.mu.org> References: <20011208174742.L92148@elvis.mu.org> <200112080216.fB82GhM02156@harmony.village.org> Date: Sun, 09 Dec 2001 17:42:07 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011208174742.L92148@elvis.mu.org> Alfred Perlstein writes: : %i is because I lost a flamewar to get %i added to kernel printf, : it has been fixed. I was thinking of just committing the one line change and avoiding the flamewar :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 16:43:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 0EB5437B416 for ; Sun, 9 Dec 2001 16:43:54 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210004340.MTTM5859.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Mon, 10 Dec 2001 00:43:40 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBA0hos31910 for ; Sun, 9 Dec 2001 16:43:50 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 6703C3810; Sun, 9 Dec 2001 16:43:50 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Joerg Wunsch Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c In-Reply-To: <20011209102129.F97235@uriah.heep.sax.de> Date: Sun, 09 Dec 2001 16:43:50 -0800 From: Peter Wemm Message-Id: <20011210004350.6703C3810@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Joerg Wunsch wrote: > As Peter Wemm wrote: > > > There shouldn't *be* bootblocks on non-boot disks. > > > > dd if=/dev/zero of=/dev/da$n count=1 > > > > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". > > All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) The problem is, that you **are** using fdisk tables, you have no choice. DD mode included a *broken* fdisk table that specified an illegal geometry. This illegal geometry was the reason why Thinkpad Laptops would wedge solid when you installed FreeBSD on it. This illegal geometry is the reason why FreeBSD disks wedge solid any EFI system unless you remove the illegal geometry tables. This illegal geometry causes divide by zero errors in a handful of scsi bioses from Adaptec. This illegal geometry causes divide by zero errors in a handful of scsi bioses from NCR/Symbios. This is why it is called dangerous. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 16:49:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D14B437B41C for ; Sun, 9 Dec 2001 16:49:15 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBA0nER41709; Sun, 9 Dec 2001 16:49:14 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 16:49:14 -0800 (PST) From: Matthew Dillon Message-Id: <200112100049.fBA0nER41709@apollo.backplane.com> To: Peter Wemm Cc: Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c References: <20011210004350.6703C3810@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :This illegal geometry causes divide by zero errors in a handful of scsi :bioses from Adaptec. : :This illegal geometry causes divide by zero errors in a handful of scsi :bioses from NCR/Symbios. : :This is why it is called dangerous. : :Cheers, :-Peter :-- :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au Handful? I'm taking my life in my hands if I DD a DELL machine. BEWM! As I found out the hard way about a year ago. (Probably the Adaptec firmware but every Dell rack-mount has one so...). The machines wouldn't boot again until I pulled the physical drives and then camcontrol rescan'd them in after a CD boot. Joy. This is why I fixed disklabel -B to operate properly on slices and added a whole section to the end of 'man disklabel' to describe how to do it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 16:59:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 5D51437B405 for ; Sun, 9 Dec 2001 16:59:29 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210005919.NFIJ5859.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Mon, 10 Dec 2001 00:59:19 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBA0xSs31964 for ; Sun, 9 Dec 2001 16:59:28 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9538A3810; Sun, 9 Dec 2001 16:59:28 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c In-Reply-To: <200112092200.fB9M0J660085@uriah.heep.sax.de> Date: Sun, 09 Dec 2001 16:59:28 -0800 From: Peter Wemm Message-Id: <20011210005928.9538A3810@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Joerg Wunsch wrote: > Mike Smith wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > > architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) No, it isn't. We specifically have a copy of both the broken and fixed fdisk tables in the kernel and do a bcmp() to see if the fdisk table that is included in /boot/boot1 **uncoditionally** is in fact the dangerously dedicated table. If it is, then we specifically reject it or we end up with a disk size of 25MB (50000 sectors). > > You do realise that "DD" mode does include a (invalid) MBR partition > > table (now valid, courtesy of a long-needed fix), right? > > Yes, of course, one that is basically ignored by everything. It has > always been there, back since 386BSD 0.1. 386BSD 0.0 didn't recognize > fdisk tables at all, but could only live on a disk by its own (as any > other BSD before used to). No, it isn't ignored, BIOS'es "know" that fdisk partitions end on cylinder boundaries, and therefore can intuit what the expected geometry is for the disk in question. It does this in order to allow the CHS int 0x13 calls to work. The problem is that the int13 code only allowed for 255 heads, and the fake "end of disk" entry that is unconditionally in /boot/boot1 specified an ending head number 255 (ie: 256 heads). When this gets put into a byte register it is truncated to zero and we get divide by zero errors. > > I'd love to never hear those invalid, unuseful, misleading opinions > > from you again. > > ETOOMANYATTRIBUTES? :-) > > As long as you keep the feature of DD mode intact, i won't argue. If > people feel like creating disks that aren't portable to another > controller, they should do. I don't like this idea. We can just as easily have bootable-DD mode with a real MBR and have freebsd start on sector #2 instead of overlapping boot1 and mbr. This costs only one sector instead of 64 sectors (a whopping 32K, I'm sure that is going to break the bank on today's disks). I'd rather that we be specific about this. If somebody wants ad2e or da2e then they should not be using *any* fdisk tables at all. Ie: block 0 should be empty. The problem is that if you put /boot/boot1 in there, then suddenly it looks like a fdisk disk and we have to have ugly magic to detect it and prevent the fake table from being used. I would prefer that the fdisk table come out of /boot/boot1 so that we dont have to have it by default, and we use fdisk to install the "DD magic table" if somebody wants to make it bootable. > But to be honest, see my other article: i never argued to make this > the default or a recommended strategy in any form. It should only > remain intact at all. Back to the subject, the current warning > however, is pointless, and has the major drawback to potentially hide > important console messages. The console buffer is 32K these days. You'd have to have around 300 disks to have any real effect on the kernel. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 17:20:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id CC68E37B417 for ; Sun, 9 Dec 2001 17:20:14 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210012008.LXVJ24045.rwcrmhc53.attbi.com@peter3.wemm.org> for ; Mon, 10 Dec 2001 01:20:08 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBA1K8s32024 for ; Sun, 9 Dec 2001 17:20:08 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 8E57C3810; Sun, 9 Dec 2001 17:20:08 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mark Murray Cc: current@FreeBSD.ORG Subject: Re: *HEADS UP!* This means you! In-Reply-To: <200112092248.fB9MmjU34838@grimreaper.grondar.org> Date: Sun, 09 Dec 2001 17:20:08 -0800 From: Peter Wemm Message-Id: <20011210012008.8E57C3810@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mark Murray wrote: > Hi > > Now that I have your attention, please listen up, this may have some > far-reaching consequences. > > We currently have 2 telnet sources in the src/ tree; src/crypto/telnet > and the "base" telnet spread around in (src/*/*telnet*/). > > The "base" telnet is a complete subset of src/crypto telnet, and as > a consequence of this, I want to remove the base telnet bits from > the src/ tree. (Just the source, not the build infrastructure). > > This will be accomplished by removing the "base" sources, and building > telnet without defining the AUTHENTICATION and ENCRYPTION macros. These > macros are currently used with unifdef to make (by hand) the "base" > telnet stuff). > > I'm not sure when I'll make the commit, but it will be soonish, with > due fanfare. > > Those of you who believe that you may be in trouble with your > government by having crypto in your posession (as opposed to using > it), please let me know ASAP! This will make src/crypto mandatory > if you want telnet(d). This will _not_ make crypto _use_ mandatory. I for one will miss it. I used libexec/telnetd extensively during ia64 bootstrap (and still use it) before we had the crypto stuff going. This was all built by hand, 'make world' still isn't an option there. I also use usr.bin/telnet on other systems where SRA is constantly getting in my face and annoying the !^@#%!@^#!# out of me. I really dont see that this has to be done this way. FreeBSD committers catch on to quirks in the tree pretty quickly. I would much rather that the unifdef step marked the generated files more prominantly so that we didn't have accidents. It would be a shame to complicate things when it just takes a bit of committer education. How about making the unifdef: targets whack on large "BEWARE! GENERATED FILE!" warnings all over the beginning and end of each of them instead? Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 18:27:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id A3FEF37B416; Sun, 9 Dec 2001 18:27:10 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBA2Wce04656; Sun, 9 Dec 2001 18:32:38 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112100232.fBA2Wce04656@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: Joerg Wunsch , Mike Smith , freebsd-current@FreeBSD.org Subject: Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c) In-reply-to: Your message of "Mon, 10 Dec 2001 10:57:03 +1030." <20011210105703.I83634@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Sun, 09 Dec 2001 18:32:38 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: > > > > > > Still, it's my opinion that these BIOSes are simply broken: Joerg's personal opinion can go take a hike. The reality of the = situation is that this table is required, and we're going to put it there= =2E End of story. -- = =2E.. every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 18:37:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id CFD5137B405; Sun, 9 Dec 2001 18:37:15 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id F1C9A786E6; Mon, 10 Dec 2001 13:07:13 +1030 (CST) Date: Mon, 10 Dec 2001 13:07:13 +1030 From: Greg Lehey To: Mike Smith Cc: Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011210130713.C63585@monorchid.lemis.com> References: <20011210105703.I83634@monorchid.lemis.com> <200112100232.fBA2Wce04656@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112100232.fBA2Wce04656@mass.dis.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 18:32:38 -0800, Mike Smith wrote: >> On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: >>> >>> >>> Still, it's my opinion that these BIOSes are simply broken: > > Joerg's personal opinion can go take a hike. The reality of the > situation is that this table is required, and we're going to put it there. The reality of the situation is far from being clear. The only thing I can see is that you're trying to dictate things without adequate justification. You should reconsider that attitude. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 18:46:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id CF91A37B417; Sun, 9 Dec 2001 18:46:21 -0800 (PST) Received: from pool0370.cvx22-bradley.dialup.earthlink.net ([209.179.199.115] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DGSP-0002Ja-00; Sun, 09 Dec 2001 18:46:18 -0800 Message-ID: <3C142200.1746FFA2@mindspring.com> Date: Sun, 09 Dec 2001 18:46:24 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: Daniel O'Connor , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) References: <44735.1007899299@verdi.nethelp.no> <20011210105025.H83634@monorchid.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg Lehey wrote: [ ... IBM DTLA drives ... ] IBM DTLA drives are known to rotate fast enough near the spindle that the sustained write speed exceeds the ability of the controller electronics to keep up, and results in crap being written to disk. This is not often a problem with windows, the FS of shich fills sectors in towards the spindle, so you only hit the problem when you near the "disk full" state. Do a Google/Tom's Hardware search to reassure yourself that I am not smoking anything. > > I don't understand the need some people have for using something that is > > labelled as DANGEROUS. > > I don't understand the need some people have for labelling something > as DANGEROUS when it works nearly all the time. It's because you have to reinstall, should you want to add a second OS at a later date (e.g. Linux, or Windows). > We don't have many disks which are shared between different platforms, > but that will change. As you know, I have the ability to hot swap > disks between an RS/6000 platform and an ia32 platform. The RS/6000 > disks will never have a Microsoft partition table on them. They will > have BSD partition tables on them. Why call this dangerous? Your use is orthogonal to the most common expected usage, which is disks shared between OSs on a single platform, rather than disks shared between a single OS on multiple platforms. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 18:51:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 9C35637B417 for ; Sun, 9 Dec 2001 18:51:33 -0800 (PST) Received: from pool0370.cvx22-bradley.dialup.earthlink.net ([209.179.199.115] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DGXO-00000j-00; Sun, 09 Dec 2001 18:51:27 -0800 Message-ID: <3C142336.B639D4A9@mindspring.com> Date: Sun, 09 Dec 2001 18:51:34 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c References: <20011210005928.9538A3810@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Joerg Wunsch wrote: > > Mike Smith wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > > > architecture specification. > > > > Its design is antique. Or rather: it's missing a design. See other > > mail for the reasons. For FreeBSD, it's obsolete since we don't need > > to rely on fdisk slices. (Or rather: it's optional. We can make good > > use of it when it's there, but we don't need to insist on it being > > there.) FWIW: The MBR layout is documented in great gory detail in chapter 6 of the PReP specififcation, which I believe is now available on line from the PowerPC folks, Apple, and Motorolla, and also as an IBM "redbook". It discusses everything, including the LBA fields, and sharing disks between PPC (running in Motorolla byte order) and x86 machines (running a DOS-derived OS). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 19:49:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id DD80437B426 for ; Sun, 9 Dec 2001 19:48:55 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id fBA3laH5024647; Sun, 9 Dec 2001 22:47:36 -0500 (EST) Date: Sun, 9 Dec 2001 22:47:36 -0500 (EST) From: Daniel Eischen To: Peter Wemm Cc: Mark Murray , current@FreeBSD.ORG Subject: Re: *HEADS UP!* This means you! In-Reply-To: <20011210012008.8E57C3810@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 9 Dec 2001, Peter Wemm wrote: > Mark Murray wrote: > > Hi > > > > Now that I have your attention, please listen up, this may have some > > far-reaching consequences. > > > > We currently have 2 telnet sources in the src/ tree; src/crypto/telnet > > and the "base" telnet spread around in (src/*/*telnet*/). > > > > The "base" telnet is a complete subset of src/crypto telnet, and as > > a consequence of this, I want to remove the base telnet bits from > > the src/ tree. (Just the source, not the build infrastructure). > > > > This will be accomplished by removing the "base" sources, and building > > telnet without defining the AUTHENTICATION and ENCRYPTION macros. These > > macros are currently used with unifdef to make (by hand) the "base" > > telnet stuff). > > > > I'm not sure when I'll make the commit, but it will be soonish, with > > due fanfare. > > > > Those of you who believe that you may be in trouble with your > > government by having crypto in your posession (as opposed to using > > it), please let me know ASAP! This will make src/crypto mandatory > > if you want telnet(d). This will _not_ make crypto _use_ mandatory. > > I for one will miss it. I used libexec/telnetd extensively during ia64 > bootstrap (and still use it) before we had the crypto stuff going. This > was all built by hand, 'make world' still isn't an option there. I also > use usr.bin/telnet on other systems where SRA is constantly getting in > my face and annoying the !^@#%!@^#!# out of me. I agree. SRA is really annoying. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 19:57:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by hub.freebsd.org (Postfix) with ESMTP id 17CFD37B41B for ; Sun, 9 Dec 2001 19:57:17 -0800 (PST) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id fBA3uYp26489; Sun, 9 Dec 2001 19:56:34 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200112100356.fBA3uYp26489@ambrisko.com> Subject: Re: *HEADS UP!* This means you! In-Reply-To: <20011210012008.8E57C3810@overcee.netplex.com.au> To: Peter Wemm Date: Sun, 9 Dec 2001 19:56:33 -0800 (PST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm writes: | I for one will miss it. I used libexec/telnetd extensively during ia64 | bootstrap (and still use it) before we had the crypto stuff going. This | was all built by hand, 'make world' still isn't an option there. I also | use usr.bin/telnet on other systems where SRA is constantly getting in | my face and annoying the !^@#%!@^#!# out of me. Well, for the SRA thing you can do a "-X SRA" now that it doesn't core-dump if you do that (I submited that patch a year ago or so since it was pretty annoying!). I setup my telnetd servers with "-X SRA" so that I don't have to do it via command line. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 20: 9:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 04C0637B416 for ; Sun, 9 Dec 2001 20:09:39 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 5D1AC786E3; Mon, 10 Dec 2001 14:39:36 +1030 (CST) Date: Mon, 10 Dec 2001 14:39:36 +1030 From: Greg Lehey To: Terry Lambert Cc: Daniel O'Connor , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011210143936.F63585@monorchid.lemis.com> References: <44735.1007899299@verdi.nethelp.no> <20011210105025.H83634@monorchid.lemis.com> <3C142200.1746FFA2@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C142200.1746FFA2@mindspring.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 18:46:24 -0800, Terry Lambert wrote: > Greg Lehey wrote: > > [ ... IBM DTLA drives ... ] No, that wasn't me. > IBM DTLA drives are known to rotate fast enough near the spindle > that the sustained write speed exceeds the ability of the controller > electronics to keep up, and results in crap being written to disk. What about the cache? > This is not often a problem with windows, the FS of shich fills > sectors in towards the spindle, so you only hit the problem when you > near the "disk full" state. This sounds very unlikely. > Do a Google/Tom's Hardware search to reassure yourself that I am not > smoking anything. I think I'd rather put the shoe on the other foot. This looks like high-grade crack. Who was smoking it? >>> I don't understand the need some people have for using something that is >>> labelled as DANGEROUS. >> >> I don't understand the need some people have for labelling something >> as DANGEROUS when it works nearly all the time. I *did* write this. > It's because you have to reinstall, should you want to add a second > OS at a later date (e.g. Linux, or Windows). So all dedicated installations are dangerous? I would have to do that whether I had a Microsoft partition table or not if I had already used the entire disk for FreeBSD. >> We don't have many disks which are shared between different platforms, >> but that will change. As you know, I have the ability to hot swap >> disks between an RS/6000 platform and an ia32 platform. The RS/6000 >> disks will never have a Microsoft partition table on them. They will >> have BSD partition tables on them. Why call this dangerous? > > Your use is orthogonal to the most common expected usage, which is > disks shared between OSs on a single platform, rather than disks > shared between a single OS on multiple platforms. Expected usage is to install once and then never change it. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 21:14:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from leviathan.inethouston.net (leviathan.inethouston.net [66.64.12.249]) by hub.freebsd.org (Postfix) with ESMTP id DB31637B405 for ; Sun, 9 Dec 2001 21:14:52 -0800 (PST) Received: by leviathan.inethouston.net (Postfix, from userid 1001) id 1C4F1407622; Sun, 9 Dec 2001 23:14:54 -0600 (CST) Date: Sun, 9 Dec 2001 23:14:54 -0600 From: "David W. Chapman Jr." To: Terry Lambert Cc: current@freebsd.org Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011210051454.GA49775@leviathan.inethouston.net> Reply-To: "David W. Chapman Jr." Mail-Followup-To: Terry Lambert , current@freebsd.org References: <44735.1007899299@verdi.nethelp.no> <20011210105025.H83634@monorchid.lemis.com> <3C142200.1746FFA2@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C142200.1746FFA2@mindspring.com> User-Agent: Mutt/1.3.24i X-Operating-System: FreeBSD 4.4-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 09, 2001 at 06:46:24PM -0800, Terry Lambert wrote: > It's because you have to reinstall, should you want to add a second > OS at a later date (e.g. Linux, or Windows). I think it has more to do with the drive going on a new motherboard that might not boot with dangerously dedicated than the above. -- David W. Chapman Jr. dwcjr@inethouston.net Raintree Network Services, Inc. dwcjr@freebsd.org FreeBSD Committer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 21:29:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 53F0837B417; Sun, 9 Dec 2001 21:29:25 -0800 (PST) Received: from pool0191.cvx22-bradley.dialup.earthlink.net ([209.179.198.191] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DJ0A-00023W-00; Sun, 09 Dec 2001 21:29:19 -0800 Message-ID: <3C144836.5217C971@mindspring.com> Date: Sun, 09 Dec 2001 21:29:26 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: Daniel O'Connor , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) References: <44735.1007899299@verdi.nethelp.no> <20011210105025.H83634@monorchid.lemis.com> <3C142200.1746FFA2@mindspring.com> <20011210143936.F63585@monorchid.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg Lehey wrote: > > [ ... IBM DTLA drives ... ] > > No, that wasn't me. I didn't quote the full thing; that's what the brackets and ellipsis was for. > > IBM DTLA drives are known to rotate fast enough near the spindle > > that the sustained write speed exceeds the ability of the controller > > electronics to keep up, and results in crap being written to disk. > > What about the cache? Good point. The cache is known to not actually flush to disk when ordered to do so. See the EXT3FS article on www.ibm.com/developerworks for more details. > > This is not often a problem with windows, the FS of shich fills > > sectors in towards the spindle, so you only hit the problem when you > > near the "disk full" state. > > This sounds very unlikely. I know, doesn't it? Good thing Tom's Hardware is so thorough, or we might never have known this, with everyone on the verge of discovering it simply dismissing it as "very unlikely". 8^). > > Do a Google/Tom's Hardware search to reassure yourself that I am not > > smoking anything. > > I think I'd rather put the shoe on the other foot. This looks like > high-grade crack. Who was smoking it? Tom's Hardware, IBM, CNET, Storave Review, etc.. http://www6.tomshardware.com/storage/00q3/000821/ibmdtla-07.html http://www.storage.ibm.com/hdd/prod/deskstar.htm http://computers.cnet.com/hardware/0-1092-418-1664463.html?pn=3&lb=2&ob=0&tag=st\.co.1092.bottom.1664463-3 http://www.storagereview.com/welcome.pl?/http://www.storagereview.com/jive/sr/thread.jsp?forum=2&thread=12485 I suggest the search: http://google.yahoo.com/bin/query?p=DTLA+drive+problem&hc=0&hs=0 > > It's because you have to reinstall, should you want to add a second > > OS at a later date (e.g. Linux, or Windows). > > So all dedicated installations are dangerous? I would have to do > that whether I had a Microsoft partition table or not if I had already > used the entire disk for FreeBSD. Yes. I don't understand your point. > > Your use is orthogonal to the most common expected usage, which is > > disks shared between OSs on a single platform, rather than disks > > shared between a single OS on multiple platforms. > > Expected usage is to install once and then never change it. No, expected usage is to purchase a machine with an OS preinstalled, and then install FreeBSD/Linux/BeOS/other third party OS as an "also ran", rather than the primary OS. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 21:31:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 7256837B416; Sun, 9 Dec 2001 21:31:51 -0800 (PST) Received: from pool0191.cvx22-bradley.dialup.earthlink.net ([209.179.198.191] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DJ2c-00045M-00; Sun, 09 Dec 2001 21:31:51 -0800 Message-ID: <3C1448CE.DAF5701C@mindspring.com> Date: Sun, 09 Dec 2001 21:31:58 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: Daniel O'Connor , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) References: <44735.1007899299@verdi.nethelp.no> <20011210105025.H83634@monorchid.lemis.com> <3C142200.1746FFA2@mindspring.com> <20011210143936.F63585@monorchid.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg Lehey wrote: [ ... DTLA drives ... ] > > Do a Google/Tom's Hardware search to reassure yourself that I am not > > smoking anything. > > I think I'd rather put the shoe on the other foot. This looks like > high-grade crack. Who was smoking it? For your further amusement, here is a pointer to the class action lawsuit against IBM on the 75GXP DTLA drives: http://www.tech-report.com/news_reply.x/3035/3/ It includes a pointer to the PDF of the complaint form. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 21:39:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id A435637B41B for ; Sun, 9 Dec 2001 21:39:06 -0800 (PST) Received: from pool0191.cvx22-bradley.dialup.earthlink.net ([209.179.198.191] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DJ9U-000286-00; Sun, 09 Dec 2001 21:38:57 -0800 Message-ID: <3C144A79.D63EB257@mindspring.com> Date: Sun, 09 Dec 2001 21:39:05 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David W. Chapman Jr." Cc: current@freebsd.org Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) References: <44735.1007899299@verdi.nethelp.no> <20011210105025.H83634@monorchid.lemis.com> <3C142200.1746FFA2@mindspring.com> <20011210051454.GA49775@leviathan.inethouston.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David W. Chapman Jr." wrote: > On Sun, Dec 09, 2001 at 06:46:24PM -0800, Terry Lambert wrote: > > It's because you have to reinstall, should you want to add a second > > OS at a later date (e.g. Linux, or Windows). > > I think it has more to do with the drive going on a new motherboard > that might not boot with dangerously dedicated than the above. The concept of "dangerously dedicated" significantly predates BIOS being unable to boot such drives, either because of "antivirus" checks, or because of automatic fictitious geometry determination by Adaptec or NCR (now Symbios) controllers, which end up getting "divide by zero" errors when parsing the fictitious partition table that the FreeBSD "dangerously dedicate" mode includes in its boot block. In fact, I remember installing 386BSD "dangerously dedicated" on an AT&T WGS 386 ESDI drive, back in 1992. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 21:59:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4746F37B419; Sun, 9 Dec 2001 21:59:07 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBA5x2x43757; Sun, 9 Dec 2001 21:59:02 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 21:59:02 -0800 (PST) From: Matthew Dillon Message-Id: <200112100559.fBA5x2x43757@apollo.backplane.com> To: Terry Lambert Cc: Greg Lehey , "Daniel O'Connor" , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) References: <44735.1007899299@verdi.nethelp.no> <20011210105025.H83634@monorchid.lemis.com> <3C142200.1746FFA2@mindspring.com> <20011210143936.F63585@monorchid.lemis.com> <3C144836.5217C971@mindspring.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On google search for: deskstar 75gxp class action http://www.theregister.co.uk/content/54/22412.html http://www.pcworld.com/news/article/0,aid,67608,00.asp etc... So apparently my warning about these drives in 'man tuning' is still appropriate :-) -Matt :> > IBM DTLA drives are known to rotate fast enough near the spindle :> > that the sustained write speed exceeds the ability of the controller :> > electronics to keep up, and results in crap being written to disk. :> :> What about the cache? : :Good point. The cache is known to not actually flush to disk when :ordered to do so. See the EXT3FS article on www.ibm.com/developerworks :for more details. : :> > This is not often a problem with windows, the FS of shich fills :> > sectors in towards the spindle, so you only hit the problem when you :> > near the "disk full" state. :> :> This sounds very unlikely. : :I know, doesn't it? Good thing Tom's Hardware is so thorough, or we :might never have known this, with everyone on the verge of discovering :it simply dismissing it as "very unlikely". 8^). :... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 22:20:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 62E9337B416; Sun, 9 Dec 2001 22:20:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210062006.NEYD4213.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 10 Dec 2001 06:20:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA27817; Sun, 9 Dec 2001 22:03:04 -0800 (PST) Date: Sun, 9 Dec 2001 22:03:03 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Terry Lambert , Greg Lehey , "Daniel O'Connor" , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) In-Reply-To: <200112100559.fBA5x2x43757@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 9 Dec 2001, Matthew Dillon wrote: > On google search for: > > deskstar 75gxp class action > > http://www.theregister.co.uk/content/54/22412.html > http://www.pcworld.com/news/article/0,aid,67608,00.asp > > etc... So apparently my warning about these drives in 'man tuning' is > still appropriate :-) > > -Matt > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > :> > that the sustained write speed exceeds the ability of the controller > :> > electronics to keep up, and results in crap being written to disk. I would adssume it actually the tracks FURTHEREST from the spindle.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 22:23:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from leviathan.inethouston.net (leviathan.inethouston.net [66.64.12.249]) by hub.freebsd.org (Postfix) with ESMTP id BB64737B405; Sun, 9 Dec 2001 22:23:31 -0800 (PST) Received: by leviathan.inethouston.net (Postfix, from userid 1001) id 4935B407622; Mon, 10 Dec 2001 00:23:38 -0600 (CST) Date: Mon, 10 Dec 2001 00:23:38 -0600 From: "David W. Chapman Jr." To: Julian Elischer Cc: Matthew Dillon , Terry Lambert , Greg Lehey , Daniel O'Connor , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011210062338.GA51934@leviathan.inethouston.net> Reply-To: "David W. Chapman Jr." Mail-Followup-To: Julian Elischer , Matthew Dillon , Terry Lambert , Greg Lehey , Daniel O'Connor , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de References: <200112100559.fBA5x2x43757@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i X-Operating-System: FreeBSD 4.4-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > :> > that the sustained write speed exceeds the ability of the controller > > :> > electronics to keep up, and results in crap being written to disk. > > > I would adssume it actually the tracks FURTHEREST from the spindle.. Wouldn't the linear speed be faster closer to the spindle at 7200 RPM than at the edge? -- David W. Chapman Jr. dwcjr@inethouston.net Raintree Network Services, Inc. dwcjr@freebsd.org FreeBSD Committer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 22:43:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 26F3737B417 for ; Sun, 9 Dec 2001 22:43:32 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fBA6hAQ17405; Sun, 9 Dec 2001 22:43:10 -0800 (PST) (envelope-from obrien) Date: Sun, 9 Dec 2001 22:43:10 -0800 From: "David O'Brien" To: Joerg Wunsch Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011209224310.A17244@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20011209102129.F97235@uriah.heep.sax.de> <200112092015.fB9KFJe01121@mass.dis.org> <200112092200.fB9M0J660085@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112092200.fB9M0J660085@uriah.heep.sax.de>; from j@uriah.heep.sax.de on Sun, Dec 09, 2001 at 11:00:19PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 09, 2001 at 11:00:19PM +0100, Joerg Wunsch wrote: > Mike Smith wrote: > > - The MBR partition table is not "obsolete", it's a part of the PC > > architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it?? You will get the traditional Unix workstation partitioning you so much long for. It really seems your arguments are nothing more than "MBR's are a M$ and IBM PeeCee thing, and I hate anything PeeCee". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 22:44:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id B489837B419; Sun, 9 Dec 2001 22:44:26 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210064426.VJMJ24045.rwcrmhc53.attbi.com@peter3.wemm.org>; Mon, 10 Dec 2001 06:44:26 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBA6WUs32815; Sun, 9 Dec 2001 22:32:30 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 467DB3810; Sun, 9 Dec 2001 22:32:30 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "David W. Chapman Jr." Cc: Julian Elischer , Matthew Dillon , Terry Lambert , Greg Lehey , "Daniel O'Connor" , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) In-Reply-To: <20011210062338.GA51934@leviathan.inethouston.net> Date: Sun, 09 Dec 2001 22:32:30 -0800 From: Peter Wemm Message-Id: <20011210063230.467DB3810@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David W. Chapman Jr." wrote: > > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > > :> > that the sustained write speed exceeds the ability of the controller > > > :> > electronics to keep up, and results in crap being written to disk. > > > > > > I would adssume it actually the tracks FURTHEREST from the spindle.. > > Wouldn't the linear speed be faster closer to the spindle at 7200 RPM > than at the edge? This particular tangent of the disk partitioning thread has gone *way* off topic. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 22:45: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 0ADB737B405 for ; Sun, 9 Dec 2001 22:44:53 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210064452.NRBY4213.rwcrmhc52.attbi.com@peter3.wemm.org> for ; Mon, 10 Dec 2001 06:44:52 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBA6iqs32877 for ; Sun, 9 Dec 2001 22:44:52 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 739173810; Sun, 9 Dec 2001 22:44:52 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "David W. Chapman Jr." Cc: current@FreeBSD.ORG Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) In-Reply-To: <20011210051454.GA49775@leviathan.inethouston.net> Date: Sun, 09 Dec 2001 22:44:52 -0800 From: Peter Wemm Message-Id: <20011210064452.739173810@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David W. Chapman Jr." wrote: > On Sun, Dec 09, 2001 at 06:46:24PM -0800, Terry Lambert wrote: > > It's because you have to reinstall, should you want to add a second > > OS at a later date (e.g. Linux, or Windows). > > I think it has more to do with the drive going on a new motherboard > that might not boot with dangerously dedicated than the above. .. And the mere presence of one of the disks that causes the bios to lock up at boot. Note that this is a particularly bad thing in laptops. There are three classes of behavior: 1) You luck out and it works 2) You get a bios divide-by-zero fault when you *boot* of the disk. This shows up as a 'BTX fault'. If you check the lists, a good number of btx faults posted to the lists have int=0 (divide by zero) in them. The problem is more widespread than it appears. 3) You get a system lockup when booting the *computer* if *any* DD disk is attached anywhere at all. This is what killed the Thinkpad T20*, A20*, 600X etc. After all the yelling we did at IBM, it turned out to be FreeBSD's fault. It also happens on Dell systems. It kills all IA64 boxes if a FreeBSD/i386 disk is attached anywhere. An additional problem is that because boot1 has got a fdisk table embedded in it unconditionally, a freebsd partition *looks* like it has got a recursive MBR in it. This is what is really bad and is what is killing us on newer systems. What really sucks is that there is **NO WAY** to remove it with the tools that we have except a hex editor. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 22:48:33 2001 Delivered-To: freebsd-current@freebsd.org Received: from theinternet.com.au (c20631.kelvn1.qld.optusnet.com.au [203.164.207.8]) by hub.freebsd.org (Postfix) with ESMTP id 07F5137B416; Sun, 9 Dec 2001 22:48:29 -0800 (PST) Received: (from akm@localhost) by theinternet.com.au (8.11.6/8.11.4) id fBA6lTN69678; Mon, 10 Dec 2001 16:47:29 +1000 (EST) (envelope-from akm) Date: Mon, 10 Dec 2001 16:47:28 +1000 From: Andrew Kenneth Milton To: "David W. Chapman Jr." Cc: Julian Elischer , Matthew Dillon , Terry Lambert , Greg Lehey , "Daniel O'Connor" , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011210164728.E46324@zeus.theinternet.com.au> References: <200112100559.fBA5x2x43757@apollo.backplane.com> <20011210062338.GA51934@leviathan.inethouston.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20011210062338.GA51934@leviathan.inethouston.net>; from David W. Chapman Jr. on Mon, Dec 10, 2001 at 12:23:38AM -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG +-------[ David W. Chapman Jr. ]---------------------- | > > :> > IBM DTLA drives are known to rotate fast enough near the spindle | > > :> > that the sustained write speed exceeds the ability of the controller | > > :> > electronics to keep up, and results in crap being written to disk. | > | > | > I would adssume it actually the tracks FURTHEREST from the spindle.. | | | Wouldn't the linear speed be faster closer to the spindle at 7200 RPM | than at the edge? er no. The circumference of a circle is 2 PI r. So as your distance from the spindle increases the amount of physical real estate you're traversing increases. Since you are turning at a constant angular velocity, your linear velocity increases as the distance from the spindle increases by a factor of PI (or around 3 if you're not a maths person). Even been at one of those carnivals where they have a spinning thing? It's easier to stay near the centre, than near the edges, because you are moving a *lot* quicker at the edges. And just for the hell of it; If you have a 3 unit disc doing 1 RPM If you're 1/2 unit out you're doing ~3 units/sec If you're one unit out, you're doing ~6 units/sec If you're two units out you're doing ~12 units/sec at three; ~18 units/sec Multiply by 7200 and s/units/inches/ The outside of your disk is really moving The density of the sectors at the outer edge is lighter than near the centre, which mitigates the speed some what. See Also: artficial gravity in space stations/ships/objects -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 23: 3:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 967F237B405 for ; Sun, 9 Dec 2001 23:03:34 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210070324.XJSX5859.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Mon, 10 Dec 2001 07:03:24 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBA73Xs32932 for ; Sun, 9 Dec 2001 23:03:34 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D88F33810; Sun, 9 Dec 2001 23:03:33 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c In-Reply-To: <200112092200.fB9M0J660085@uriah.heep.sax.de> Date: Sun, 09 Dec 2001 23:03:33 -0800 From: Peter Wemm Message-Id: <20011210070333.D88F33810@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Joerg Wunsch wrote: > Mike Smith wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > > architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) Can you please clarify for me what specifically you do not like.. Is it: - the cost of 32K of disk space on an average disk these days? (and if so, is reducing that to one sector instead of 62 sufficient?) - you don't like typing "s1" in the device name? Dont forget, there is quite a bit of confusion about what "DD" means. "disklabel -rw ad2 auto" is one form. That should not use fdisk at all. This is quite fine, and nobody wants that to go away. But the abomination is the form that is pseudo-bootable. We fill up boot1.s with a fake fdisk table and crap to try and work around cases where we are called either as the partition boot sector, or as a global MBR. This one should be taken out and shot. If you are going to make a bootable disk, you had better play by the rules of the environment that is booting it. At the very least, the fdisk table should be valid! I advocate that the bootable form (where boot1.s is expected to do the job of both the mbr *and* the partition boot) is evil and should at the very least be fixed. It should be something that is explicitly activated, and not something that you get whether you want it or not. This would have solved the Thinkpad and does solve the EFI problem. There are lots of ways that it can be fixed without forcing an "s1" into your device names if that's what is really upsetting you. > As long as you keep the feature of DD mode intact, i won't argue. If > people feel like creating disks that aren't portable to another > controller, they should do. I don't like this idea. Which "DD" mode? Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 23: 7:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 90F2137B417 for ; Sun, 9 Dec 2001 23:07:15 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 466FC786E6; Mon, 10 Dec 2001 17:37:13 +1030 (CST) Date: Mon, 10 Dec 2001 17:37:13 +1030 From: Greg Lehey To: Peter Wemm Cc: "David W. Chapman Jr." , current@FreeBSD.ORG Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011210173713.G63585@monorchid.lemis.com> References: <20011210051454.GA49775@leviathan.inethouston.net> <20011210064452.739173810@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011210064452.739173810@overcee.netplex.com.au> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 22:44:52 -0800, Peter Wemm wrote: > 3) You get a system lockup when booting the *computer* if *any* DD disk > is attached anywhere at all. This is what killed the Thinkpad T20*, > A20*, 600X etc. After all the yelling we did at IBM, it turned out > to be FreeBSD's fault. It also happens on Dell systems. It kills > all IA64 boxes if a FreeBSD/i386 disk is attached anywhere. What are you talking about? The IBM lockup was due to the presence of *Microsoft partition* of type 0xn5, for any value of n. If these systems also lock up with a dedicated disk, it's due to some other bug. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 23: 8:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7CC0537B41B; Sun, 9 Dec 2001 23:08:28 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBA77rJ44369; Sun, 9 Dec 2001 23:07:53 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 23:07:53 -0800 (PST) From: Matthew Dillon Message-Id: <200112100707.fBA77rJ44369@apollo.backplane.com> To: Julian Elischer Cc: Terry Lambert , Greg Lehey , "Daniel O'Connor" , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> etc... So apparently my warning about these drives in 'man tuning' is :> still appropriate :-) :> :> -Matt :> :> :> > IBM DTLA drives are known to rotate fast enough near the spindle :> :> > that the sustained write speed exceeds the ability of the controller :> :> > electronics to keep up, and results in crap being written to disk. : : :I would adssume it actually the tracks FURTHEREST from the spindle.. This is the first I've heard of the alleged controller electronics performance problem. My understanding is that the failures are due to manufacturing problems, but people have apparently experienced software lockups as well. What is not in doubt is that there have been some severe problems with this model. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 23:49:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 53F4B37B405 for ; Sun, 9 Dec 2001 23:49:31 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210074931.WKCQ24045.rwcrmhc53.attbi.com@peter3.wemm.org> for ; Mon, 10 Dec 2001 07:49:31 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBA7nVs33021 for ; Sun, 9 Dec 2001 23:49:31 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id DC9DC38CC; Sun, 9 Dec 2001 23:49:30 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG Subject: IBM DTLA drives (was: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) ) In-Reply-To: <200112100707.fBA77rJ44369@apollo.backplane.com> Date: Sun, 09 Dec 2001 23:49:30 -0800 From: Peter Wemm Message-Id: <20011210074930.DC9DC38CC@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > :> etc... So apparently my warning about these drives in 'man tuning' is > :> still appropriate :-) > :> > :> -Matt > :> > :> :> > IBM DTLA drives are known to rotate fast enough near the spindle > :> :> > that the sustained write speed exceeds the ability of the controller > :> :> > electronics to keep up, and results in crap being written to disk. > : > : > :I would adssume it actually the tracks FURTHEREST from the spindle.. > > This is the first I've heard of the alleged controller electronics > performance problem. My understanding is that the failures are due > to manufacturing problems, but people have apparently experienced > software lockups as well. > > What is not in doubt is that there have been some severe problems with > this model. Yes there are two problems. The physical failure problem seems to be mostly restricted to the 75GXP. However the electronics/bandwidth/ density/whatever-it-is problem is uniform across the entire DTLA line. We stopped using 75GXP's at work a while back, but we still regularly suffer from the electronics/bandwidth/whatever-it-is problem on 30G DTLA drives on a daily basis. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 9 23:58:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 29F0437B41D for ; Sun, 9 Dec 2001 23:58:28 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.11.6/8.11.6) id fBA7wLY48636; Mon, 10 Dec 2001 08:58:21 +0100 (CET) (envelope-from sos) From: Søren Schmidt Message-Id: <200112100758.fBA7wLY48636@freebsd.dk> Subject: Re: IBM DTLA drives (was: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) ) In-Reply-To: <20011210074930.DC9DC38CC@overcee.netplex.com.au> To: Peter Wemm Date: Mon, 10 Dec 2001 08:58:21 +0100 (CET) Cc: Matthew Dillon , freebsd-current@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Peter Wemm wrote: > > Yes there are two problems. The physical failure problem seems to > be mostly restricted to the 75GXP. However the electronics/bandwidth/ > density/whatever-it-is problem is uniform across the entire DTLA line. > We stopped using 75GXP's at work a while back, but we still regularly > suffer from the electronics/bandwidth/whatever-it-is problem on 30G DTLA > drives on a daily basis. It seems this problem only affects the newer versions of the DTLA, the first models (of which type most of mine are) doesn't seem to suffer from this problem. The first models looks like the older DPTA drives, whereas the newer ones has at least a different top cover. Anyhow, the problem seem to be an electronics malfunction (IBM doesn't tell exactly) and it is triggered by the drive being very sensitive to the power supply being top quality. At any rate I think the hysteria about these drives is somewhat overrated, but thats only my oppinion... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 0: 3:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id E60B837B416 for ; Mon, 10 Dec 2001 00:03:18 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBA835680219; Mon, 10 Dec 2001 10:03:05 +0200 (EET) (envelope-from ru) Date: Mon, 10 Dec 2001 10:03:05 +0200 From: Ruslan Ermilov To: Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: rev 1.61 of /sys/netinet/in.c breaks ISDN Message-ID: <20011210100305.B79785@sunbay.com> References: <200112061126.fB6BQ5v00774@Magelan.Leidinger.net> <200112061352.fB6DqnE47522@hak.lan.Awfulhak.org> <20011206162840.C82299@sunbay.com> <200112062023.fB6KNWd65603@uriah.heep.sax.de> <20011207095553.D13705@sunbay.com> <20011207210112.A97235@uriah.heep.sax.de> <20011208165113.G32556@sunbay.com> <20011208234447.E97235@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011208234447.E97235@uriah.heep.sax.de> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 11:44:47PM +0100, Joerg Wunsch wrote: > As Ruslan Ermilov wrote: > > > > You need to configure /some/ interface address for the remote end > > > anyway, and it must not clash with any other routing table entry, > > > since "ifconfig ... up" always adds an entry for the remote IP address > > > for p2p interfaces. > > > Only if you have INET address configured on an interface. > > That's the purpose of an sppp interface. You can't do anything with > it unless an INET address has been configured to it. (In the case of > an automatic dialer -- which is what many ISDN users are using -- you > need the IP traffic generated by normal routing in order to trigger > the ISDN dialout.) > ifconfig isp0 up route add default -iface isp0 Won't this work, without prior configuring any INET addresses? This will definitely trigger a traffic through the interface. > > Why not just bring the interface up first, then negotiate an address, > > then add it to interface? > > Because it'll become a chicken-and-egg problem: the interface would > never start negotiating PPP in that case. > Still don't get it, sorry. :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 0: 4:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 164D037B416; Mon, 10 Dec 2001 00:04:23 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBA89Oe07723; Mon, 10 Dec 2001 00:09:24 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112100809.fBA89Oe07723@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "David W. Chapman Jr." Cc: Julian Elischer , Matthew Dillon , Terry Lambert , Greg Lehey , "Daniel O'Connor" , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) In-reply-to: Your message of "Mon, 10 Dec 2001 00:23:38 CST." <20011210062338.GA51934@leviathan.inethouston.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Dec 2001 00:09:24 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > > :> > that the sustained write speed exceeds the ability of the controller > > > :> > electronics to keep up, and results in crap being written to disk. > > > > I would adssume it actually the tracks FURTHEREST from the spindle.. With ZBR, anything is possible. > Wouldn't the linear speed be faster closer to the spindle at 7200 RPM > than at the edge? The stunning ignorance being displayed in this thread appears to have reached an all-time low. *sigh* -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 0:11:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id CAF5D37B405; Mon, 10 Dec 2001 00:11:46 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBA8HEe07837; Mon, 10 Dec 2001 00:17:14 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112100817.fBA8HEe07837@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: Mike Smith , Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c) In-reply-to: Your message of "Mon, 10 Dec 2001 13:07:13 +1030." <20011210130713.C63585@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Dec 2001 00:17:14 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >>> Still, it's my opinion that these BIOSes are simply broken: > > > > Joerg's personal opinion can go take a hike. The reality of the > > situation is that this table is required, and we're going to put it there. > > The reality of the situation is far from being clear. The only thing > I can see is that you're trying to dictate things without adequate > justification. You should reconsider that attitude. You can't substantiate your argument by closing your eyes, Greg. There's a wealth of evidence against your stance, and frankly, none that supports it other than myopic bigotry ("I don't want to do this because Microsoft use this format"). Are you going to stop using all of the other techniques that we share with them? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 0:12:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D8ECD37B419; Mon, 10 Dec 2001 00:12:19 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBA8CJK44729; Mon, 10 Dec 2001 00:12:19 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 00:12:19 -0800 (PST) From: Matthew Dillon Message-Id: <200112100812.fBA8CJK44729@apollo.backplane.com> To: Mike Smith Cc: "David W. Chapman Jr." , Julian Elischer , Terry Lambert , Greg Lehey , "Daniel O'Connor" , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) References: <200112100809.fBA89Oe07723@mass.dis.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> Wouldn't the linear speed be faster closer to the spindle at 7200 RPM :> than at the edge? : :The stunning ignorance being displayed in this thread appears to have :reached an all-time low. : :*sigh* Ah, another poor soul who didn't read the first sentence of tuning(7). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 0:20:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id EFD6637B417 for ; Mon, 10 Dec 2001 00:20:24 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id JAA11442 for freebsd-current@FreeBSD.ORG; Mon, 10 Dec 2001 09:20:23 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fBA8B3N70662 for freebsd-current@FreeBSD.ORG; Mon, 10 Dec 2001 09:11:03 +0100 (MET) (envelope-from j) Date: Mon, 10 Dec 2001 09:11:03 +0100 From: Joerg Wunsch To: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011210091103.M97235@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-current@FreeBSD.ORG References: <20011209102129.F97235@uriah.heep.sax.de> <20011210004350.6703C3810@overcee.netplex.com.au> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011210005928.9538A3810@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011210005928.9538A3810@overcee.netplex.com.au>; from peter@wemm.org on Sun, Dec 09, 2001 at 04:59:28PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As Peter Wemm wrote: > No, it isn't ignored, BIOS'es "know" that fdisk partitions end on > cylinder boundaries, and therefore can intuit what the expected > geometry is for the disk in question. And you call that a "design"? I call it a poor hack, nothing else. The restriction to whatever the BIOS believes to be a "cylinder" boundary is one of my gripes with fdisk tables; you obviously missed that (or you don't argue about it -- can i take this as silent agreement?). It imposes a geometry that is not even remotely there, with the drawbacks that a number of sectors can never be assigned (OK, no big deal these days), but even worse, disks are non-portable between different BIOSes that perform different "intuition" about how to obtain the "geometry" from those poorly chosen values that are included in fdisk tables. /The/ major advantage of DD mode was that all BIOSes (so far :) at least agree on how to access block 0 and the adjacent blocks, so starting our own system there makes those disks portable. > [...] The problem is that the int13 code only allowed for 255 heads, > and the fake "end of disk" entry that is unconditionally in /boot/boot1 > specified an ending head number 255 (ie: 256 heads). When this gets put > into a byte register it is truncated to zero and we get divide by zero > errors. I've read this, and yes, i never argued about fixing /that/. Since those values chosen by our grandfather Bill Jolitz have been just `magic' numbers only, it's unfortunate they eventually turned out to be such bad magic about a decade later. > We can just as easily have bootable-DD mode with a real MBR and have > freebsd start on sector #2 instead of overlapping boot1 and mbr. Probably, i think i could live with that. > I'd rather that we be specific about this. If somebody wants ad2e > or da2e then they should not be using *any* fdisk tables at all. > Ie: block 0 should be empty. That disk wouldn't boot at all, you know that. Yes, i prefer my disks to be called da0a...daNP. >> But to be honest, see my other article: i never argued to make this >> the default or a recommended strategy in any form. It should only >> remain intact at all. Back to the subject, the current warning >> however, is pointless, and has the major drawback to potentially >> hide important console messages. > The console buffer is 32K these days. You'd have to have around 300 > disks to have any real effect on the kernel. You're narrow minded here, Peter, this time about in the same way as Windoze is narrow minded: "All the world's a graphical console produced by XXX." No, all the world's not like that. You might consider my pcvt console obsolete, OK, but did you ever think about a plain VT220 on a serial console? They don't have /any/ scrollback buffer. (And you can't even stop the output with ^S while FreeBSD is booting.) Also, i think that: uriah /boot/kernel/kernel: da0: invalid primary partition table: Dangerously Dedicated (ignored) uriah last message repeated 5 times uriah /boot/kernel/kernel: da1: invalid primary partition table: Dangerously Dedicated (ignored) uriah last message repeated 34 times uriah /boot/kernel/kernel: da2: invalid primary partition table: Dangerously Dedicated (ignored) uriah last message repeated 34 times ...73 of those silly messages are just beyond any form of usefulness. Either we hide this completely behind bootverbose (back to the root of this thread) since it bears no information at all (i already knew what is written there, since it was my deliberate decision, and it could not have happened unless being my deliberate decision), or we at least ensure any of those messages is emitted at most once per drive. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 0:57:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id C51E137B416; Mon, 10 Dec 2001 00:57:12 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 6FEC6786E6; Mon, 10 Dec 2001 19:27:09 +1030 (CST) Date: Mon, 10 Dec 2001 19:27:09 +1030 From: Greg Lehey To: Mike Smith Cc: Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011210192709.H63585@monorchid.lemis.com> References: <20011210130713.C63585@monorchid.lemis.com> <200112100817.fBA8HEe07837@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200112100817.fBA8HEe07837@mass.dis.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday, 10 December 2001 at 0:17:14 -0800, Mike Smith wrote: >>>>> Still, it's my opinion that these BIOSes are simply broken: >>> >>> Joerg's personal opinion can go take a hike. The reality of the >>> situation is that this table is required, and we're going to put it there. >> >> The reality of the situation is far from being clear. The only thing >> I can see is that you're trying to dictate things without adequate >> justification. You should reconsider that attitude. > > You can't substantiate your argument by closing your eyes, Greg. No, of course not. I also can't substantiate my arguments by sticking my fingers down my throat and shouting "dangerously dedicated!". But then, I wasn't doing either. Read back this thread for the evidence I have given and which you apparently choose to ignore. > There's a wealth of evidence against your stance, Possibly, you just haven't shown it. What we know so far is that there are some kludges in the boot loader which can confuse BIOSes; peter went into some detail earlier on IRC. Only, they apply both to systems with Microsoft partitions and those without. And there are reports that some Adaptec host adaptors (or, presumably, their BIOSes) can't handle our particular boot blocks. It's possible, as peter suggests, that this is a fixable bug, but every time I mention it, I get shouted down. And yes, like Jörg, I don't care enough. I'm not saying "ditch the Microsoft partition table", I'm saying "don't ditch disks without the Microsoft partition table". Note also that, although this is so "dangerous", it has never bitten me on any system. > and frankly, none that supports it other than myopic bigotry ("I > don't want to do this because Microsoft use this format"). None that you care to remember. > Are you going to stop using all of the other techniques that we > share with them? No. See above. What is it about this particular topic brings out such irrational emotions in you and others? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 1: 1:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from ns.klondike.ru (ns.klondike.ru [195.170.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 2B7F837B405 for ; Mon, 10 Dec 2001 01:01:21 -0800 (PST) Received: (from root@localhost) by ns.klondike.ru (8.9.3/8.9.3) id MAA11403 for freebsd-current@FreeBSD.ORG.KAV; Mon, 10 Dec 2001 12:01:19 +0300 (MSK) Received: from freebsd.klondike.ru (freebsd [195.170.237.64]) by ns.klondike.ru (8.9.3/8.9.3) with SMTP id MAA11387; Mon, 10 Dec 2001 12:01:17 +0300 (MSK) Date: Mon, 10 Dec 2001 12:01:31 +0300 From: Kaltashkin Eugene To: Julian Elischer Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, freebsd-question@FreeBSD.ORG Subject: Re: NCP Broken ? Message-Id: <20011210120131.33ce1f7a.zhecka@klondike.ru> In-Reply-To: References: <20011207121324.7deab0a8.zhecka@klondike.ru> X-Mailer: stuphead ver. 0.5.4 (Insensible-cvs) (GTK+ 1.2.10; FreeBSD 5.0-CURRENT; i386) Organization: Klondike Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 7 Dec 2001 10:55:03 -0800 (PST) Julian Elischer wrote: JE: yes ncp and nwfs are broken in -current Hm, and when this be work ? -- Best Regards Kaltashkin Eugene ZHECKA-RIPN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 1:44: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.heelbhi.com (adsl-216-61-40-121.dsl.austtx.swbell.net [216.61.40.121]) by hub.freebsd.org (Postfix) with SMTP id C792237B419 for ; Mon, 10 Dec 2001 01:43:59 -0800 (PST) To: current From: Andrew X-Mailer: SuperMail-2 Subject: current, how much? MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20011210094359.C792237B419@hub.freebsd.org> Date: Mon, 10 Dec 2001 01:43:59 -0800 (PST) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG My name is Andrew. I am an erotic photographer and I love young Russian girls that's why I made this site for you. I was impressed when browseing the photos. Cool site Many russian lolitas. ( http://lola-tron.tc ) its only exclusive photos of Russian lolitas. Over 2000 fresh photos. High quality photos. All girls that you will meet here are REAL. Yes, I mean real Russian amateur teen girls. I don't buy pictures from content provider, I make it myself. What it means to you? You can write a letter, ask question and even meet every girl you see here! Everything is possible here!! For unsubsribe go to: http:///www.autoremove.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 1:47:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id 6703637B417; Mon, 10 Dec 2001 01:47:17 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id SAA07128; Mon, 10 Dec 2001 18:47:16 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA13196; Mon, 10 Dec 2001 18:47:16 +0900 (JST) Received: from localhost (shigeru@mercury.iij.ad.jp [192.168.4.89]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA24819; Mon, 10 Dec 2001 18:47:16 +0900 (JST) Date: Mon, 10 Dec 2001 18:47:15 +0900 (JST) Message-Id: <20011210.184715.99986520.shigeru@iij.ad.jp> To: freebsd-mobile@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: 2 patches for NEWCARD From: YAMAMOTO Shigeru In-Reply-To: <200111200454.fAK4sb780192@harmony.village.org> References: <20011119.171129.72757009.shigeru@iij.ad.jp> <200111200454.fAK4sb780192@harmony.village.org> X-Mailer: Mew version 2.0 pre1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Dec_10_18:47:15_2001_070)--" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----Next_Part(Mon_Dec_10_18:47:15_2001_070)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> "Warner" == Warner Losh writes: Warner> Hmmm. Something about this patch looks incorrect. Wouldn't it Warner> delete the actual bus (eg pccard/cardbus)? I'd think that we'd want Warner> to delete the children's children. I will have to look at the code Warner> more closely to see if I might be mistaken. I re-write a patch for NEWCARD. New patch is, - detach children of cardbus/pccard devices at suspend time - probe and attach children of cardbus/pccard devices at resume time - pccbb devices are suspend/resume - cardbus and pccard devices are suspend/resume instead of detach/attach Currently, I'm using this fixes on my NotePC and there is no problem. ------- YAMAMOTO Shigeru ----Next_Part(Mon_Dec_10_18:47:15_2001_070)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="newcard.diff" Index: cardbus/cardbus.c =================================================================== RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/dev/cardbus/cardbus.c,v retrieving revision 1.12 diff -u -r1.12 cardbus.c --- cardbus/cardbus.c 27 Aug 2001 00:09:34 -0000 1.12 +++ cardbus/cardbus.c 9 Dec 2001 15:51:50 -0000 @@ -163,6 +163,24 @@ return 0; } +static +int +cardbus_suspend(device_t self) { + int error = 0; + + cardbus_detach_card(self, DETACH_FORCE); + + return(error); +} + +static +int +cardbus_resume(device_t self) { + int error = 0; + + return(error); +} + /************************************************************************/ /* Attach/Detach card */ /************************************************************************/ @@ -1199,8 +1217,8 @@ DEVMETHOD(device_attach, cardbus_attach), DEVMETHOD(device_detach, cardbus_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_suspend, cardbus_suspend), + DEVMETHOD(device_resume, cardbus_resume), /* Bus interface */ DEVMETHOD(bus_print_child, cardbus_print_child), Index: pccard/pccard.c =================================================================== RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/dev/pccard/pccard.c,v retrieving revision 1.48 diff -u -r1.48 pccard.c --- pccard/pccard.c 26 Nov 2001 07:14:00 -0000 1.48 +++ pccard/pccard.c 9 Dec 2001 15:50:43 -0000 @@ -807,6 +807,25 @@ return 0; } +static +int +pccard_suspend(device_t self) { + int error = 0; + struct pccard_softc* sc = PCCARD_SOFTC(self); + + pccard_detach_card(self, 0); + + return(error); +} + +static +int +pccard_resume(device_t self) { + int error = 0; + + return(error); +} + static void pccard_print_resources(struct resource_list *rl, const char *name, int type, int count, const char *format) @@ -1200,8 +1219,8 @@ DEVMETHOD(device_attach, pccard_attach), DEVMETHOD(device_detach, pccard_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_suspend, pccard_suspend), + DEVMETHOD(device_resume, pccard_resume), /* Bus interface */ DEVMETHOD(bus_print_child, pccard_print_child), Index: pccbb/pccbb.c =================================================================== RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.31 diff -u -r1.31 pccbb.c --- pccbb/pccbb.c 26 Nov 2001 07:17:09 -0000 1.31 +++ pccbb/pccbb.c 9 Dec 2001 15:50:04 -0000 @@ -2096,14 +2096,78 @@ b, s, f, reg, val, width); } +static +int +pccbb_suspend(device_t self) { + int error = 0; + struct pccbb_softc* sc = device_get_softc(self); + int numdevs; + device_t* devlist; + int tmp; + + bus_teardown_intr(self, sc->sc_irq_res, sc->sc_intrhand); + + bus_generic_suspend(self); + + return(error); +} + +static +int +pccbb_resume(device_t self) +{ + int error = 0; + struct pccbb_softc *sc = (struct pccbb_softc *)device_get_softc(self); + + pci_write_config(self, PCCBBR_SOCKBASE, + rman_get_start(sc->sc_base_res), 4); + DEVPRINTF((self, "PCI Memory allocated: %08lx\n", + rman_get_start(sc->sc_base_res))); + + pccbb_chipinit(sc); + + /* CSC Interrupt: Card detect interrupt on */ + sc->sc_socketreg->socket_mask |= PCCBB_SOCKET_MASK_CD; + + /* reset interrupt */ + { + u_int32_t tmp; + + tmp = sc->sc_socketreg->socket_event; + sc->sc_socketreg->socket_event = tmp; + } + + /* establish the interrupt. */ + if (bus_setup_intr(self, sc->sc_irq_res, INTR_TYPE_BIO, pccbb_intr, sc, + &(sc->sc_intrhand))) { + device_printf(self, "couldn't establish interrupt"); + bus_release_resource(self, SYS_RES_IRQ, 0, sc->sc_irq_res); + bus_release_resource(self, SYS_RES_MEMORY, PCCBBR_SOCKBASE, + sc->sc_base_res); + mtx_destroy(&sc->sc_mtx); + error = ENOMEM; + } + + bus_generic_resume(self); + + /* wakeup thread */ + if (!error) { + mtx_lock(&sc->sc_mtx); + wakeup(sc); + mtx_unlock(&sc->sc_mtx); + } + + return(error); +} + static device_method_t pccbb_methods[] = { /* Device interface */ DEVMETHOD(device_probe, pccbb_probe), DEVMETHOD(device_attach, pccbb_attach), DEVMETHOD(device_detach, pccbb_detach), DEVMETHOD(device_shutdown, pccbb_shutdown), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_suspend, pccbb_suspend), + DEVMETHOD(device_resume, pccbb_resume), /* bus methods */ DEVMETHOD(bus_print_child, bus_generic_print_child), ----Next_Part(Mon_Dec_10_18:47:15_2001_070)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 1:49:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id EE0D037B417; Mon, 10 Dec 2001 01:49:24 -0800 (PST) Received: from pool0043.cvx40-bradley.dialup.earthlink.net ([216.244.42.43] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DN3o-0006vs-00; Mon, 10 Dec 2001 01:49:20 -0800 Message-ID: <3C148523.9A0E1463@mindspring.com> Date: Mon, 10 Dec 2001 01:49:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David W. Chapman Jr." Cc: Julian Elischer , Matthew Dillon , Greg Lehey , Daniel O'Connor , sthaug@nethelp.no, freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de, joerg_wunsch@uriah.heep.sax.de Subject: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) References: <200112100559.fBA5x2x43757@apollo.backplane.com> <20011210062338.GA51934@leviathan.inethouston.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David W. Chapman Jr." wrote: > > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > > :> > that the sustained write speed exceeds the ability of the controller > > > :> > electronics to keep up, and results in crap being written to disk. > > > > > > I would adssume it actually the tracks FURTHEREST from the spindle.. > > Wouldn't the linear speed be faster closer to the spindle at 7200 RPM > than at the edge? Linear speed is closes at the edge, but magnetic domain density is higher at the spindle, for a uniform rotation rate. I think that the electronics ended up being designed for the average rate. PS: The encoding frequency is higher at the spindle, as well. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 1:53:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 5F88C37B417 for ; Mon, 10 Dec 2001 01:53:21 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBA9oo494507; Mon, 10 Dec 2001 11:50:50 +0200 (EET) (envelope-from ru) Date: Mon, 10 Dec 2001 11:50:50 +0200 From: Ruslan Ermilov To: Peter Wemm Cc: Mathieu Arnold , Warner Losh , current@FreeBSD.ORG Subject: Re: stable->current busted Message-ID: <20011210115050.B82371@sunbay.com> References: <3C106394.A9803F72@club-internet.fr> <20011208210832.2FC593808@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011208210832.2FC593808@overcee.netplex.com.au> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 01:08:32PM -0800, Peter Wemm wrote: > Mathieu Arnold wrote: > > > > Warner Losh wrote: > > > > > > 4.4-r -> current build is very broken right now. I'll investigate and > > > fix. > > > > last time I did it, I had a problem with install, adding LDFLAGS+= > > -static to src/usr.bin/xinstall/Makefile fixed the problem. > > the problem was using install linked to libc.so.4 to do something like > > this : > > rm libc.so.4 > > install libc.so.4 > > which was failing for obvious reasons :) > > I think this will fix it: > > http://people.freebsd.org/~peter/compat.diff > Please don't do this. At least in my version of Makefile.inc1, bootstrap-tools (which xinstall is part of) are built static and used during installworld: ldd: /usr/obj/usr/src/i386/usr/bin/install: not a dynamic executable Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 2: 5: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 4F90037B416 for ; Mon, 10 Dec 2001 02:04:58 -0800 (PST) Received: from pool0043.cvx40-bradley.dialup.earthlink.net ([216.244.42.43] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DNIt-0005Pi-00; Mon, 10 Dec 2001 02:04:56 -0800 Message-ID: <3C1488CF.410BE633@mindspring.com> Date: Mon, 10 Dec 2001 02:05:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joerg Wunsch Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c References: <20011209102129.F97235@uriah.heep.sax.de> <20011210004350.6703C3810@overcee.netplex.com.au> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011210005928.9538A3810@overcee.netplex.com.au> <20011210091103.M97235@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ah, the thread which would not die... 8^). Joerg Wunsch wrote: > /The/ major advantage of DD mode was that all BIOSes (so far :) at > least agree on how to access block 0 and the adjacent blocks, so > starting our own system there makes those disks portable. I guarantee you that there are a number of controllers which have different ideas of how to do soft sector sparing _at the controller level_ rather than at the drive level. Disks created with such controllers aren't portable, since they depend on controller state information, which may not be valid from controller to controller, depending on the controller settings (I killed a disk by not having the WD1007 soft sector sparing jumper set the same in the machine I put it in as in the machine I took it out of... 8^)). > I've read this, and yes, i never argued about fixing /that/. Since > those values chosen by our grandfather Bill Jolitz have been just > `magic' numbers only, it's unfortunate they eventually turned out to > be such bad magic about a decade later. Yeah, we should pick new magic. It's bound to die again in the future, though, once "what's magic" changes out from under us again... 8^(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 2: 8:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 17A3D37B416; Mon, 10 Dec 2001 02:08:30 -0800 (PST) Received: from pool0043.cvx40-bradley.dialup.earthlink.net ([216.244.42.43] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DNML-0006rV-00; Mon, 10 Dec 2001 02:08:29 -0800 Message-ID: <3C1489A5.A8FA8983@mindspring.com> Date: Mon, 10 Dec 2001 02:08:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: Mike Smith , Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c) References: <20011210130713.C63585@monorchid.lemis.com> <200112100817.fBA8HEe07837@mass.dis.org> <20011210192709.H63585@monorchid.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg Lehey wrote: > What is it about this particular topic brings out such irrational > emotions in you and others? Everyone who has been around for any length of time has been bitten on the arse by it at one time or another, I think. I remember Alfred made a "Lapbrick" out of a system a while back.... ;^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 2:20:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 5835C37B405 for ; Mon, 10 Dec 2001 02:20:00 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id LAA12677 for freebsd-current@FreeBSD.ORG; Mon, 10 Dec 2001 11:19:58 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fBAA4cP72615 for freebsd-current@FreeBSD.ORG; Mon, 10 Dec 2001 11:04:38 +0100 (MET) (envelope-from j) Date: Mon, 10 Dec 2001 11:04:38 +0100 From: Joerg Wunsch To: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011210110438.A72135@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-current@FreeBSD.ORG References: <20011209102129.F97235@uriah.heep.sax.de> <200112092015.fB9KFJe01121@mass.dis.org> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011209224310.A17244@dragon.nuxi.com> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011210070333.D88F33810@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011210070333.D88F33810@overcee.netplex.com.au>; from peter@wemm.org on Sun, Dec 09, 2001 at 11:03:33PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As Peter Wemm wrote: > Can you please clarify for me what specifically you do not like.. Is it: > - the cost of 32K of disk space on an average disk these days? > (and if so, is reducing that to one sector instead of 62 sufficient?) The idea of a "geometry" that does not even remotely resembles the actual geometry and only causes additional hassles, like disks being not portable between controllers that have a different idea of that geometry (since the design of this table is missing an actual field to specify the geometry). Incidentally, it's only what you call "intuition" that finally stumpled across the 10-years old Jolitz fake fdisk values. So IOW, it took the BIOS vendors ten years to produce a BIOS that would break on it :), and the breakage (division by 0) was only since they needed black magic in order to infer a geometry value that was short-sightedly never specified in the table itself. > - you don't like typing "s1" in the device name? Aesthetically, yes, this one too. :) > "disklabel -rw ad2 auto" is one form. That should not use fdisk at all. > This is quite fine, and nobody wants that to go away. Good to hear. Well, actually i always use "disklabel -Brw daN auto", partly because this sequence is wired into my fingers, and since i mentally DAbelieve that having more bootstrappable disks couldn't harm. ;-) As laid out in another message, i eventually got the habit of even including a root partition mirror on each disk as well. So each of my disks should be able to boot a single-user FreeBSD. > I advocate that the bootable form (where boot1.s is expected to do the > job of both the mbr *and* the partition boot) is evil and should at the very > least be fixed. Fixing is OK to me. I think to recognize the dummy fdisk table of DD mode, it would be totally sufficient to verify slice 4 being labelled with 50000 blocks, and the other slices being labelled 0. We do not support any physical disk anymore that is only 25 MB in size :). So all the remaining (INT 0x13 bootstrap) values could be anything -- even something that most BIOSes would recognize as a valid fdisk table. > It should be something that is explicitly activated, and > not something that you get whether you want it or not. I don't fully understand that. DD mode has always been an explicit decision. Even in the above, the specification of -B explicitly tells to install that bootstrap. As David O'Brien wrote: > > Its design is antique. Or rather: it's missing a design. > Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it?? I don't see much value in an Alpha. Maybe a Sun some day, who knows? As i understand it now, the UltraSparc port is not quite at that stage, but i'm willing to experiment with it when i find a bit of time and documentation how to get started. I've got access to a good number of Suns here at work, and i think there are even a number of colleagues who would prefer FreeBSD over Solaris on them. If FreeBSD would had been ready for it, i could have tested it on the new V880 machine that was just announced recently. :) (We were the first one worldwide to show it on a fair trade here, about 24 hours after the official announcment...) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 2:20: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 8121837B416; Mon, 10 Dec 2001 02:20:04 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id LAA12689; Mon, 10 Dec 2001 11:20:03 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fBAA6jW72769; Mon, 10 Dec 2001 11:06:45 +0100 (MET) (envelope-from j) Date: Mon, 10 Dec 2001 11:06:45 +0100 From: Joerg Wunsch To: freebsd-current@FreeBSD.ORG Cc: Ruslan Ermilov Subject: Re: rev 1.61 of /sys/netinet/in.c breaks ISDN Message-ID: <20011210110645.B72135@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-current@FreeBSD.ORG, Ruslan Ermilov References: <200112061126.fB6BQ5v00774@Magelan.Leidinger.net> <200112061352.fB6DqnE47522@hak.lan.Awfulhak.org> <20011206162840.C82299@sunbay.com> <200112062023.fB6KNWd65603@uriah.heep.sax.de> <20011207095553.D13705@sunbay.com> <20011207210112.A97235@uriah.heep.sax.de> <20011208165113.G32556@sunbay.com> <20011208234447.E97235@uriah.heep.sax.de> <20011210100305.B79785@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011210100305.B79785@sunbay.com>; from ru@FreeBSD.ORG on Mon, Dec 10, 2001 at 10:03:05AM +0200 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As Ruslan Ermilov wrote: > ifconfig isp0 up > route add default -iface isp0 > > Won't this work, without prior configuring any INET addresses? Probably not, at least not the way sppp is designed right now. Historically, it always required explicit IP addresses to start with, negotiating addresses has only been added later. There are more important things on my plate to fix in sppp than this relatively minor issue which is of pure aesthetical value. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 2:22:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 7A04537B405 for ; Mon, 10 Dec 2001 02:22:32 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBAALOB99050; Mon, 10 Dec 2001 12:21:24 +0200 (EET) (envelope-from ru) Date: Mon, 10 Dec 2001 12:21:24 +0200 From: Ruslan Ermilov To: Peter Wemm Cc: Mathieu Arnold , Warner Losh , current@FreeBSD.ORG Subject: Re: stable->current busted Message-ID: <20011210122124.C82371@sunbay.com> References: <3C106394.A9803F72@club-internet.fr> <20011208210832.2FC593808@overcee.netplex.com.au> <20011210115050.B82371@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20011210115050.B82371@sunbay.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 10, 2001 at 11:50:50AM +0200, Ruslan Ermilov wrote: > On Sat, Dec 08, 2001 at 01:08:32PM -0800, Peter Wemm wrote: > > Mathieu Arnold wrote: > > > > > > Warner Losh wrote: > > > > > > > > 4.4-r -> current build is very broken right now. I'll investigate and > > > > fix. > > > > > > last time I did it, I had a problem with install, adding LDFLAGS+= > > > -static to src/usr.bin/xinstall/Makefile fixed the problem. > > > the problem was using install linked to libc.so.4 to do something like > > > this : > > > rm libc.so.4 > > > install libc.so.4 > > > which was failing for obvious reasons :) > > > > I think this will fix it: > > > > http://people.freebsd.org/~peter/compat.diff > > > Please don't do this. At least in my version of Makefile.inc1, > bootstrap-tools (which xinstall is part of) are built static > and used during installworld: > > ldd: /usr/obj/usr/src/i386/usr/bin/install: not a dynamic executable > Please also see my reply to PR misc/32635 (attached). The author reported a (known) impossibility to make 5.0-CURRENT release on a 4.4-STABLE box, but was also worried about standard source upgrade. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --k+w/mQv8wyuph6w0 Content-Type: message/rfc822 Content-Disposition: inline Received: from mx2.freebsd.org (mx2.FreeBSD.org [216.136.204.119]) by whale.sunbay.crimea.ua (8.11.6/8.11.2) with ESMTP id fBAAIVv98574 for ; Mon, 10 Dec 2001 12:18:32 +0200 (EET) (envelope-from ru@FreeBSD.org) Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 9E89855E9B for ; Mon, 10 Dec 2001 02:18:26 -0800 (PST) (envelope-from ru@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id 4A2E337B417; Mon, 10 Dec 2001 02:18:27 -0800 (PST) Delivered-To: ru@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id EB30237B405; Mon, 10 Dec 2001 02:18:26 -0800 (PST) Received: (from ru@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id fBAAIKb84916; Mon, 10 Dec 2001 02:18:20 -0800 (PST) (envelope-from ru) Date: Mon, 10 Dec 2001 02:18:20 -0800 (PST) From: Message-Id: <200112101018.fBAAIKb84916@freefall.freebsd.org> To: florian.schrack@freenet.de, ru@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/32635: 'make installworld' fails during update to -current MIME-Version: 1.0 Synopsis: 'make installworld' fails during update to -current State-Changed-From-To: open->closed State-Changed-By: ru State-Changed-When: Mon Dec 10 02:07:52 PST 2001 State-Changed-Why: Sorry, but we don't currently support building cross-branch releases. This shouldn't be a problem for a normal (non-chrooted) upgrade, since `installworld' makes copies of all utilities (and uses them) that are needed during install. This happens as the first step of `buildworld' stage. Also, if you have old 4.x binaries (linked against libc.so.4, etc.), make sure to add COMPAT4X=TRUE to /etc/make.conf. There's still a race exists when installing compat libraries, because stale libraries (libc.so.4) are removed before their copies are moved into /usr/lib/compat. But this race is actually harmless, because the only utils that are used during installation are chflags(1), rm(1) and install(1), all of them are linked static (including install(1), which is built in a BMAKEENV environment with -DNOSHARED during `installworld'). http://www.FreeBSD.org/cgi/query-pr.cgi?pr=32635 --k+w/mQv8wyuph6w0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 3:20:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id D9C6237B417; Mon, 10 Dec 2001 03:20:24 -0800 (PST) Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id NAA51342; Mon, 10 Dec 2001 13:20:22 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (h163.229.dialup.iptcom.net [212.9.229.163]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id NAA22628; Mon, 10 Dec 2001 13:20:11 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id fBABInW10635; Mon, 10 Dec 2001 13:18:49 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3C149AD0.EF66AF8B@FreeBSD.org> Date: Mon, 10 Dec 2001 13:21:52 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: current@FreeBSD.org, jhb@FreeBSD.org Subject: -CURRENT often panices when exiting from X server to VESA_800x600 console Content-Type: multipart/mixed; boundary="------------A3B48C213C1C879EC0C8D961" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------A3B48C213C1C879EC0C8D961 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi, My -CURRENT box often panices when exiting from X server to console running in VESA_800x600 mode. I was observing this weird behaviour for quite some time now. Also I've noted that the chances of system going down is directly related to the presence of disk activity during the mode change - if there is a havy disk activity during this period then those chances are quite high. Therefore, I suspecting that there are some locking problems, but as my knowelege in this area is almost non-existent I would like to ask somebody to look at the attached crash log and let me know if there are any ideas. Please also don't hesitate to ask if any additional debugging is necessary. Thanks! -Maxim --------------A3B48C213C1C879EC0C8D961 Content-Type: application/x-unknown-content-type-txtfile; name="panic.log" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="panic.log" U2NyaXB0IHN0YXJ0ZWQgb24gTW9uIERlYyAxMCAxMzowODowNCAyMDAxCnJvb3RAbm90ZWJv b2sjIGdkYiAtayAvc3lzL2kzODYvY29tcGlsZS9OT1RFQk9PSy9rZXJuZWwuZGVidWcgdm1j b3JlLjANCkdOVSBnZGIgNC4xOA0KQ29weXJpZ2h0IDE5OTggRnJlZSBTb2Z0d2FyZSBGb3Vu ZGF0aW9uLCBJbmMuDQpHREIgaXMgZnJlZSBzb2Z0d2FyZSwgY292ZXJlZCBieSB0aGUgR05V IEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGFuZCB5b3UgYXJlDQp3ZWxjb21lIHRvIGNoYW5n ZSBpdCBhbmQvb3IgZGlzdHJpYnV0ZSBjb3BpZXMgb2YgaXQgdW5kZXIgY2VydGFpbiBjb25k aXRpb25zLg0KVHlwZSAic2hvdyBjb3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuDQpU aGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5IGZvciBHREIuICBUeXBlICJzaG93IHdh cnJhbnR5IiBmb3IgZGV0YWlscy4NClRoaXMgR0RCIHdhcyBjb25maWd1cmVkIGFzICJpMzg2 LXVua25vd24tZnJlZWJzZCIuLi4NCklkbGVQVEQgMzU0NzEzNg0KaW5pdGlhbCBwY2IgYXQg MmFiYWMwDQpwYW5pY3N0cjogYndyaXRlOiBidWZmZXIgaXMgbm90IGJ1c3k/Pz8NCnBhbmlj IG1lc3NhZ2VzOg0KLS0tDQpGYXRhbCB0cmFwIDEyOiBwYWdlIGZhdWx0IHdoaWxlIGluIHZt ODYgbW9kZQ0KZmF1bHQgdmlydHVhbCBhZGRyZXNzCT0gMHhjMGRkYw0KZmF1bHQgY29kZQkJ PSB1c2VyIHJlYWQsIHBhZ2Ugbm90IHByZXNlbnQNCmluc3RydWN0aW9uIHBvaW50ZXIJPSAw eGMwMDA6MHhkZGMNCnN0YWNrIHBvaW50ZXIJICAgICAgICA9IDB4MDoweGZhNA0KZnJhbWUg cG9pbnRlcgkgICAgICAgID0gMHgwOjB4ZmU2DQpjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDQ0 MDAxMiwgbGltaXQgMHgxMDAwMSwgdHlwZSAweGQNCgkJCT0gRFBMIDAsIHByZXMgMCwgZGVm MzIgMCwgZ3JhbiAwDQpwcm9jZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0IGVuYWJsZWQsIHJl c3VtZSwgdm04NiwgSU9QTCA9IDANCmN1cnJlbnQgcHJvY2VzcwkJPSAyODYxMCAoWEY4Nl9T VkdBKQ0KdHJhcCBudW1iZXIJCT0gMTINCnBhbmljOiBwYWdlIGZhdWx0DQoNCnN5bmNpbmcg ZGlza3MuLi4gcGFuaWM6IGJ3cml0ZTogYnVmZmVyIGlzIG5vdCBidXN5Pz8/DQpVcHRpbWU6 IDNoMzFtMTlzDQpwZnNfdm5jYWNoZV91bmxvYWQoKTogMSBlbnRyaWVzIHJlbWFpbmluZw0K DQpkdW1waW5nIHRvIGRldiBhZDBzMWIsIG9mZnNldCA3MjE5Mg0KZHVtcCBhdGEwOiByZXNl dHRpbmcgZGV2aWNlcyAuLiBkb25lDQo2NCA2MyA2MiA2MSA2MCA1OSA1OCA1NyA1NiA1NSA1 NCA1MyA1MiA1MSA1MCA0OSA0OCA0NyA0NiA0NSA0NCA0MyA0MiA0MSA0MCAzOSAzOCAzNyAz NiAzNSAzNCAzMyAzMiAzMSAzMCAyOSAyOCAyNyAyNiAyNSAyNCAyMyAyMiAyMSAyMCAxOSAx OCAxNyAxNiAxNSAxNCAxMyAxMiAxMSAxMCA5IDggNyA2IDUgNCAzIDIgMSBzdWNjZWVkZWQN CkF1dG9tYXRpYyByZWJvb3QgaW4gMTUgc2Vjb25kcyAtIHByZXNzIGEga2V5IG9uIHRoZSBj b25zb2xlIHRvIGFib3J0DQpSZWJvb3RpbmcuLi4NCkNvcHlyaWdodCAoYykgMTk5Mi0yMDAx IFRoZSBGcmVlQlNEIFByb2plY3QuDQpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMs IDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQNCglUaGUgUmVnZW50 cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVk Lg0KRnJlZUJTRCA1LjAtQ1VSUkVOVCAjMTI0OiBTYXQgRGVjICA4IDAzOjIwOjQwIEVFVCAy MDAxDQogICAgcm9vdEBub3RlYm9vazovdXNyL3NyYy9zeXMvaTM4Ni9jb21waWxlL05PVEVC T09LDQpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhj MDM0NjAwMC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvc25kX3BjbS5r byIgYXQgMHhjMDM0NjBhOC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwv c25kX2Vzcy5rbyIgYXQgMHhjMDM0NjE1NC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9v dC9rZXJuZWwvc25kX3NiYy5rbyIgYXQgMHhjMDM0NjIwMC4NClRpbWVjb3VudGVyICJpODI1 NCIgIGZyZXF1ZW5jeSAxMTkzMzk1IEh6DQpDUFU6IFBlbnRpdW0vUDU1QyAocXVhcnRlci1t aWNyb24pICgyNjYuNTktTUh6IDU4Ni1jbGFzcyBDUFUpDQogIE9yaWdpbiA9ICJHZW51aW5l SW50ZWwiICBJZCA9IDB4NTgxICBTdGVwcGluZyA9IDENCiAgRmVhdHVyZXM9MHg4MDAxYmY8 RlBVLFZNRSxERSxQU0UsVFNDLE1TUixNQ0UsQ1g4LE1NWD4NCnJlYWwgbWVtb3J5ICA9IDY3 MTA4ODY0ICg2NTUzNksgYnl0ZXMpDQphdmFpbCBtZW1vcnkgPSA2MTg1MzY5NiAoNjA0MDRL IGJ5dGVzKQ0KSW50ZWwgUGVudGl1bSBkZXRlY3RlZCwgaW5zdGFsbGluZyB3b3JrYXJvdW5k IGZvciBGMDBGIGJ1Zw0KVkVTQTogdjEuMiwgMTk4NGsgbWVtb3J5LCBmbGFnczoweDAsIG1v ZGUgdGFibGU6MHhjMDBjNGU3OCAoYzAwMDRlNzgpDQpWRVNBOiBTMyBJbmNvcnBvcmF0ZWQu IDg2Q002NQ0KYXBtMDogPEFQTSBCSU9TPiBvbiBtb3RoZXJib2FyZA0KYXBtMDogZm91bmQg QVBNIEJJT1MgdjEuMiwgY29ubmVjdGVkIGF0IHYxLjINCm5weDA6IDxtYXRoIHByb2Nlc3Nv cj4gb24gbW90aGVyYm9hcmQNCm5weDA6IElOVCAxNiBpbnRlcmZhY2UNCnBjaWIwOiA8SG9z dCB0byBQQ0kgYnJpZGdlPiBhdCBwY2lidXMgMCBvbiBtb3RoZXJib2FyZA0KcGNpMDogPFBD SSBidXM+IG9uIHBjaWIwDQpwY2ljMDogPFRJIFBDSS0xMTMxIFBDSS1DYXJkQnVzIEJyaWRn ZT4gbWVtIDB4N2ZmZmUwMDAtMHg3ZmZmZWZmZiBpcnEgMTEgYXQgZGV2aWNlIDEyLjAgb24g cGNpMA0KcGNpYzA6IFRJMTEzWCBQQ0kgQ29uZmlnIFJlZzogW3NwZWFrZXIgZW5hYmxlXVtD U0Mgc2VyaWFsIGlzYSBpcnFdDQpwY2NhcmQwOiA8UEMgQ2FyZCBidXMgKGNsYXNzaWMpPiBv biBwY2ljMA0KcGNpYzE6IDxUSSBQQ0ktMTEzMSBQQ0ktQ2FyZEJ1cyBCcmlkZ2U+IG1lbSAw eDdmZmZmMDAwLTB4N2ZmZmZmZmYgaXJxIDExIGF0IGRldmljZSAxMi4xIG9uIHBjaTANCnBj aWMxOiBUSTExM1ggUENJIENvbmZpZyBSZWc6IFtzcGVha2VyIGVuYWJsZV1bQ1NDIHNlcmlh bCBpc2EgaXJxXQ0KcGNjYXJkMTogPFBDIENhcmQgYnVzIChjbGFzc2ljKT4gb24gcGNpYzEN CnBjaTA6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAxMy4wIChubyBkcml2ZXIgYXR0YWNo ZWQpDQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMTQuMCBvbiBwY2kwDQpp c2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0YXBjaTA6IDxHZW5lcmljIFBDSSBBVEEgY29u dHJvbGxlcj4gcG9ydCAweGIxNDAtMHhiMTRmLDAtMHgzLDAtMHg3LDAtMHgzLDAtMHg3IGly cSAwIGF0IGRldmljZSAxNC4xIG9uIHBjaTANCmF0YTA6IGF0IDB4MWYwIGlycSAxNCBvbiBh dGFwY2kwDQphdGExOiBhdCAweDE3MCBpcnEgMTUgb24gYXRhcGNpMA0KcGNpYy06IHBjaWMw IGFscmVhZHkgZXhpc3RzLCBza2lwcGluZyBpdA0KcGNpYy06IHBjaWMxIGFscmVhZHkgZXhp c3RzLCBza2lwcGluZyBpdA0Kc2MtOiBzYzAgYWxyZWFkeSBleGlzdHMsIHNraXBwaW5nIGl0 DQp2Z2EtOiB2Z2EwIGFscmVhZHkgZXhpc3RzLCBza2lwcGluZyBpdA0Kb3JtMDogPE9wdGlv biBST00+IGF0IGlvbWVtIDB4YzAwMDAtMHhjYmZmZiBvbiBpc2EwDQpzYzA6IDxTeXN0ZW0g Y29uc29sZT4gb24gaXNhMA0Kc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdz PTB4MjAwPg0KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBp b21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRy b2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMA0KYXRrYmQwOiA8QVQg S2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIg b24gYXRrYmRjMA0KcHNtMDogbW9kZWwgR2VuZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQg MA0KZmRjMDogPE5FQyA3MjA2NUIgb3IgY2xvbmU+IGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgz ZjcgaXJxIDYgZHJxIDIgb24gaXNhMA0KZmRjMDogRklGTyBlbmFibGVkLCA4IGJ5dGVzIHRo cmVzaG9sZA0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZlIDANCnBt dGltZXIwIG9uIGlzYTANCnNpbzAgYXQgcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2Ew DQpzaW8wOiB0eXBlIDE2NTUwQQ0KdW5rbm93bjogPFBOUDA3MDA+IGNhbid0IGFzc2lnbiBy ZXNvdXJjZXMNCnNiYzA6IDxFU1MgRVMxODc4PiBhdCBwb3J0IDB4MjIwLTB4MjJmLDB4Mzg4 LTB4MzhiLDB4MzMwLTB4MzMxIGlycSA1IGRycSAxLDAgb24gaXNhMA0KcGNtMDogPEVTUyAx OHh4IERTUD4gb24gc2JjMA0KdW5rbm93bjogPFBOUDAzMDM+IGNhbid0IGFzc2lnbiByZXNv dXJjZXMNCnVua25vd246IDxQTlAwZjEzPiBjYW4ndCBhc3NpZ24gcmVzb3VyY2VzDQp1bmtu b3duOiA8Q1BRYWU0OD4gY2FuJ3QgYXNzaWduIHJlc291cmNlcw0KYWQwOiA0ODg3TUIgPElC TS1EUExBLTI1MTIwPiBbMTA1OTIvMTUvNjNdIGF0IGF0YTAtbWFzdGVyIEJJT1NETUENCmFj ZDA6IENEUk9NIDxDT01QQVEgQ1JELVMzMTE+IGF0IGF0YTAtc2xhdmUgUElPMw0KTW91bnRp bmcgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMxYQ0KcGNjYXJkOiBjYXJkIGluc2VydGVkLCBz bG90IDANCldBUk5JTkc6IC8gd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkDQovOiBsb3N0 IGJsb2NrcyA5OCBmaWxlcyAxMg0KLzogcmVsb2FkIHBlbmRpbmcgZXJyb3I6IGJsb2NrcyA5 OCBmaWxlcyAxMg0KZWQwIGF0IHBvcnQgMHgyODAtMHgyOWYgaXJxIDExIHNsb3QgMCBvbiBw Y2NhcmQwDQplZDA6IGFkZHJlc3MgMDA6ODA6Yzg6ODg6ODY6YjEsIHR5cGUgTkUyMDAwICgx NiBiaXQpIA0KV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBg YnVmZGFlbW9uJyB0byBzdG9wLi4uc3RvcHBlZA0KV2FpdGluZyAobWF4IDYwIHNlY29uZHMp IGZvciBzeXN0ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4uc3RvcHBlZA0KDQpzeW5j aW5nIGRpc2tzLi4uIDcgNyAyIDIgDQpkb25lDQpVcHRpbWU6IDJtNTdzDQpSZWJvb3Rpbmcu Li4NCkNvcHlyaWdodCAoYykgMTk5Mi0yMDAxIFRoZSBGcmVlQlNEIFByb2plY3QuDQpDb3B5 cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5 OTIsIDE5OTMsIDE5OTQNCglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxp Zm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KRnJlZUJTRCA1LjAtQ1VSUkVOVCAjMTI0 OiBTYXQgRGVjICA4IDAzOjIwOjQwIEVFVCAyMDAxDQogICAgcm9vdEBub3RlYm9vazovdXNy L3NyYy9zeXMvaTM4Ni9jb21waWxlL05PVEVCT09LDQpQcmVsb2FkZWQgZWxmIGtlcm5lbCAi L2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhjMDM0NjAwMC4NClByZWxvYWRlZCBlbGYgbW9k dWxlICIvYm9vdC9rZXJuZWwvc25kX3BjbS5rbyIgYXQgMHhjMDM0NjBhOC4NClByZWxvYWRl ZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvc25kX2Vzcy5rbyIgYXQgMHhjMDM0NjE1NC4N ClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvc25kX3NiYy5rbyIgYXQgMHhj MDM0NjIwMC4NClRpbWVjb3VudGVyICJpODI1NCIgIGZyZXF1ZW5jeSAxMTkzMzk0IEh6DQpD UFU6IFBlbnRpdW0vUDU1QyAocXVhcnRlci1taWNyb24pICgyNjYuNTktTUh6IDU4Ni1jbGFz cyBDUFUpDQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NTgxICBTdGVwcGlu ZyA9IDENCiAgRmVhdHVyZXM9MHg4MDAxYmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixNQ0Us Q1g4LE1NWD4NCnJlYWwgbWVtb3J5ICA9IDY3MTA4ODY0ICg2NTUzNksgYnl0ZXMpDQphdmFp bCBtZW1vcnkgPSA2MTg1MzY5NiAoNjA0MDRLIGJ5dGVzKQ0KSW50ZWwgUGVudGl1bSBkZXRl Y3RlZCwgaW5zdGFsbGluZyB3b3JrYXJvdW5kIGZvciBGMDBGIGJ1Zw0KVkVTQTogdjEuMiwg MTk4NGsgbWVtb3J5LCBmbGFnczoweDAsIG1vZGUgdGFibGU6MHhjMDBjNGU3OCAoYzAwMDRl NzgpDQpWRVNBOiBTMyBJbmNvcnBvcmF0ZWQuIDg2Q002NQ0KYXBtMDogPEFQTSBCSU9TPiBv biBtb3RoZXJib2FyZA0KYXBtMDogZm91bmQgQVBNIEJJT1MgdjEuMiwgY29ubmVjdGVkIGF0 IHYxLjINCm5weDA6IDxtYXRoIHByb2Nlc3Nvcj4gb24gbW90aGVyYm9hcmQNCm5weDA6IElO VCAxNiBpbnRlcmZhY2UNCnBjaWIwOiA8SG9zdCB0byBQQ0kgYnJpZGdlPiBhdCBwY2lidXMg MCBvbiBtb3RoZXJib2FyZA0KcGNpMDogPFBDSSBidXM+IG9uIHBjaWIwDQpwY2ljMDogPFRJ IFBDSS0xMTMxIFBDSS1DYXJkQnVzIEJyaWRnZT4gbWVtIDB4N2ZmZmUwMDAtMHg3ZmZmZWZm ZiBpcnEgMTEgYXQgZGV2aWNlIDEyLjAgb24gcGNpMA0KcGNpYzA6IFRJMTEzWCBQQ0kgQ29u ZmlnIFJlZzogW3NwZWFrZXIgZW5hYmxlXVtDU0Mgc2VyaWFsIGlzYSBpcnFdDQpwY2NhcmQw OiA8UEMgQ2FyZCBidXMgKGNsYXNzaWMpPiBvbiBwY2ljMA0KcGNpYzE6IDxUSSBQQ0ktMTEz MSBQQ0ktQ2FyZEJ1cyBCcmlkZ2U+IG1lbSAweDdmZmZmMDAwLTB4N2ZmZmZmZmYgaXJxIDEx IGF0IGRldmljZSAxMi4xIG9uIHBjaTANCnBjaWMxOiBUSTExM1ggUENJIENvbmZpZyBSZWc6 IFtzcGVha2VyIGVuYWJsZV1bQ1NDIHNlcmlhbCBpc2EgaXJxXQ0KcGNjYXJkMTogPFBDIENh cmQgYnVzIChjbGFzc2ljKT4gb24gcGNpYzENCnBjaTA6IDxkaXNwbGF5LCBWR0E+IGF0IGRl dmljZSAxMy4wIChubyBkcml2ZXIgYXR0YWNoZWQpDQppc2FiMDogPFBDSS1JU0EgYnJpZGdl PiBhdCBkZXZpY2UgMTQuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0 YXBjaTA6IDxHZW5lcmljIFBDSSBBVEEgY29udHJvbGxlcj4gcG9ydCAweGIxNDAtMHhiMTRm LDAtMHgzLDAtMHg3LDAtMHgzLDAtMHg3IGlycSAwIGF0IGRldmljZSAxNC4xIG9uIHBjaTAN CmF0YTA6IGF0IDB4MWYwIGlycSAxNCBvbiBhdGFwY2kwDQphdGExOiBhdCAweDE3MCBpcnEg MTUgb24gYXRhcGNpMA0KcGNpYy06IHBjaWMwIGFscmVhZHkgZXhpc3RzLCBza2lwcGluZyBp dA0KcGNpYy06IHBjaWMxIGFscmVhZHkgZXhpc3RzLCBza2lwcGluZyBpdA0Kc2MtOiBzYzAg YWxyZWFkeSBleGlzdHMsIHNraXBwaW5nIGl0DQp2Z2EtOiB2Z2EwIGFscmVhZHkgZXhpc3Rz LCBza2lwcGluZyBpdA0Kb3JtMDogPE9wdGlvbiBST00+IGF0IGlvbWVtIDB4YzAwMDAtMHhj YmZmZiBvbiBpc2EwDQpzYzA6IDxTeXN0ZW0gY29uc29sZT4gb24gaXNhMA0Kc2MwOiBWR0Eg PDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MjAwPg0KdmdhMDogPEdlbmVyaWMgSVNB IFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNh MA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYw LDB4NjQgb24gaXNhMA0KYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAN CnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMA0KcHNtMDogbW9kZWwgR2Vu ZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQgMA0KZmRjMDogPE5FQyA3MjA2NUIgb3IgY2xv bmU+IGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNhMA0KZmRj MDogRklGTyBlbmFibGVkLCA4IGJ5dGVzIHRocmVzaG9sZA0KZmQwOiA8MTQ0MC1LQiAzLjUi IGRyaXZlPiBvbiBmZGMwIGRyaXZlIDANCnBtdGltZXIwIG9uIGlzYTANCnNpbzAgYXQgcG9y dCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2EwDQpzaW8wOiB0eXBlIDE2NTUwQQ0KdW5rbm93 bjogPFBOUDA3MDA+IGNhbid0IGFzc2lnbiByZXNvdXJjZXMNCnNiYzA6IDxFU1MgRVMxODc4 PiBhdCBwb3J0IDB4MjIwLTB4MjJmLDB4Mzg4LTB4MzhiLDB4MzMwLTB4MzMxIGlycSA1IGRy cSAxLDAgb24gaXNhMA0KcGNtMDogPEVTUyAxOHh4IERTUD4gb24gc2JjMA0KdW5rbm93bjog PFBOUDAzMDM+IGNhbid0IGFzc2lnbiByZXNvdXJjZXMNCnVua25vd246IDxQTlAwZjEzPiBj YW4ndCBhc3NpZ24gcmVzb3VyY2VzDQp1bmtub3duOiA8Q1BRYWU0OD4gY2FuJ3QgYXNzaWdu IHJlc291cmNlcw0KYWQwOiA0ODg3TUIgPElCTS1EUExBLTI1MTIwPiBbMTA1OTIvMTUvNjNd IGF0IGF0YTAtbWFzdGVyIEJJT1NETUENCmFjZDA6IENEUk9NIDxDT01QQVEgQ1JELVMzMTE+ IGF0IGF0YTAtc2xhdmUgUElPMw0KTW91bnRpbmcgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMx YQ0KcGNjYXJkOiBjYXJkIGluc2VydGVkLCBzbG90IDANCmVkMCBhdCBwb3J0IDB4MjgwLTB4 MjlmIGlycSAxMSBzbG90IDAgb24gcGNjYXJkMA0KZWQwOiBhZGRyZXNzIDAwOjgwOmM4Ojg4 Ojg2OmIxLCB0eXBlIE5FMjAwMCAoMTYgYml0KSANCldhaXRpbmcgKG1heCA2MCBzZWNvbmRz KSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1vbicgdG8gc3RvcC4uLnN0b3BwZWQNCldh aXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYHN5bmNlcicgdG8g c3RvcC4uLnN0b3BwZWQNCg0Kc3luY2luZyBkaXNrcy4uLiAxOCAxOCAxIDEgDQpkb25lDQpV cHRpbWU6IDI1bTU1cw0KUmVib290aW5nLi4uDQpDb3B5cmlnaHQgKGMpIDE5OTItMjAwMSBU aGUgRnJlZUJTRCBQcm9qZWN0Lg0KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAx OTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0DQoJVGhlIFJlZ2VudHMg b2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4N CkZyZWVCU0QgNS4wLUNVUlJFTlQgIzA6IE1vbiBEZWMgMTAgMTI6NDY6MTIgRUVUIDIwMDEN CiAgICByb290QG5vdGVib29rOi91c3Ivc3JjL3N5cy9pMzg2L2NvbXBpbGUvTk9URUJPT0sN ClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGMwMzQz MDAwLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9zbmRfcGNtLmtvIiBh dCAweGMwMzQzMGE4Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9zbmRf ZXNzLmtvIiBhdCAweGMwMzQzMTU0Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tl cm5lbC9zbmRfc2JjLmtvIiBhdCAweGMwMzQzMjAwLg0KVGltZWNvdW50ZXIgImk4MjU0IiAg ZnJlcXVlbmN5IDExOTMzOTQgSHoNCkNQVTogUGVudGl1bS9QNTVDIChxdWFydGVyLW1pY3Jv bikgKDI2Ni41OS1NSHogNTg2LWNsYXNzIENQVSkNCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRl bCIgIElkID0gMHg1ODEgIFN0ZXBwaW5nID0gMQ0KICBGZWF0dXJlcz0weDgwMDFiZjxGUFUs Vk1FLERFLFBTRSxUU0MsTVNSLE1DRSxDWDgsTU1YPg0KcmVhbCBtZW1vcnkgID0gNjcxMDg4 NjQgKDY1NTM2SyBieXRlcykNCmF2YWlsIG1lbW9yeSA9IDYxODY1OTg0ICg2MDQxNksgYnl0 ZXMpDQpJbnRlbCBQZW50aXVtIGRldGVjdGVkLCBpbnN0YWxsaW5nIHdvcmthcm91bmQgZm9y IEYwMEYgYnVnDQpWRVNBOiB2MS4yLCAxOTg0ayBtZW1vcnksIGZsYWdzOjB4MCwgbW9kZSB0 YWJsZToweGMwMGM0ZTc4IChjMDAwNGU3OCkNClZFU0E6IFMzIEluY29ycG9yYXRlZC4gODZD TTY1DQphcG0wOiA8QVBNIEJJT1M+IG9uIG1vdGhlcmJvYXJkDQphcG0wOiBmb3VuZCBBUE0g QklPUyB2MS4yLCBjb25uZWN0ZWQgYXQgdjEuMg0KbnB4MDogPG1hdGggcHJvY2Vzc29yPiBv biBtb3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGludGVyZmFjZQ0KcGNpYjA6IDxIb3N0IHRv IFBDSSBicmlkZ2U+IGF0IHBjaWJ1cyAwIG9uIG1vdGhlcmJvYXJkDQpwY2kwOiA8UENJIGJ1 cz4gb24gcGNpYjANCnBjaWMwOiA8VEkgUENJLTExMzEgUENJLUNhcmRCdXMgQnJpZGdlPiBt ZW0gMHg3ZmZmZTAwMC0weDdmZmZlZmZmIGlycSAxMSBhdCBkZXZpY2UgMTIuMCBvbiBwY2kw DQpwY2ljMDogVEkxMTNYIFBDSSBDb25maWcgUmVnOiBbc3BlYWtlciBlbmFibGVdW0NTQyBz ZXJpYWwgaXNhIGlycV0NCnBjY2FyZDA6IDxQQyBDYXJkIGJ1cyAoY2xhc3NpYyk+IG9uIHBj aWMwDQpwY2ljMTogPFRJIFBDSS0xMTMxIFBDSS1DYXJkQnVzIEJyaWRnZT4gbWVtIDB4N2Zm ZmYwMDAtMHg3ZmZmZmZmZiBpcnEgMTEgYXQgZGV2aWNlIDEyLjEgb24gcGNpMA0KcGNpYzE6 IFRJMTEzWCBQQ0kgQ29uZmlnIFJlZzogW3NwZWFrZXIgZW5hYmxlXVtDU0Mgc2VyaWFsIGlz YSBpcnFdDQpwY2NhcmQxOiA8UEMgQ2FyZCBidXMgKGNsYXNzaWMpPiBvbiBwY2ljMQ0KcGNp MDogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDEzLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkN CmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAxNC4wIG9uIHBjaTANCmlzYTA6 IDxJU0EgYnVzPiBvbiBpc2FiMA0KYXRhcGNpMDogPEdlbmVyaWMgUENJIEFUQSBjb250cm9s bGVyPiBwb3J0IDB4YjE0MC0weGIxNGYsMC0weDMsMC0weDcsMC0weDMsMC0weDcgaXJxIDAg YXQgZGV2aWNlIDE0LjEgb24gcGNpMA0KYXRhMDogYXQgMHgxZjAgaXJxIDE0IG9uIGF0YXBj aTANCmF0YTE6IGF0IDB4MTcwIGlycSAxNSBvbiBhdGFwY2kwDQpwY2ljLTogcGNpYzAgYWxy ZWFkeSBleGlzdHMsIHNraXBwaW5nIGl0DQpwY2ljLTogcGNpYzEgYWxyZWFkeSBleGlzdHMs IHNraXBwaW5nIGl0DQpzYy06IHNjMCBhbHJlYWR5IGV4aXN0cywgc2tpcHBpbmcgaXQNCnZn YS06IHZnYTAgYWxyZWFkeSBleGlzdHMsIHNraXBwaW5nIGl0DQpvcm0wOiA8T3B0aW9uIFJP TT4gYXQgaW9tZW0gMHhjMDAwMC0weGNiZmZmIG9uIGlzYTANCnNjMDogPFN5c3RlbSBjb25z b2xlPiBvbiBpc2EwDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgy MDA+DQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVt IDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxl ciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBpc2EwDQphdGtiZDA6IDxBVCBLZXli b2FyZD4gaXJxIDEgb24gYXRrYmRjMA0KcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBh dGtiZGMwDQpwc20wOiBtb2RlbCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwDQpm ZGMwOiA8TkVDIDcyMDY1QiBvciBjbG9uZT4gYXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBp cnEgNiBkcnEgMiBvbiBpc2EwDQpmZGMwOiBGSUZPIGVuYWJsZWQsIDggYnl0ZXMgdGhyZXNo b2xkDQpmZDA6IDwxNDQwLUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMA0KcG10aW1l cjAgb24gaXNhMA0Kc2lvMCBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlzYTANCnNp bzA6IHR5cGUgMTY1NTBBDQp1bmtub3duOiA8UE5QMDcwMD4gY2FuJ3QgYXNzaWduIHJlc291 cmNlcw0Kc2JjMDogPEVTUyBFUzE4Nzg+IGF0IHBvcnQgMHgyMjAtMHgyMmYsMHgzODgtMHgz OGIsMHgzMzAtMHgzMzEgaXJxIDUgZHJxIDEsMCBvbiBpc2EwDQpwY20wOiA8RVNTIDE4eHgg RFNQPiBvbiBzYmMwDQp1bmtub3duOiA8UE5QMDMwMz4gY2FuJ3QgYXNzaWduIHJlc291cmNl cw0KdW5rbm93bjogPFBOUDBmMTM+IGNhbid0IGFzc2lnbiByZXNvdXJjZXMNCnVua25vd246 IDxDUFFhZTQ4PiBjYW4ndCBhc3NpZ24gcmVzb3VyY2VzDQphZDA6IDQ4ODdNQiA8SUJNLURQ TEEtMjUxMjA+IFsxMDU5Mi8xNS82M10gYXQgYXRhMC1tYXN0ZXIgQklPU0RNQQ0KYWNkMDog Q0RST00gPENPTVBBUSBDUkQtUzMxMT4gYXQgYXRhMC1zbGF2ZSBQSU8zDQpNb3VudGluZyBy b290IGZyb20gdWZzOi9kZXYvYWQwczFhDQpwY2NhcmQ6IGNhcmQgaW5zZXJ0ZWQsIHNsb3Qg MA0KZWQwIGF0IHBvcnQgMHgyODAtMHgyOWYgaXJxIDExIHNsb3QgMCBvbiBwY2NhcmQwDQpl ZDA6IGFkZHJlc3MgMDA6ODA6Yzg6ODg6ODY6YjEsIHR5cGUgTkUyMDAwICgxNiBiaXQpIA0K DQoNCkZhdGFsIHRyYXAgMTI6IHBhZ2UgZmF1bHQgd2hpbGUgaW4gdm04NiBtb2RlDQpmYXVs dCB2aXJ0dWFsIGFkZHJlc3MJPSAweGMwZGRjDQpmYXVsdCBjb2RlCQk9IHVzZXIgcmVhZCwg cGFnZSBub3QgcHJlc2VudA0KaW5zdHJ1Y3Rpb24gcG9pbnRlcgk9IDB4YzAwMDoweGRkYw0K c3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgwOjB4ZmE0DQpmcmFtZSBwb2ludGVyCSAgICAg ICAgPSAweDA6MHhmZTYNCmNvZGUgc2VnbWVudAkJPSBiYXNlIDB4ZTEwMDA1LCBsaW1pdCAw eDEwMDAyLCB0eXBlIDB4MTkNCgkJCT0gRFBMIDAsIHByZXMgMCwgZGVmMzIgMCwgZ3JhbiAw DQpwcm9jZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0IGVuYWJsZWQsIHJlc3VtZSwgdm04Niwg SU9QTCA9IDANCmN1cnJlbnQgcHJvY2VzcwkJPSA1NTYgKFhGODZfU1ZHQSkNCnRyYXAgbnVt YmVyCQk9IDEyDQpwYW5pYzogcGFnZSBmYXVsdA0KDQpzeW5jaW5nIGRpc2tzLi4uIHBhbmlj OiBid3JpdGU6IGJ1ZmZlciBpcyBub3QgYnVzeT8/Pw0KVXB0aW1lOiAxNG0zMXMNCnBmc192 bmNhY2hlX3VubG9hZCgpOiAxIGVudHJpZXMgcmVtYWluaW5nDQoNCmR1bXBpbmcgdG8gZGV2 IGFkMHMxYiwgb2Zmc2V0IDcyMTkyDQpkdW1wIGF0YTA6IHJlc2V0dGluZyBkZXZpY2VzIC4u IGRvbmUNCjY0IDYzIDYyIDYxIDYwIDU5IDU4IDU3IDU2IDU1IDU0IDUzIDUyIDUxIDUwIDQ5 IDQ4IDQ3IDQ2IDQ1IDQ0IDQzIDQyIDQxIDQwIDM5IDM4IDM3IDM2IDM1IDM0IDMzIDMyIDMx IDMwIDI5IDI4IDI3IDI2IDI1IDI0IDIzIDIyIDIxIDIwIDE5IDE4IDE3IDE2IDE1IDE0IDEz IDEyIDExIDEwIDkgOCA3IDYgNSA0IDMgMiAxIA0KLS0tDQojMCAgZHVtcHN5cyAoKSBhdCAu Li8uLi8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzo0OTINCjQ5MgkJaWYgKCFkb2R1bXApDQoo a2dkYikgdXANCiMxICAweGMwMTZmNmIwIGluIGJvb3QgKGhvd3RvPTI2MCkgYXQgLi4vLi4v Li4va2Vybi9rZXJuX3NodXRkb3duLmM6MzM1DQozMzUJCQlkdW1wc3lzKCk7DQooa2dkYikg dXANCiMyICAweGMwMTZmYWU3IGluIHBhbmljIChmbXQ9MHhjMDI2NTc5OCAiYndyaXRlOiBi dWZmZXIgaXMgbm90IGJ1c3k/Pz8iKQ0KICAgIGF0IC4uLy4uLy4uL2tlcm4va2Vybl9zaHV0 ZG93bi5jOjYzNA0KNjM0CQlib290KGJvb3RvcHQpOw0KKGtnZGIpIHVwDQojMyAgMHhjMDFh MTFiYiBpbiBid3JpdGUgKGJwPTB4YzFkZjE0YTgpIGF0IC4uLy4uLy4uL2tlcm4vdmZzX2Jp by5jOjY3Mg0KNjcyCQkJcGFuaWMoImJ3cml0ZTogYnVmZmVyIGlzIG5vdCBidXN5Pz8/Iik7 DQooa2dkYikgdXANCiM0ICAweGMwMWExNzdlIGluIGJhd3JpdGUgKGJwPTB4YzFkZjE0YTgp IGF0IC4uLy4uLy4uL2tlcm4vdmZzX2Jpby5jOjk4NQ0KOTg1CQkodm9pZCkgQlVGX1dSSVRF KGJwKTsNCihrZ2RiKSB1cA0KIzUgIDB4YzAxZmVjODQgaW4gZmZzX2ZzeW5jIChhcD0weGMw MzY2ZWEwKSBhdCAuLi8uLi8uLi91ZnMvZmZzL2Zmc192bm9wcy5jOjIxNw0KMjE3CQkJCQkJ KHZvaWQpIGJhd3JpdGUoYnApOw0KKGtnZGIpIHVwDQojNiAgMHhjMDFmZDJlNiBpbiBmZnNf c3luYyAobXA9MHhjMGE3MTgwMCwgd2FpdGZvcj0yLCBjcmVkPTB4YzA1ZDBiMDAsIHRkPTB4 YzAyYzBiMjQpDQogICAgYXQgdm5vZGVfaWYuaDo0NDENCjQ0MQkJcmMgPSBWQ0FMTCh2cCwg Vk9GRlNFVCh2b3BfZnN5bmMpLCAmYSk7DQooa2dkYikgdXANCiM3ICAweGMwMWFkYzM2IGlu IHN5bmMgKHRkPTB4YzAyYzBiMjQsIHVhcD0weDApIGF0IC4uLy4uLy4uL2tlcm4vdmZzX3N5 c2NhbGxzLmM6NjU3DQo2NTcJCQkJVkZTX1NZTkMobXAsIE1OVF9OT1dBSVQsDQooa2dkYikg dXANCiM4ICAweGMwMTZmMmI2IGluIGJvb3QgKGhvd3RvPTI1NikgYXQgLi4vLi4vLi4va2Vy bi9rZXJuX3NodXRkb3duLmM6MjQ0DQoyNDQJCQlzeW5jKHRocmVhZDAsIE5VTEwpOw0KKGtn ZGIpIHVwDQojOSAgMHhjMDE2ZmFlNyBpbiBwYW5pYyAoZm10PTB4YzAyNzUxZGUgIiVzIikg YXQgLi4vLi4vLi4va2Vybi9rZXJuX3NodXRkb3duLmM6NjM0DQo2MzQJCWJvb3QoYm9vdG9w dCk7DQooa2dkYikgdXANCiMxMCAweGMwMjQyYmVlIGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4 YzAzNjZmYTgsIGV2YT03ODk5ODApIGF0IC4uLy4uLy4uL2kzODYvaTM4Ni90cmFwLmM6OTUw DQo5NTAJCQlwYW5pYygiJXMiLCB0cmFwX21zZ1t0eXBlXSk7DQooa2dkYikgdXANCiMxMSAw eGMwMjQyOTQ1IGluIHRyYXBfcGZhdWx0IChmcmFtZT0weGMwMzY2ZmE4LCB1c2VybW9kZT0w LCBldmE9Nzg5OTgwKQ0KICAgIGF0IC4uLy4uLy4uL2kzODYvaTM4Ni90cmFwLmM6ODY0DQo4 NjQJCQl0cmFwX2ZhdGFsKGZyYW1lLCBldmEpOw0KKGtnZGIpIHVwDQojMTIgMHhjMDI0MjJk OCBpbiB0cmFwIChmcmFtZT17dGZfZnMgPSAwLCB0Zl9lcyA9IDAsIHRmX2RzID0gMCwgdGZf ZWRpID0gMTcyNDgsIHRmX2VzaSA9IDE2MDA4LCANCiAgICAgIHRmX2VicCA9IDQwNzAsIHRm X2lzcCA9IC0xMDcwMTc0MjUyLCB0Zl9lYnggPSA2NCwgdGZfZWR4ID0gOTgwLCB0Zl9lY3gg PSAyNDE0NCwgdGZfZWF4ID0gMCwgDQogICAgICB0Zl90cmFwbm8gPSAxMiwgdGZfZXJyID0g NCwgdGZfZWlwID0gMzU0OCwgdGZfY3MgPSA0OTE1MiwgdGZfZWZsYWdzID0gNzIxNDc4LCB0 Zl9lc3AgPSA0MDA0LCANCiAgICAgIHRmX3NzID0gMH0pIGF0IC4uLy4uLy4uL2kzODYvaTM4 Ni90cmFwLmM6NDE2DQo0MTYJCQkJKHZvaWQpIHRyYXBfcGZhdWx0KCZmcmFtZSwgRkFMU0Us IGV2YSk7DQooa2dkYikgdXANCiMxMyAweGRkYyBpbiA/PyAoKQ0KKGtnZGIpIHVwDQpDYW5u b3QgYWNjZXNzIG1lbW9yeSBhdCBhZGRyZXNzIDB4ZmU2Lg0KKGtnZGIpIHF1aXQNCnJvb3RA bm90ZWJvb2sjIGV4aXQNCgpTY3JpcHQgZG9uZSBvbiBNb24gRGVjIDEwIDEzOjA5OjM2IDIw MDEK --------------A3B48C213C1C879EC0C8D961-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 3:50:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id A139C37B416 for ; Mon, 10 Dec 2001 03:50:13 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 10 Dec 2001 11:50:11 +0000 (GMT) To: Peter Wemm Cc: Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c In-Reply-To: Your message of "Sun, 09 Dec 2001 16:43:50 PST." <20011210004350.6703C3810@overcee.netplex.com.au> Date: Mon, 10 Dec 2001 11:50:10 +0000 From: Ian Dowse Message-ID: <200112101150.aa33241@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011210004350.6703C3810@overcee.netplex.com.au>, Peter Wemm writes : >The problem is, that you **are** using fdisk tables, you have no choice. >DD mode included a *broken* fdisk table that specified an illegal geometry. ... >This is why it is called dangerous. BTW, I presume you are aware of the way sysinstall creates DD MBRs; it does not use the 50000 sector slice 4 method, but sets up slice 1 to cover the entire disk including the MBR, with c/h/s entries corresponding to the real start and end of the disk, e.g: cylinders=3544 heads=191 sectors/track=53 (10123 blks/cyl) ... The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 35885168 (17522 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 1023/ head 190/ sector 53 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Otherwise the disk layout is the same as disklabel's DD. I suspect that this approach is much less illegal than disklabel's MBRs although I do remember seeing a HP PC that disliked it. I wonder if a reasonable compromise is to make disklabel use this system for DD disks instead of the bogus 50000 sector slice? Obviously, it should also somehow not install a partition table unless boot1 is being used as the MBR, and the fdisk -I method should be preferred. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 4:31:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from email01.aon.at (WARSL401PIP7.highway.telekom.at [195.3.96.115]) by hub.freebsd.org (Postfix) with SMTP id B818437B41D for ; Mon, 10 Dec 2001 04:30:20 -0800 (PST) Received: (qmail 657318 invoked from network); 10 Dec 2001 12:30:15 -0000 Received: from n054p029.adsl.highway.telekom.at (HELO mail.kpost.com) ([213.33.6.189]) (envelope-sender ) by qmail1.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 12:30:15 -0000 From: "contractor@kpost.com" To: "5062@lycos.com" <5062@lycos.com> Message-ID: <1007991311.0499569422@mail.kpost.com> Subject: Reduce Travel Costs MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Dec 2001 04:30:20 -0800 (PST) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Take Control Of Your Conference Calls

Long Distance Conferencing
Only 18 Cents Per Minute

Connects Up To 100 Participants=21

  • No setup fees
  • No contracts or monthly fees
  • Call anytime, from anywhere, to anywhere
  • International Dial In 18 cents per minute
  • Simplicity in set up and administration
  • Operator Help available 24/7

    • G= et the best quality, the easiest to use, and lowest rate in the industry.

    If you like saving = money, fill out the form below and one of our consultants will contact you.

    Required Input Field*

    Name*
    Web Address*
    Company Name*
    State*
    Business Phone*
    Home Phone
    Email Address*
    Type of Business



    This ad is being sent in compliance with Senate Bill 1618= , Title 3, Section 301. You have recently visited our web site, referral or affiliate sit= es which indicated you were interested in communication services. If this email is reaching = you in error and you feel that you have not contacted us, Click here. We sincerely apologize, and assure you will be r= emoved from our distribution list.

    To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 4:50:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 0EAF337B41B for ; Mon, 10 Dec 2001 04:50:11 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fBACo6551264; Mon, 10 Dec 2001 13:50:06 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fBAClOtx095722; Mon, 10 Dec 2001 13:47:32 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fBAClNW04921; Mon, 10 Dec 2001 13:47:23 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fBAClMk11931; Mon, 10 Dec 2001 13:47:22 +0100 (CET) (envelope-from ticso) Date: Mon, 10 Dec 2001 13:47:21 +0100 From: Bernd Walter To: Joerg Wunsch Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011210134721.C11774@cicely8.cicely.de> References: <20011209102129.F97235@uriah.heep.sax.de> <200112092015.fB9KFJe01121@mass.dis.org> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011209224310.A17244@dragon.nuxi.com> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011210070333.D88F33810@overcee.netplex.com.au> <20011210110438.A72135@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011210110438.A72135@uriah.heep.sax.de> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 10, 2001 at 11:04:38AM +0100, Joerg Wunsch wrote: > As Peter Wemm wrote: > > > Can you please clarify for me what specifically you do not like.. Is it: > > - the cost of 32K of disk space on an average disk these days? > > (and if so, is reducing that to one sector instead of 62 sufficient?) > > The idea of a "geometry" that does not even remotely resembles the > actual geometry and only causes additional hassles, like disks being > not portable between controllers that have a different idea of that > geometry (since the design of this table is missing an actual field > to specify the geometry). Incidentally, it's only what you call > "intuition" that finally stumpled across the 10-years old Jolitz > fake fdisk values. So IOW, it took the BIOS vendors ten years to > produce a BIOS that would break on it :), and the breakage (division > by 0) was only since they needed black magic in order to infer a > geometry value that was short-sightedly never specified in the table > itself. Two points to add why I would miss that feature: - Having bootable media such as MOs or zips. - There is no way to find out the BIOS geometry when creating a bootable disk inside FreeBSD. > > - you don't like typing "s1" in the device name? > > Aesthetically, yes, this one too. :) > > > "disklabel -rw ad2 auto" is one form. That should not use fdisk at all. > > This is quite fine, and nobody wants that to go away. > > Good to hear. > > Well, actually i always use "disklabel -Brw daN auto", partly because > this sequence is wired into my fingers, and since i mentally DAbelieve > that having more bootstrappable disks couldn't harm. ;-) As laid out > in another message, i eventually got the habit of even including a > root partition mirror on each disk as well. So each of my disks should > be able to boot a single-user FreeBSD. I was already happy to have them, but I can't create a propper bootable fdisk table without knowing what the BIOS thinks about geometry. It is the typical problem that you boot DOS, fdisk /mbr and then install FreeBSD... > > I advocate that the bootable form (where boot1.s is expected to do the > > job of both the mbr *and* the partition boot) is evil and should at the very > > least be fixed. > > Fixing is OK to me. I think to recognize the dummy fdisk table of DD mode, > it would be totally sufficient to verify slice 4 being labelled with 50000 > blocks, and the other slices being labelled 0. We do not support any > physical disk anymore that is only 25 MB in size :). So all the remaining Flash Media comes in mind - but I hardly beleave it to be exactly 25M. > (INT 0x13 bootstrap) values could be anything -- even something that most > BIOSes would recognize as a valid fdisk table. > > > It should be something that is explicitly activated, and > > not something that you get whether you want it or not. > > I don't fully understand that. DD mode has always been an explicit > decision. Even in the above, the specification of -B explicitly tells > to install that bootstrap. The example in Handbook 12.3.2.2 should get the B flag removed. It's about adding disks and not about adding bootable disks. > As David O'Brien wrote: > > > > Its design is antique. Or rather: it's missing a design. > > > Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it?? > > I don't see much value in an Alpha. Maybe a Sun some day, who knows? Not for the far future - but I would still prefer them over a PC. But my biggest hopes go for the UltraSparc port. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 5:10:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by hub.freebsd.org (Postfix) with ESMTP id A589937B417; Mon, 10 Dec 2001 05:10:36 -0800 (PST) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.11.6/8.11.5) with ESMTP id fBAD7Y801018; Mon, 10 Dec 2001 08:07:35 -0500 (EST) (envelope-from mi@aldan.algebra.com) Message-Id: <200112101307.fBAD7Y801018@aldan.algebra.com> Date: Mon, 10 Dec 2001 08:07:33 -0500 (EST) From: Mikhail Teterin Subject: panic upon manual swapon(8) To: current@FreeBSD.org Cc: dillon@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I typicly run without any swap space configured -- 320Mb of RAM is usually fine. However, after noticing a message "get swap space failed" (or similar) in the nightly report, I tried to tell my Nov 5 -current to swapon /dev/da0b I used to do this with full impunity in the past, but this time the thing paniced with: IdlePTD 5033984 initial pcb at 3e3f00 panicstr: bwrite: buffer is not busy??? panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 01000000 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x8:0xc024f50f stack pointer = 0x10:0xcf0fab8c frame pointer = 0x10:0xcf0fab98 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 16315 (swapon) trap number = 12 panic: page fault cpuid = 0; lapic.id = 01000000 boot() called on cpu#0 syncing disks... panic: bwrite: buffer is not busy??? cpuid = 0; lapic.id = 01000000 boot() called on cpu#0 Uptime: 22h14m15s Some sources have been re-cvsuped since, but not the vfs_subr.c, where the actual panic occured, seemingly: #0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:492 warning: Source file is more recent than executable. 492 if (!dodump) (kgdb) where #0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:492 #1 0xc02124c0 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:335 #2 0xc021295d in panic (fmt=0xc035c878 "bwrite: buffer is not busy???") at /ccd/src/sys/kern/kern_shutdown.c:634 #3 0xc0247203 in bwrite (bp=0xc7cea51c) at /ccd/src/sys/kern/vfs_bio.c:666 #4 0xc02484bc in vfs_bio_awrite (bp=0xc7cea51c) at /ccd/src/sys/kern/vfs_bio.c:1529 #5 0xc02ce8f4 in ffs_fsync (ap=0xcf0faa44) at /ccd/src/sys/ufs/ffs/ffs_vnops.c:239 #6 0xc02ccdbe in ffs_sync (mp=0xc16be600, waitfor=2, cred=0xc1027b00, td=0xc04098e4) at vnode_if.h:441 #7 0xc0253c5a in sync (td=0xc04098e4, uap=0x0) at /ccd/src/sys/kern/vfs_syscalls.c:657 #8 0xc02120e1 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:244 #9 0xc021295d in panic (fmt=0xc0376e3e "%s") at /ccd/src/sys/kern/kern_shutdown.c:634 #10 0xc03185ea in trap_fatal (frame=0xcf0fab4c, eva=24) at /ccd/src/sys/i386/i386/trap.c:939 #11 0xc0318311 in trap_pfault (frame=0xcf0fab4c, usermode=0, eva=24) at /ccd/src/sys/i386/i386/trap.c:853 #12 0xc0317d4f in trap (frame={tf_fs = 24, tf_es = -821100528, tf_ds = -831127536, tf_edi = 2, tf_esi = 0, tf_ebp = -821056616, tf_isp = -821056648, tf_ebx = 0, tf_edx = 1, tf_ecx = -829663484, #13 0xc024f50f in vlrureclaim (mp=0x0, count=2) at /ccd/src/sys/kern/vfs_subr.c:561 #14 0xc024f58e in getnewvnode (tag=VT_NON, mp=0x0, vops=0xc163d000, vpp=0xc04167f8) at /ccd/src/sys/kern/vfs_subr.c:593 #15 0xc02e5b92 in swaponvp (td=0xce8c5704, vp=0xce818080, dev=0xc1714f00, nblks=0) at /ccd/src/sys/vm/vm_swap.c:268 #16 0xc02e5b02 in swapon (td=0xce8c5704, uap=0xcf0fad20) at /ccd/src/sys/vm/vm_swap.c:230 #17 0xc0318a98 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077938364, tf_esi = 2, tf_ebp = -1077938372, tf_isp = -821056140, tf_ebx = -1077938105, tf_edx = 0, tf_ecx = 134571136, tf_eax = 85, tf_trapno = 12, tf_err = 2, tf_eip = 134515980, tf_cs = 31, tf_eflags = 659, tf_esp = -1077938568, tf_ss = 47}) at /ccd/src/sys/i386/i386/trap.c:1129 18 0xc030727d 0xc030727din syscall_with_err_pushed () #19 0x0 in ?? () (kgdb) up 13 #13 0xc024f50f in vlrureclaim (mp=0x0, count=2) at /ccd/src/sys/kern/vfs_subr.c:561 561 } [...] env LANG=C ls -l /ccd/src/sys/kern/vfs_subr.c -rw-r--r-- 1 mi wheel 76055 Nov 4 16:34 /ccd/src/sys/kern/vfs_subr.c [...] (kgdb) up #14 0xc024f58e in getnewvnode (tag=VT_NON, mp=0x0, vops=0xc163d000, vpp=0xc04167f8) at /ccd/src/sys/kern/vfs_subr.c:593 593 vlrureclaim(mp, 2); (kgdb) p mp $1 = (struct mount *) 0x0 Anything else? Thanks, -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 5:50:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 2416037B416 for ; Mon, 10 Dec 2001 05:50:34 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id OAA15175 for freebsd-current@FreeBSD.ORG; Mon, 10 Dec 2001 14:50:32 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fBADKC775946 for freebsd-current@FreeBSD.ORG; Mon, 10 Dec 2001 14:20:12 +0100 (MET) (envelope-from j) Date: Mon, 10 Dec 2001 14:20:11 +0100 From: Joerg Wunsch To: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011210142011.A75760@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-current@FreeBSD.ORG References: <20011209102129.F97235@uriah.heep.sax.de> <20011210004350.6703C3810@overcee.netplex.com.au> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011210005928.9538A3810@overcee.netplex.com.au> <20011210091103.M97235@uriah.heep.sax.de> <3C1488CF.410BE633@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C1488CF.410BE633@mindspring.com>; from tlambert2@mindspring.com on Mon, Dec 10, 2001 at 02:05:03AM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As Terry Lambert wrote: > Joerg Wunsch wrote: > > /The/ major advantage of DD mode was that all BIOSes (so far :) at > > least agree on how to access block 0 and the adjacent blocks, so > > starting our own system there makes those disks portable. > I guarantee you that there are a number of controllers which have > different ideas of how to do soft sector sparing _at the controller > level_ rather than at the drive level. We have dropped support for ESDI controllers long since. :-) Seriously, all the disks we are supporting these days do bad block replacement at the drive level. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 6:10:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 457F737B405 for ; Mon, 10 Dec 2001 06:10:26 -0800 (PST) Received: from pool0062.cvx22-bradley.dialup.earthlink.net ([209.179.198.62] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DR8R-0002p7-00; Mon, 10 Dec 2001 06:10:23 -0800 Message-ID: <3C14C256.549553DD@mindspring.com> Date: Mon, 10 Dec 2001 06:10:30 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joerg Wunsch Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c References: <20011209102129.F97235@uriah.heep.sax.de> <20011210004350.6703C3810@overcee.netplex.com.au> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011210005928.9538A3810@overcee.netplex.com.au> <20011210091103.M97235@uriah.heep.sax.de> <3C1488CF.410BE633@mindspring.com> <20011210142011.A75760@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Joerg Wunsch wrote: > > I guarantee you that there are a number of controllers which have > > different ideas of how to do soft sector sparing _at the controller > > level_ rather than at the drive level. > > We have dropped support for ESDI controllers long since. :-) > > Seriously, all the disks we are supporting these days do bad block > replacement at the drive level. Adaptec 1742 is supported, though it took a long enough time to find its way into CAM. Same for the NCR 810. For certain applications, also, you _want_ to turn off the automatic bad sector sparing: it's incompatible with spindle sync, for example, where you want to spare all drives or none, so that the spindles don't desyncronize on a sparing hit for one drive, but not another. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 6:53: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 3B82F37B419 for ; Mon, 10 Dec 2001 06:52:49 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBAEpR942605; Mon, 10 Dec 2001 16:51:27 +0200 (EET) (envelope-from ru) Date: Mon, 10 Dec 2001 16:51:27 +0200 From: Ruslan Ermilov To: Peter Wemm Cc: Mathieu Arnold , Warner Losh , current@FreeBSD.ORG Subject: Re: stable->current busted Message-ID: <20011210165127.A42117@sunbay.com> References: <3C106394.A9803F72@club-internet.fr> <20011208210832.2FC593808@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011208210832.2FC593808@overcee.netplex.com.au> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 01:08:32PM -0800, Peter Wemm wrote: > Mathieu Arnold wrote: > > > > Warner Losh wrote: > > > > > > 4.4-r -> current build is very broken right now. I'll investigate and > > > fix. > > > > last time I did it, I had a problem with install, adding LDFLAGS+= > > -static to src/usr.bin/xinstall/Makefile fixed the problem. > > the problem was using install linked to libc.so.4 to do something like > > this : > > rm libc.so.4 > > install libc.so.4 > > which was failing for obvious reasons :) > > I think this will fix it: > > http://people.freebsd.org/~peter/compat.diff > > I would have liked to change the 'beforeinstall' to 'afterinstall' in > Makefile.inc, but afterinstall seems to not be usable. Another option is > this: > This makes `afterinstall' useable: Index: Makefile.inc =================================================================== RCS file: /home/ncvs/src/lib/compat/Makefile.inc,v retrieving revision 1.8 diff -u -r1.8 Makefile.inc --- Makefile.inc 2001/09/22 08:11:24 1.8 +++ Makefile.inc 2001/12/10 14:50:41 @@ -3,8 +3,7 @@ LIBCOMPATDIR?= ${LIBDIR}/compat/aout .if defined(LIBS) && !empty(LIBS) -beforeinstall: __remove-stale-libs -__remove-stale-libs: .PHONY +afterinstall: .for lib in ${LIBS} .if exists(${DESTDIR}${SHLIBDIR}/${lib}) -chflags noschg ${DESTDIR}${SHLIBDIR}/${lib} /me browses how many makefiles have afterinstall: depend on something else. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 8:36:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by hub.freebsd.org (Postfix) with ESMTP id 5C36E37B416; Mon, 10 Dec 2001 08:36:53 -0800 (PST) Received: (from ak03@localhost) by h132-197-179-27.gte.com (8.11.6/8.11.4) id fBAGaqR01450; Mon, 10 Dec 2001 11:36:52 -0500 (EST) (envelope-from ak03) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 10 Dec 2001 11:36:51 -0500 (EST) Organization: Verizon Laboratories Inc. From: "Alexander N. Kabaev" To: freebsd-current@freebsd.org Subject: NULLFS panic in -CURRENT Cc: bp@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG My -CURRENT box got this panic tonight. Apparently, null_inactive tries to vput NULL lowervp vnode, but how lowervp has managed to become NULL is not immediately clear for me :( I have crash dump available, if anyone is interested. #0 dumpsys () at ../../../kern/kern_shutdown.c:492 #1 0xc01f4ab8 in boot (howto=0x104) at ../../../kern/kern_shutdown.c:335 #2 0xc01f4f07 in panic (fmt=0xc032cbd9 "bremfree: bp %p not locked") at ../../../kern/kern_shutdown.c:634 #3 0xc0222c29 in bremfree (bp=0xc6df7cf0) at ../../../kern/vfs_bio.c:539 #4 0xc0224261 in vfs_bio_awrite (bp=0xc6df7cf0) at ../../../kern/vfs_bio.c:1528 #5 0xc01d5ff4 in spec_fsync (ap=0xd197c9c8) at ../../../fs/specfs/spec_vnops.c:404 #6 0xc01d5bad in spec_vnoperate (ap=0xd197c9c8) at ../../../fs/specfs/spec_vnops.c:119 #7 0xc02ae621 in ffs_sync (mp=0xc1c69600, waitfor=0x2, cred=0xc0e5ac00, td=0xc03dc164) at vnode_if.h:441 #8 0xc022f4ea in sync (td=0xc03dc164, uap=0x0) at ../../../kern/vfs_syscalls.c:657 #9 0xc01f478d in boot (howto=0x100) at ../../../kern/kern_shutdown.c:244 #10 0xc01f4f07 in panic (fmt=0xc032e6da "vput: null vp") at ../../../kern/kern_shutdown.c:634 #11 0xc022cdbd in vput (vp=0x0) at ../../../kern/vfs_subr.c:1665 #12 0xc1cba606 in null_inactive (ap=0xd197caa8) at /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:728 #13 0xc022ce86 in vput (vp=0xd1fc5840) at vnode_if.h:654 #14 0xc0492287 in nfs_lookup (ap=0xd197cbc4) at /usr/src/sys/modules/nfsclient/../../nfsclient/nfs_vnops.c:808 #15 0xc022a8f9 in lookup (ndp=0xd197cc44) at vnode_if.h:45 #16 0xc022a3e4 in namei (ndp=0xd197cc44) at ../../../kern/vfs_lookup.c:168 #17 0xc0231375 in stat (td=0xd1899704, uap=0xd197cd20) at ../../../kern/vfs_syscalls.c:1976 #18 0xc02ec147 in syscall (frame={tf_fs = 0x2f, tf_es = 0xbfbf002f, tf_ds = 0xbfbf002f, tf_edi = 0xbfbffe3a, tf_esi = 0xbfbff938, tf_ebp = 0xbfbff998, tf_isp = 0xd197cd74, tf_ebx = 0x810a720, tf_edx = 0x1, tf_ecx = 0x3, tf_eax = 0xbc, tf_trapno = 0x0, tf_err = 0x2, tf_eip = 0x2830b9e3, tf_cs = 0x1f, tf_eflags = 0x200287, tf_esp = 0xbfbff50c, tf_ss = 0x2f}) at ../../../i386/i386/trap.c:1140 #19 0xc02dfc1d in syscall_with_err_pushed () #20 0x8094e81 in ?? () #21 0x809a0ec in ?? () #22 0x8064dfb in ?? () #23 0x806d38c in ?? () #24 0x804d841 in ?? () (kgdb) -------------------------------------------- E-Mail: Alexander N. Kabaev Date: 10-Dec-2001 Time: 11:18:02 -------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 9:43: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 8C56137B417; Mon, 10 Dec 2001 09:43:03 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBAHmcV01138; Mon, 10 Dec 2001 09:48:38 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112101748.fBAHmcV01138@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: freebsd-current@FreeBSD.org Subject: Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c) In-reply-to: Your message of "Mon, 10 Dec 2001 19:27:09 +1030." <20011210192709.H63585@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Dec 2001 09:48:38 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > What is it about this particular topic brings out such irrational > emotions in you and others? Because you define as "irrational" those opinions that don't agree with = your own. I don't consider my stance "irrational" at all, and I find = your leaps past logic and commonsense quite "irrational" in return. -- = =2E.. every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 9:49: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 2D16037B405 for ; Mon, 10 Dec 2001 09:48:56 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBAHsRV01202; Mon, 10 Dec 2001 09:54:27 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112101754.fBAHsRV01202@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c In-reply-to: Your message of "Mon, 10 Dec 2001 06:10:30 PST." <3C14C256.549553DD@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Dec 2001 09:54:27 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Joerg Wunsch wrote: > > > I guarantee you that there are a number of controllers which have > > > different ideas of how to do soft sector sparing _at the controller > > > level_ rather than at the drive level. > > > > We have dropped support for ESDI controllers long since. :-) > > > > Seriously, all the disks we are supporting these days do bad block > > replacement at the drive level. > > Adaptec 1742 is supported, though it took a long enough time to > find its way into CAM. Same for the NCR 810. Neither of which do controller-level sparing. > For certain applications, also, you _want_ to turn off the automatic > bad sector sparing: it's incompatible with spindle sync, for example, > where you want to spare all drives or none, so that the spindles don't > desyncronize on a sparing hit for one drive, but not another. Spindle sync is an anachronism these days; asynchronous behaviour (write-behind in particular) is all the rage. You'd be hard-pressed to find drives that even support it anymore. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 10: 2:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id D9E9437B416 for ; Mon, 10 Dec 2001 10:02:25 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id fBAI2O850051 for current@freebsd.org; Mon, 10 Dec 2001 10:02:24 -0800 (PST) (envelope-from david) Date: Mon, 10 Dec 2001 10:02:24 -0800 (PST) From: David Wolfskill Message-Id: <200112101802.fBAI2O850051@bunrab.catwhisker.org> To: current@freebsd.org Subject: panic: blockable sleep lock (sleep mutex) with today's -CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I managed to get a panic on my (SMP) "build machine" on the first reboot after building -CURRENT with sources updated from cvsup13 at around 4:22 AM US/Pacific (8 hrs. west of GMT/UTC) today. (My laptop is still working on the build from the same sources; it is nearing the end of the "buildworld" phase, and then will be going on to making a new kernel. Scratch that; it's building the kernel now.) Here's the part of what I see so far that appears relevant. This is a build machine (as noted); it is underutilized otherwise, so I can let it sit there in the debugger & try things out, if that would be of interest; I can also try patches & whatnot -- it has a local copy of the FreeBSD CVS repository, so that's no problem... as long as it's responsive at least to its serial console. (It's at home; I'm at work.) I can also make more detailed information available on a Web site, if folks would prefer that to spamming -current. OK, as promised: Mon Dec 10 05:41:01 PST 2001 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: boot() called on cpu#1 Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 66 66 60 60 53 53 45 45 37 37 29 29 23 23 17 17 9 9 2 2 done Uptime: 3h46m45s Rebooting... cpu_reset called on cpu#1 cpu_reset: Stopping other CPUs cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 1.0 (root@freebeast.catwhisker.org, Mon Dec 10 07:10:55 PST 2001) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x1ff450 data=0x2b58c+0x627e8 syms=[0x4+0x33960+0x4+0x3f0a4] / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x34dfc data=0x1090+0xbf8 syms=[0x4+0x4c90+0x4+0x64c9] ... Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #4: Mon Dec 10 07:38:06 PST 2001 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/FREEBEAST Preloaded elf kernel "/boot/kernel/kernel" at 0xc0445000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04450a8. Calibrating clock(s) ... TSC clock: 876477435 Hz, i8254 clock: 1193298 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium III/Pentium III Xeon/Celeron (876.40-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 536805376 (524224K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x0046f000 - 0x1ffe7fff, 532123648 bytes (129913 pages) avail memory = 518000640 (505860K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 SMP: CPU0 apic_initialize(): lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec00000 bios32: Found BIOS32 Service Directory header at 0xc00faf20 bios32: Entry = 0xfb390 (c00fb390) Rev = 0 Len = 1 ... ad0: success setting UDMA5 on VIA chip Creating DISK ad0 ad0: ATA-5 disk at ata0-master ad0: 39203MB (80288480 sectors), 79651 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 ad0: piomode=4 dmamode=2 udmamode=5 cblid=1 ... Mounting root from ufs:/dev/ad0s4a ad0s1: type 0xa5, start 63, end = 4192964, size 4192902 : OK ad0s2: type 0xa5, start 4192965, end = 8385929, size 4192965 : OK ad0s3: type 0xa5, start 8385930, end = 12578894, size 4192965 : OK ad0s4: type 0xa5, start 12578895, end = 80276804, size 67697910 : OK yMP: AP CPUs t#a1r tL_aiunnicth:e dt!r _SnMgP :/ sCbPiUn1/ ianpiitc initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff lock order reversal 1st 0xc038aa80 sched lock @ /usr/src/sys/kern/kern_intr.c:544 2nd 0xc0375120 sio @ /usr/src/sys/dev/sio/sio.c:3100 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 01000000 fault virtual address = 0x486 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0365250 stack pointer = 0x10:0xff805f74 frame pointer = 0x10:0xc01b7d5f code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 10 (idle: cpu1) kernel: type 12 trap, code=0 timeout stopping cpus Stopped at 0xc0365250: addb %dl,0(%ecx) db> trace w_locklistdata(1c03408,68000000,4f5,2d77a068,68006ac0) at 0xc0365250 db> show witness Sleep locks: 0 Giant -- last acquired @ /usr/src/sys/kern/kern_intr.c:531 1 taskqueue list -- last acquired @ /usr/src/sys/kern/subr_taskqueue.c:85 1 mbuf PCPU list lock -- last acquired @ /usr/src/sys/kern/subr_mbuf.c:784 1 eventhandler -- last acquired @ /usr/src/sys/kern/subr_eventhandler.c:78 3 lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:505 3 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:153 3 zone -- last acquired @ /usr/src/sys/vm/vm_zone.c:475 1 sf_bufs list lock -- last acquired @ /usr/src/sys/kern/uipc_syscalls.c:1530 3 lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:505 3 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:153 3 zone -- last acquired @ /usr/src/sys/vm/vm_zone.c:475 1 rl0 -- last acquired @ /usr/src/sys/pci/if_rl.c:842 2 rman -- last acquired @ /usr/src/sys/kern/subr_rman.c:129 3 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:153 2 bpf global lock -- last acquired @ /usr/src/sys/net/bpf.c:1223 2 ithread -- last acquired @ /usr/src/sys/kern/kern_intr.c:269 3 lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:505 3 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:153 3 zone -- last acquired @ /usr/src/sys/vm/vm_zone.c:475 3 fork list -- last acquired @ /usr/src/sys/kern/kern_fork.c:646 3 proctree -- last acquired @ /usr/src/sys/kern/kern_fork.c:573 4 allproc -- last acquired @ /usr/src/sys/vm/vm_glue.c:405 5 process lock -- last acquired @ /usr/src/sys/kern/kern_exec.c:129 6 ucred -- last acquired @ /usr/src/sys/kern/kern_prot.c:1587 6 uidinfo hash -- last acquired @ /usr/src/sys/kern/kern_resource.c:844 7 uidinfo struct -- last acquired @ /usr/src/sys/kern/kern_resource.c:955 1 zone subsystem -- last acquired @ /usr/src/sys/vm/vm_zone.c:179 1 mntvnode -- last acquired @ /usr/src/sys/kern/vfs_subr.c:752 1 pseudofs -- last acquired @ /usr/src/sys/fs/pseudofs/pseudofs_fileno.c:87 1 spechash -- last acquired @ /usr/src/sys/kern/vfs_subr.c:2157 1 rman head -- last acquired @ /usr/src/sys/kern/subr_rman.c:107 1 taskqueue -- last acquired @ /usr/src/sys/kern/subr_taskqueue.c:190 1 random reseed -- last acquired @ /usr/src/sys/dev/random/yarrow.c:266 1 ifsvgt -- last acquired @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1213 1 vnode interlock -- last acquired @ /usr/src/sys/kern/vfs_subr.c:1616 2 vnode_free_list -- last acquired @ /usr/src/sys/kern/vfs_subr.c:601 1 ufs ihash -- last acquired @ /usr/src/sys/ufs/ufs/ufs_ihash.c:134 1 pbuf mutex -- last acquired @ /usr/src/sys/vm/swap_pager.c:316 1 buftime lock -- last acquired @ /usr/src/sys/sys/buf.h:276 1 mntid -- last acquired @ /usr/src/sys/kern/vfs_subr.c:434 2 mountlist -- last acquired @ /usr/src/sys/kern/vfs_syscalls.c:413 Spin locks: 0 ap boot -- last acquired @ /usr/src/sys/i386/i386/mp_machdep.c:2249 1 com -- last acquired @ order list:0 2 sio -- last acquired @ /usr/src/sys/dev/sio/sio.c:3100 3 cy -- last acquired @ order list:0 4 ng_node -- last acquired @ order list:0 5 ng_worklist -- last acquired @ order list:0 6 ithread table lock -- last acquired @ /usr/src/sys/i386/isa/intr_machdep.c:613 7 sched lock -- last acquired @ /usr/src/sys/kern/kern_intr.c:544 8 callout -- last acquired @ /usr/src/sys/kern/kern_timeout.c:256 9 imen -- last acquired @ /usr/src/sys/i386/i386/mpapic.c:262 10 smp rendezvous -- last acquired @ order list:0 11 clk -- last acquired @ /usr/src/sys/i386/isa/clock.c:412 Locks which were never acquired: vnode pollinfo arp_inq ip6_inq ip_inq pseudofs_vncache pseudofs_fileno ppp ppp_rawq ppp_fastq ppp_inq lo msdosfs dehash cd9660_ihash lp bpf interface lock rl ACPI global lock mbuf subsystem general lists lock phys_pager list dev_pager list dev_pager create swap_pager list vm object_list vm buckets hash mutexes vm pageq mutex vm86 lock db> show lockedvnodes Locked vnodes panic: blockable sleep lock (sleep mutex) mountlist @ /usr/src/sys/kern/vfs_subr.c:2241 cpuid = 1; lapic.id = 01000000 Debugger("panic") Stopped at 0xc0365250: loopne 0xc03652a3 db> And there it sits, for now. Note that the reboot was clean. I was about to look in the archives for cvs-all, but I'm not making much progress there. Thoughts? Thanks, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 10:13:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B959737B417; Mon, 10 Dec 2001 10:13:20 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBAIDKo47460; Mon, 10 Dec 2001 10:13:20 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 10:13:20 -0800 (PST) From: Matthew Dillon Message-Id: <200112101813.fBAIDKo47460@apollo.backplane.com> To: Mike Smith Cc: Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c References: <200112101754.fBAHsRV01202@mass.dis.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Spindle sync is an anachronism these days; asynchronous behaviour :(write-behind in particular) is all the rage. You'd be hard-pressed to :find drives that even support it anymore. Woa! Say what? I think you are totally incorrect here Mike. Spindle sync is not an anachronism. You can't get good RAID{0,2,3,4,5} performance without it - for reading OR writing. It doesn't matter so much for RAID{1,10}, but it matters a whole lot for something like RAID-5 where the difference between a spindle-synced read or write and a non-spindle-synched read or write can be upwards of 35%. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 10:23: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id EBF9537B41B; Mon, 10 Dec 2001 10:22:55 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id fBAIMpj65394; Mon, 10 Dec 2001 19:22:51 +0100 (CET) (envelope-from wkb) Date: Mon, 10 Dec 2001 19:22:51 +0100 From: Wilko Bulte To: Matthew Dillon Cc: Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011210192251.A65380@freebie.xs4all.nl> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112101813.fBAIDKo47460@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Dec 10, 2001 at 10:13:20AM -0800 X-OS: FreeBSD 4.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 10, 2001 at 10:13:20AM -0800, Matthew Dillon wrote: > :Spindle sync is an anachronism these days; asynchronous behaviour > :(write-behind in particular) is all the rage. You'd be hard-pressed to > :find drives that even support it anymore. > > Woa! Say what? I think you are totally incorrect here Mike. > Spindle sync is not an anachronism. You can't get good RAID{0,2,3,4,5} For RAID3 that is true. For the other ones... > performance without it - for reading OR writing. It doesn't matter > so much for RAID{1,10}, but it matters a whole lot for something like > RAID-5 where the difference between a spindle-synced read or write > and a non-spindle-synched read or write can be upwards of 35%. If you have RAID5 with I/O sizes that result in full-stripe operations. -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 10:30:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A064537B421; Mon, 10 Dec 2001 10:30:11 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBAIU4w47648; Mon, 10 Dec 2001 10:30:04 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 10:30:04 -0800 (PST) From: Matthew Dillon Message-Id: <200112101830.fBAIU4w47648@apollo.backplane.com> To: Wilko Bulte Cc: Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> performance without it - for reading OR writing. It doesn't matter :> so much for RAID{1,10}, but it matters a whole lot for something like :> RAID-5 where the difference between a spindle-synced read or write :> and a non-spindle-synched read or write can be upwards of 35%. : :If you have RAID5 with I/O sizes that result in full-stripe operations. Well, 'more then one disk' operations anyway, for random-I/O. Caching takes care of sequential I/O reasonably well but random-I/O goes down the drain for writes if you aren't spindle synced, no matter what the stripe size, and will go down the drain for reads if you cross a stripe - something that is quite common I think. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 10:49:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F340A37B419; Mon, 10 Dec 2001 10:49:34 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBAInSO47847; Mon, 10 Dec 2001 10:49:28 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 10:49:28 -0800 (PST) From: Matthew Dillon Message-Id: <200112101849.fBAInSO47847@apollo.backplane.com> To: Wilko Bulte Cc: Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :For RAID3 that is true. For the other ones... : :> performance without it - for reading OR writing. It doesn't matter :> so much for RAID{1,10}, but it matters a whole lot for something like :> RAID-5 where the difference between a spindle-synced read or write :> and a non-spindle-synched read or write can be upwards of 35%. : :If you have RAID5 with I/O sizes that result in full-stripe operations. : :-- :| / o / /_ _ email: wilko@FreeBSD.org :|/|/ / / /( (_) Bulte Arnhem, The Netherlands Well, for reads a non-stripe-crossing op would still work reasonably well. But for writes less then full-stripe operations without spindle sync are going to be terrible due to the read-before-write requirement (to calculate parity). The disk cache is useless in that case. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 10:56:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id A4A9037B417 for ; Mon, 10 Dec 2001 10:56:09 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBAJ1hV01951; Mon, 10 Dec 2001 11:01:44 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112101901.fBAJ1hV01951@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c In-reply-to: Your message of "Mon, 10 Dec 2001 10:49:28 PST." <200112101849.fBAInSO47847@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Dec 2001 11:01:43 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Well, for reads a non-stripe-crossing op would still work reasonably > well. But for writes less then full-stripe operations without > spindle sync are going to be terrible due to the read-before-write > requirement (to calculate parity). The disk cache is useless in that > case. You obviously weren't reading the previous thread on RAID5 checksum calculation, I see. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 10:57: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 53DCF37B41C for ; Mon, 10 Dec 2001 10:56:58 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id fBAIuwo50278 for current@FreeBSD.ORG; Mon, 10 Dec 2001 10:56:58 -0800 (PST) (envelope-from david) Date: Mon, 10 Dec 2001 10:56:58 -0800 (PST) From: David Wolfskill Message-Id: <200112101856.fBAIuwo50278@bunrab.catwhisker.org> To: current@FreeBSD.ORG Subject: Re: panic: blockable sleep lock (sleep mutex) with today's -CURRENT In-Reply-To: <200112101802.fBAI2O850051@bunrab.catwhisker.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Date: Mon, 10 Dec 2001 10:02:24 -0800 (PST) >From: David Wolfskill >I managed to get a panic on my (SMP) "build machine" on the first reboot >after building -CURRENT.... Well, the laptop finshed building & booting from (nearly) the same sources, so I suspect either hardware or an SMP issue -- more likely the former. (Machine didn't come out of the panic; said it was rebooting, but then got: Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot <-- Rebooting... cpu_reset called on cpu#1 cpu_reset: Stopping other CPUs timeout stopping cpus cpu_reset: Restarting BSP cpu_reset: Failed to restart BSP and it remains rather catatonic at this point. Sorry for the noise, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 10:58:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1F29537B41B; Mon, 10 Dec 2001 10:58:44 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBAIwiX48022; Mon, 10 Dec 2001 10:58:44 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 10:58:44 -0800 (PST) From: Matthew Dillon Message-Id: <200112101858.fBAIwiX48022@apollo.backplane.com> To: Mike Smith Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c References: <200112101901.fBAJ1hV01951@mass.dis.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> Well, for reads a non-stripe-crossing op would still work reasonably :> well. But for writes less then full-stripe operations without :> spindle sync are going to be terrible due to the read-before-write :> requirement (to calculate parity). The disk cache is useless in that :> case. : :You obviously weren't reading the previous thread on RAID5 checksum :calculation, I see. 8) I don't see a thread on raid-5 checksuming. What was the subject? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 13:39:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 79DC137B42F for ; Mon, 10 Dec 2001 13:38:44 -0800 (PST) Received: (qmail 8980 invoked from network); 10 Dec 2001 21:38:42 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 21:38:42 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011209102129.F97235@uriah.heep.sax.de> Date: Mon, 10 Dec 2001 13:38:39 -0800 (PST) From: John Baldwin To: Joerg Wunsch Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 09-Dec-01 Joerg Wunsch wrote: > As Peter Wemm wrote: > >> There shouldn't *be* bootblocks on non-boot disks. >> >> dd if=/dev/zero of=/dev/da$n count=1 >> >> Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". > > All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) Well, since they are a de facto part of the PC architecture they are also good so that you don't break BIOS's. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 14: 2: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from web21102.mail.yahoo.com (web21102.mail.yahoo.com [216.136.227.104]) by hub.freebsd.org (Postfix) with SMTP id D1CAD37B417 for ; Mon, 10 Dec 2001 14:01:53 -0800 (PST) Message-ID: <20011210220153.50612.qmail@web21102.mail.yahoo.com> Received: from [62.254.0.5] by web21102.mail.yahoo.com via HTTP; Mon, 10 Dec 2001 14:01:53 PST Date: Mon, 10 Dec 2001 14:01:53 -0800 (PST) From: Hiten Pandya Subject: [SUGGESTION] - JFS for FreeBSD To: current@FreeBSD.org Cc: hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi all, this is a wild idea...suggestion... i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... as for JFS, it is developed by IBM for Linux and is licensed under GPL, so we could put this into src/gnu/ It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... ===== -Hiten, Thank You, Yours Sincerely, Hiten Pandya, __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 14: 4: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 986A037B405; Mon, 10 Dec 2001 14:03:55 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 45898485; Mon, 10 Dec 2001 22:03:46 +0000 (GMT) Date: Mon, 10 Dec 2001 22:03:46 +0000 From: Josef Karthauser To: Hiten Pandya Cc: current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <20011210220346.F28634@tao.org.uk> Mail-Followup-To: Josef Karthauser , Hiten Pandya , current@FreeBSD.org, hackers@FreeBSD.org References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="dWYAkE0V1FpFQHQ3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011210220153.50612.qmail@web21102.mail.yahoo.com>; from hitmaster2k@yahoo.com on Mon, Dec 10, 2001 at 02:01:53PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --dWYAkE0V1FpFQHQ3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 10, 2001 at 02:01:53PM -0800, Hiten Pandya wrote: > hi all, >=20 > this is a wild idea...suggestion... >=20 > i wanted to ask if there were any _plans_ to port > JFS (Journaled File System) to FreeBSD... Hi Hiten, Search the mail list archives (from www.freebsd.org) for JFS and XFS. You'll see that there have been many discussions about this over the last few years. Joe --dWYAkE0V1FpFQHQ3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwVMUEACgkQXVIcjOaxUBYv/QCfdKzLh5HAqOvc8Y1sSUr3aM7L TXQAoIe29fKvZqPL+kHz181B3MaupJkJ =dfZG -----END PGP SIGNATURE----- --dWYAkE0V1FpFQHQ3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 14:14: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from pn109.warszawa.cvx.ppp.tpnet.pl (pn109.warszawa.cvx.ppp.tpnet.pl [213.76.109.109]) by hub.freebsd.org (Postfix) with SMTP id ACEB137B405 for ; Mon, 10 Dec 2001 14:13:35 -0800 (PST) To: freebsd-current@freebsd.org From: Jackie 'business-first' Cook Subject: Motion for removal of xargs(1) from base system Message-Id: <20011210221335.ACEB137B405@hub.freebsd.org> Date: Mon, 10 Dec 2001 14:13:35 -0800 (PST) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There are days when people get tired with the lagacy code in the system - when things of the past just have to go. Recently I got sick and tired with one of those things. The command is, as you could have guessed from the subject, xags(1) aka /usr/bin/xargs. It is buggy and cluttered piece of code. Faulty and hard to use command. It's idiosyncratic syntax makes people dizzy everytime they use/or just try to use it. Moreover short research I've conducted showed, that excessive use of xargs(1) can cause nausea, vomiting and migrene. The very presence of xargs(1) in the system, caused in some cases severe brain damage. Therefore I propose removal of xargs(1) from base system and moving it to ports tree. The new port in sysutils/xargs should be marked as BROKEN just after creation - that's obvious. Short procedure for removing xargs(1) from your life: Version #1 - for experienced sysadmins (local solution): rm -f /usr/bin/xargs (the -f is for those lucky ones who have ditched xargs(1) long ago, but just want to make sure it will vanish for good) Version #2 - for enterprise (ie. business) users, who are searching for their way in life (overwhelming majority) (local solution, still): find / -print0 | grep -v xargs | xargs -0 rm -f {} \; (the -v switch for grep adds some *verbosity* during operation) Version #3 - for commiters only (global solution, all FreeBSD users are urged to cvs up/cvsup right after the commit, but one of presented local solutions is still necessary to get rid of the venerous xargs(1) from your system): freefall% rm -rf $CVSROOT/src/usr.bin/xargs (to trash it altogether with version history, and make sure it will never come back) As a replacement for the 'functionality' present in xargs(1), I propose implementing arbitrary length argument list passing right in the operating system. Yours sincerly, Jackie 'business-first' Cook. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 14:20:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id F03EA37B417 for ; Mon, 10 Dec 2001 14:20:03 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210222003.PVDV5859.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Mon, 10 Dec 2001 22:20:03 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBAMK3s35882 for ; Mon, 10 Dec 2001 14:20:03 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 4391539F0; Mon, 10 Dec 2001 14:20:03 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Ian Dowse Cc: Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c In-Reply-To: <200112101150.aa33241@salmon.maths.tcd.ie> Date: Mon, 10 Dec 2001 14:20:03 -0800 From: Peter Wemm Message-Id: <20011210222003.4391539F0@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ian Dowse wrote: > In message <20011210004350.6703C3810@overcee.netplex.com.au>, Peter Wemm writ es > : > >The problem is, that you **are** using fdisk tables, you have no choice. > >DD mode included a *broken* fdisk table that specified an illegal geometry. > ... > >This is why it is called dangerous. > > BTW, I presume you are aware of the way sysinstall creates DD MBRs; > it does not use the 50000 sector slice 4 method, but sets up slice > 1 to cover the entire disk including the MBR, with c/h/s entries > corresponding to the real start and end of the disk, e.g: > > cylinders=3544 heads=191 sectors/track=53 (10123 blks/cyl) > ... > The data for partition 1 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 0, size 35885168 (17522 Meg), flag 80 (active) > beg: cyl 0/ head 0/ sector 1; > end: cyl 1023/ head 190/ sector 53 > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > > > Otherwise the disk layout is the same as disklabel's DD. I suspect > that this approach is much less illegal than disklabel's MBRs > although I do remember seeing a HP PC that disliked it. I wonder > if a reasonable compromise is to make disklabel use this system for > DD disks instead of the bogus 50000 sector slice? Obviously, it > should also somehow not install a partition table unless boot1 is > being used as the MBR, and the fdisk -I method should be preferred. Yes, that is much safer, however there are certain bioses that have interesting quirks that the MBR has to work around. The problem when overlapping mbr and boot1 into the same block is that we no longer have the space to do that. boot1.s has got *3* bytes free. For example, we dont have space to fix the case where the drive number is passed through incorrectly to the mbr. Some older Intel boards have this problem (Phoenix derived bios). See boot0's setdrv option. Also (and I think this is more likely to be the problem you ran into) many newer PC's are looking at the partition tables for a suspend-to-disk partition or a FAT filesystem with a suspend-to-disk dump file. For better or worse, PC architecture dictates that boot disk partitions start and end on cylinder boundaries (except for the first one which starts on the second head in the first cylinder). When we break those rules, we have to be prepared for the consequences. However, there is light at the end of the tunnel. EFI GPT is pretty clean. It supports up to something like 16384 partitions and it has all the useful stuff we could possibly want including unique ID's, no CHS (pure 64 bit LBA), volume tags (you can name partitions etc), and so on. It is clean enough that we could almost get away with doing away with disklabel as well. "Coming soon to a PC near you." (http://developer.intel.com/technology/efi/index.htm) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 14:32: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 03BA137B416 for ; Mon, 10 Dec 2001 14:32:05 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 9EBCF81D01; Mon, 10 Dec 2001 16:32:04 -0600 (CST) Date: Mon, 10 Dec 2001 16:32:04 -0600 From: Alfred Perlstein To: Jackie 'business-first' Cook Cc: freebsd-current@freebsd.org Subject: Re: Motion for removal of xargs(1) from base system Message-ID: <20011210163204.M92148@elvis.mu.org> References: <20011210221335.ACEB137B405@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011210221335.ACEB137B405@hub.freebsd.org>; from jackie@businessman.pl on Mon, Dec 10, 2001 at 02:13:35PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Jackie 'business-first' Cook [011210 16:19] wrote: > > As a replacement for the 'functionality' present in xargs(1), I propose > implementing arbitrary length argument list passing right in the operating > system. Nice proposal, where's the diff? > Yours sincerly, Jackie 'business-first' Cook. > -- -Alfred 'patches-first' Perlstein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 14:34:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-d.strhg1.mi.home.com [24.13.43.207]) by hub.freebsd.org (Postfix) with ESMTP id 2D48C37B419 for ; Mon, 10 Dec 2001 14:34:34 -0800 (PST) Received: by turtle.looksharp.net (Postfix, from userid 1003) id 570CE3E23; Mon, 10 Dec 2001 17:35:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turtle.looksharp.net (Postfix) with ESMTP id 53F93BAA5; Mon, 10 Dec 2001 17:35:00 -0500 (EST) Date: Mon, 10 Dec 2001 17:35:00 -0500 (EST) From: "Brandon D. Valentine" To: Alfred Perlstein Cc: Jackie 'business-first' Cook , Subject: Re: Motion for removal of xargs(1) from base system In-Reply-To: <20011210163204.M92148@elvis.mu.org> Message-ID: <20011210173333.E33626-100000@turtle.looksharp.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Dec 2001, Alfred Perlstein wrote: >* Jackie 'business-first' Cook [011210 16:19] wrote: >> >> As a replacement for the 'functionality' present in xargs(1), I propose >> implementing arbitrary length argument list passing right in the operating >> system. > >Nice proposal, where's the diff? I'd like to preempt the ensuing bikeshed by voting for green. >> Yours sincerly, Jackie 'business-first' Cook. You don't by chance sell used cars, do you? Brandon D. Valentine -- "Iam mens praetrepidans avet vagari." - G. Valerius Catullus, Carmina, XLVI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 14:40:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 92F0237B41C for ; Mon, 10 Dec 2001 14:40:07 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210224007.QMBZ5859.rwcrmhc51.attbi.com@InterJet.elischer.org>; Mon, 10 Dec 2001 22:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA01027; Mon, 10 Dec 2001 14:24:41 -0800 (PST) Date: Mon, 10 Dec 2001 14:24:40 -0800 (PST) From: Julian Elischer To: "Jackie 'business-first' Cook" Cc: freebsd-current@freebsd.org Subject: Re: Motion for removal of xargs(1) from base system In-Reply-To: <20011210221335.ACEB137B405@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ummm, what are my scripts that use it going to use instead? it seems to work fine, and it's pretty much an expected base utility. Removing it is going to cause quite a bit of confusion. On Mon, 10 Dec 2001, Jackie 'business-first' Cook wrote: > There are days when people get tired with the lagacy code in the > system - when things of the past just have to go. Recently I got sick > and tired with one of those things. The command is, as you could have > guessed from the subject, xags(1) aka /usr/bin/xargs. It is buggy and > cluttered piece of code. Faulty and hard to use command. It's > idiosyncratic syntax makes people dizzy everytime they use/or just try > to use it. > > Moreover short research I've conducted showed, that excessive use of > xargs(1) can cause nausea, vomiting and migrene. The very presence of > xargs(1) in the system, caused in some cases severe brain damage. > Therefore I propose removal of xargs(1) from base system and moving it > to ports tree. The new port in sysutils/xargs should be marked as > BROKEN just after creation - that's obvious. > > Short procedure for removing xargs(1) from your life: > > Version #1 - for experienced sysadmins (local solution): > > rm -f /usr/bin/xargs (the -f is for those lucky ones who have ditched > xargs(1) long ago, but just want to make sure > it will vanish for good) > > Version #2 - for enterprise (ie. business) users, who are searching for their > way in life (overwhelming majority) (local solution, still): > > find / -print0 | grep -v xargs | xargs -0 rm -f {} \; > (the -v switch for grep adds some *verbosity* > during operation) > > Version #3 - for commiters only (global solution, all FreeBSD users are urged to > cvs up/cvsup right after the commit, but one of presented local > solutions is still necessary to get rid of the venerous xargs(1) > from your system): > > freefall% rm -rf $CVSROOT/src/usr.bin/xargs > (to trash it altogether with version history, > and make sure it will never come back) > > As a replacement for the 'functionality' present in xargs(1), I propose > implementing arbitrary length argument list passing right in the operating > system. that wouldn't do what I want to do with xargs. It may not be wonderful but it's expected.. If you wna to get ugliness out of the system, how about starting with Perl :-) > > Yours sincerly, Jackie 'business-first' Cook. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 14:56: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 4AA7D37B41E for ; Mon, 10 Dec 2001 14:56:01 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id B32C71C1E; Mon, 10 Dec 2001 23:55:36 +0100 (CET) Date: Mon, 10 Dec 2001 23:55:36 +0100 From: Emiel Kollof To: Julian Elischer Cc: Jackie 'business-first' Cook , freebsd-current@freebsd.org Subject: Re: Motion for removal of xargs(1) from base system Message-ID: <20011210225536.GA1810@laptop.hackerheaven.org> References: <20011210221335.ACEB137B405@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.org/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer (julian@elischer.org) wrote: > ummm, what are my scripts that use it going to use instead? > it seems to work fine, and it's pretty much an expected > base utility. Removing it is going to cause quite a bit of confusion. I have to concurr here. Who knows what's going to break when this is removed. It seems to have an established place on every UNIX workalike out there. I say keep it. If you don't like it, then don't use it. Cheers, Emiel (who hopes for not another flamewar. One at a time is enough :) -- "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 14:56:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from relay.gnf.org (relay.gnf.org [208.44.31.36]) by hub.freebsd.org (Postfix) with ESMTP id 6BCBA37B416 for ; Mon, 10 Dec 2001 14:56:17 -0800 (PST) Received: from mail.gnf.org (smtp.gnf.org [10.0.0.11]) by relay.gnf.org (8.11.6/8.11.6) with ESMTP id fBAMuAJ16134; Mon, 10 Dec 2001 14:56:10 -0800 Received: by mail.gnf.org (Postfix, from userid 888) id E2B5511E503; Mon, 10 Dec 2001 14:53:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id E0AC011A577; Mon, 10 Dec 2001 14:53:16 -0800 (PST) Date: Mon, 10 Dec 2001 14:53:16 -0800 (PST) From: Gordon Tetlow To: "Jackie 'business-first' Cook" Cc: Subject: Re: Motion for removal of xargs(1) from base system In-Reply-To: <20011210221335.ACEB137B405@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG If this isn't a troll, I don't know what is.... On Mon, 10 Dec 2001, Jackie 'business-first' Cook wrote: > There are days when people get tired with the lagacy code in the > system - when things of the past just have to go. Recently I got sick > and tired with one of those things. The command is, as you could have > guessed from the subject, xags(1) aka /usr/bin/xargs. It is buggy and > cluttered piece of code. Faulty and hard to use command. It's > idiosyncratic syntax makes people dizzy everytime they use/or just try > to use it. Well, in that case, find(1) needs to be pitched as well for it's "idiosyncratic syntax" as well. Besides xargs is part of the POSIX 1003.2 Standard. Since we are trying to be POSIX compliant, xargs should stay. If you think the code is ugly, please feel free to fix it. Patches are most welcome. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 15: 2:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id C21E437B41E for ; Mon, 10 Dec 2001 15:02:15 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id fBAN1sE66977; Tue, 11 Dec 2001 00:01:54 +0100 (CET) (envelope-from wkb) Date: Tue, 11 Dec 2001 00:01:54 +0100 From: Wilko Bulte To: Emiel Kollof Cc: Julian Elischer , "Jackie 'business-first' Cook" , freebsd-current@FreeBSD.ORG Subject: Re: Motion for removal of xargs(1) from base system Message-ID: <20011211000154.A66950@freebie.xs4all.nl> References: <20011210221335.ACEB137B405@hub.freebsd.org> <20011210225536.GA1810@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011210225536.GA1810@laptop.hackerheaven.org>; from coolvibe@hackerheaven.org on Mon, Dec 10, 2001 at 11:55:36PM +0100 X-OS: FreeBSD 4.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 10, 2001 at 11:55:36PM +0100, Emiel Kollof wrote: > * Julian Elischer (julian@elischer.org) wrote: > > ummm, what are my scripts that use it going to use instead? > > it seems to work fine, and it's pretty much an expected > > base utility. Removing it is going to cause quite a bit of confusion. > > I have to concurr here. Who knows what's going to break when this is > removed. It seems to have an established place on every UNIX workalike > out there. I say keep it. If you don't like it, then don't use it. > > Cheers, > Emiel (who hopes for not another flamewar. One at a time is enough :) Thanks to progress we can now have multi-threaded flamewars ;) Wilko [likes to keep xargs btw] -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 15: 3:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 757F837B405 for ; Mon, 10 Dec 2001 15:03:47 -0800 (PST) Received: (qmail 7022 invoked from network); 10 Dec 2001 23:03:46 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 23:03:46 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011210221335.ACEB137B405@hub.freebsd.org> Date: Mon, 10 Dec 2001 15:03:42 -0800 (PST) From: John Baldwin To: "Jackie 'business-first' Cook" Subject: RE: Motion for removal of xargs(1) from base system Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Dec-01 Jackie 'business-first' Cook wrote: > There are days when people get tired with the lagacy code in the system - > when > things of the past just have to go. Recently I got sick and tired with one of > those things. The command is, as you could have guessed from the subject, > xags(1) aka /usr/bin/xargs. It is buggy and cluttered piece of code. Faulty > and > hard to use command. It's idiosyncratic syntax makes people dizzy everytime > they > use/or just try to use it. Buggy? I haven't had problems with xargs(1). I think a more useful use of your time would be to actually describe the problems you have so they can be addressed. What Unix command doesn't have idiosyncratic syntax anyways? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 15:11:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A7DDE37B41F; Mon, 10 Dec 2001 15:11:17 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id fBANB3933575; Mon, 10 Dec 2001 18:11:04 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200112102311.fBANB3933575@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Brandon D. Valentine" Cc: Alfred Perlstein , "Jackie 'business-first' Cook" , freebsd-current@freebsd.org Subject: Re: Motion for removal of xargs(1) from base system In-Reply-To: Message from "Brandon D. Valentine" of "Mon, 10 Dec 2001 17:35:00 EST." <20011210173333.E33626-100000@turtle.looksharp.net> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Dec 2001 18:11:03 -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Brandon D. Valentine" wrote: > On Mon, 10 Dec 2001, Alfred Perlstein wrote: > > >* Jackie 'business-first' Cook [011210 16:19] wrote: > >> > >> As a replacement for the 'functionality' present in xargs(1), I propose > >> implementing arbitrary length argument list passing right in the operating > >> system. > > > >Nice proposal, where's the diff? > > I'd like to preempt the ensuing bikeshed by voting for green. I'd like to accept your nomination. People, I know you won't regret choosing the right person for the job! -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 15:14:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id E0DBE37B428 for ; Mon, 10 Dec 2001 15:14:14 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBANDeq44433; Mon, 10 Dec 2001 15:13:41 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: "Jackie 'business-first' Cook" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Motion for removal of xargs(1) from base system In-Reply-To: Message from "Jackie 'business-first' Cook" of "Mon, 10 Dec 2001 14:13:35 PST." <20011210221335.ACEB137B405@hub.freebsd.org> Date: Mon, 10 Dec 2001 15:13:40 -0800 Message-ID: <44429.1008026020@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG My, is it April 1st already? How quickly time flies! December feels like it was just yesterday! - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 15:18:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 37EA337B419 for ; Mon, 10 Dec 2001 15:18:12 -0800 (PST) Received: (qmail 25341 invoked from network); 10 Dec 2001 23:18:09 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 23:18:09 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200112102311.fBANB3933575@green.bikeshed.org> Date: Mon, 10 Dec 2001 15:17:59 -0800 (PST) From: John Baldwin To: "Brian F. Feldman" Subject: Re: Motion for removal of xargs(1) from base system Cc: freebsd-current@freebsd.org, Cc: freebsd-current@freebsd.org, "Jackie 'business-first' Cook" , Alfred Perlstein , "Brandon D. Valentine" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Dec-01 Brian F. Feldman wrote: > "Brandon D. Valentine" wrote: >> On Mon, 10 Dec 2001, Alfred Perlstein wrote: >> >> >* Jackie 'business-first' Cook [011210 16:19] >> >wrote: >> >> >> >> As a replacement for the 'functionality' present in xargs(1), I propose >> >> implementing arbitrary length argument list passing right in the >> >> operating >> >> system. >> > >> >Nice proposal, where's the diff? >> >> I'd like to preempt the ensuing bikeshed by voting for green. > > I'd like to accept your nomination. People, I know you won't regret > choosing the right person for the job! So I can cut you up into little places, grind those up in a blender, mix with the appropriate substances and use the result to paint bikesheds? Hmmm.. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 15:23: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from hal-4.inet.it (hal-4.inet.it [213.92.5.23]) by hub.freebsd.org (Postfix) with ESMTP id B1A0637B417 for ; Mon, 10 Dec 2001 15:22:53 -0800 (PST) Received: (from root@localhost) by hal-4.inet.it (8.11.1/8.11.1) id fBANMqq252520 for ; Tue, 11 Dec 2001 00:22:52 +0100 Received: from acampi.inet.it(213.92.1.165) by hal-4.inet.it via I-SMTP-4.0.3-100 id s-213.92.1.165-DWfA9p; Tue Dec 11 00:22:52 2001 Received: from webcom.it (unknown [213.140.20.183]) by acampi.inet.it (Postfix) with SMTP id 5936115533 for ; Tue, 11 Dec 2001 00:22:51 +0100 (CET) Received: (qmail 3051 invoked by uid 1000); 10 Dec 2001 23:22:50 -0000 Date: Tue, 11 Dec 2001 00:22:50 +0100 From: Andrea Campi To: "Jackie 'business-first' Cook" Cc: freebsd-current@freebsd.org Subject: Re: Motion for removal of xargs(1) from base system Message-ID: <20011210232250.GA301@webcom.it> References: <20011210221335.ACEB137B405@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011210221335.ACEB137B405@hub.freebsd.org> User-Agent: Mutt/1.3.24i X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Either this is a troll, or it's an attempt at the very first layer 8 (between chair and keyboard) exploit: > Version #2 - for enterprise (ie. business) users, who are searching for their > way in life (overwhelming majority) (local solution, still): > > find / -print0 | grep -v xargs | xargs -0 rm -f {} \; > (the -v switch for grep adds some *verbosity* > during operation) This doesn't quite do what he says; let's hope nobody tried to run it AND let it run to its unpleasant end: passing the paths to all the files on your system down the pipes on a single line, for rm to delete... Too bad the machine would slow down to a crawl... nice try anyway ;-) Andrea [luckily the rm wouldn't work for at least a reason which is left as an exercise to the reader] -- Intel: where Quality is job number 0.9998782345! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 15:31: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 88C6737B417 for ; Mon, 10 Dec 2001 15:31:05 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id 3CAF21C1E; Tue, 11 Dec 2001 00:30:47 +0100 (CET) Date: Tue, 11 Dec 2001 00:30:46 +0100 From: Emiel Kollof To: Jordan Hubbard Cc: Jackie 'business-first' Cook , freebsd-current@FreeBSD.ORG Subject: Re: Motion for removal of xargs(1) from base system Message-ID: <20011210233046.GB1810@laptop.hackerheaven.org> References: <20011210221335.ACEB137B405@hub.freebsd.org> <44429.1008026020@winston.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44429.1008026020@winston.freebsd.org> User-Agent: Mutt/1.3.24i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.org/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Jordan Hubbard (jkh@winston.freebsd.org) wrote: > My, is it April 1st already? How quickly time flies! December feels > like it was just yesterday! You can say that again... I missed my birthday and the new-years party too. I'm such a geek... :-) Cheers, Emiel -- No man is an island, but some of us are long peninsulas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 16:25:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 0D32437B416 for ; Mon, 10 Dec 2001 16:25:25 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id fBB0PLj74164; Tue, 11 Dec 2001 00:25:21 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id fBB0LrU43770; Tue, 11 Dec 2001 00:21:53 GMT (envelope-from mark@grondar.za) Message-Id: <200112110021.fBB0LrU43770@grimreaper.grondar.org> To: Peter Wemm Cc: current@FreeBSD.ORG Subject: Re: *HEADS UP!* This means you! References: <20011210012008.8E57C3810@overcee.netplex.com.au> In-Reply-To: <20011210012008.8E57C3810@overcee.netplex.com.au> ; from Peter Wemm "Sun, 09 Dec 2001 17:20:08 PST." Date: Tue, 11 Dec 2001 00:21:53 +0000 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I for one will miss it. I used libexec/telnetd extensively during ia64 > bootstrap (and still use it) before we had the crypto stuff going. This > was all built by hand, 'make world' still isn't an option there. I also > use usr.bin/telnet on other systems where SRA is constantly getting in > my face and annoying the !^@#%!@^#!# out of me. All that will happen, is that the "usual" sources will be gone, and a .PATH: will point to effectively the same code (with some crypto in it, wrapped in #ifdefs that won't apply, like ENCRYPTION and AUTHENTICATION). The code this actually compiled will not change _at_all_. There will be no SRA unless you install secure/ telnet. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 16:26:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 8434537B417; Mon, 10 Dec 2001 16:26:19 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 2D204786E6; Tue, 11 Dec 2001 10:56:17 +1030 (CST) Date: Tue, 11 Dec 2001 10:56:17 +1030 From: Greg Lehey To: Hiten Pandya , Matthew Emmerton , Anthony Schneider Cc: current@FreeBSD.org, hackers@FreeBSD.org, Alfred Perlstein Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <20011211105617.K63585@monorchid.lemis.com> References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <002601c181cb$8c6a5e90$1200a8c0@gsicomp.on.ca> <20011210174711.A3208@mail.slc.edu> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <002601c181cb$8c6a5e90$1200a8c0@gsicomp.on.ca> <20011210220153.50612.qmail@web21102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011210174711.A3208@mail.slc.edu> <002601c181cb$8c6a5e90$1200a8c0@gsicomp.on.ca> <20011210220153.50612.qmail@web21102.mail.yahoo.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Format recovered--see http://www.lemis.com/email/email-format.html] Long-short syndrome in first message. On Monday, 10 December 2001 at 14:01:53 -0800, Hiten Pandya wrote: > hi all, > > this is a wild idea...suggestion... > > i wanted to ask if there were any _plans_ to port > JFS (Journaled File System) to FreeBSD... > > as for JFS, it is developed by IBM for Linux and is licensed under > GPL, so we could put this into src/gnu/ Well, JFS was developed by IBM for AIX. If you look at the header files, it is clearly derived from UFS. They later developed a completely new file system, JFS2, for OS/2, and later ported this version to Linux. It's also available for AIX, but the standard AIX file system is still the old JFS1. > It is used on IBM MainFrames and Enterprise servers for high > performance and maximum throughput... I don't think the zSeries (System/390) runs JFS. As I said above, the RS/6000 uses a different JFS file system. On Monday, 10 December 2001 at 17:39:35 -0500, Matthew Emmerton wrote: >> * Hiten Pandya [011210 16:02] wrote: >>> hi all, >>> >>> this is a wild idea...suggestion... >>> >>> i wanted to ask if there were any _plans_ to port >>> JFS (Journaled File System) to FreeBSD... >>> >>> as for JFS, it is developed by IBM for Linux and >>> is licensed under GPL, so we could put this into >>> src/gnu/ >>> >>> It is used on IBM MainFrames and Enterprise servers >>> for >>> high performance and maximum throughput... >> >> I'm glad you took the time to read the marketting literature. >> >> The problem is that porting it is going to be a bit more complicated >> than just dumping it into src/gnu. >> >> Feel free to take a shot at porting it though, let us know >> when you're done. > > I'm gainfully employed by IBM (although not for FreeBSD pursuits), > and have had this on my TODO list for a while. Well, I'm gainfully employed by IBM, both for FreeBSD and JFS. I've thought (and spoken) about this from time to time. It would be a lot of work. > The licence issue is a real sticky point, especially since the GPL > and BSD licences are like oil and water. Because of the GPL > licence, JFS support can never become part of the GENERIC kernel, > and any related support tools will have to exist as separate > binaries (newfs.jfs, fsck.jfs), as is currently done with the EXT2FS > filesystem. As others have pointed out, this is a detail. The real question is: will JFS2 buy anything? The only real way to find out is to try it. On Monday, 10 December 2001 at 17:47:11 -0500, Anthony Schneider wrote: > I'm no expert on journaled filesystems, but isn't the freebsd softupdates > option similar? No, at least not from a technical standpoint. From a user standpoint, they both try to make things faster and more reliable, but they do it in very different ways. > perhaps there could be an upgrade to offer > options SOFTERUPDATES > as an equal-but-different alternative to jfs? And what would that do? Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 16:28:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id B4AB737B405; Mon, 10 Dec 2001 16:28:16 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 16F3C786E3; Tue, 11 Dec 2001 10:58:15 +1030 (CST) Date: Tue, 11 Dec 2001 10:58:15 +1030 From: Greg Lehey To: Hiten Pandya , Matthew Emmerton , Anthony Schneider Cc: current@FreeBSD.org, hackers@FreeBSD.org, Alfred Perlstein Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <20011211105815.L63585@monorchid.lemis.com> References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <002601c181cb$8c6a5e90$1200a8c0@gsicomp.on.ca> <20011210174711.A3208@mail.slc.edu> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <002601c181cb$8c6a5e90$1200a8c0@gsicomp.on.ca> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011211105617.K63585@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011211105617.K63585@monorchid.lemis.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 11 December 2001 at 10:56:17 +1030, Greg Lehey wrote: > On Monday, 10 December 2001 at 17:39:35 -0500, Matthew Emmerton wrote: >>> * Hiten Pandya [011210 16:02] wrote: >>>> hi all, >>>> >>>> this is a wild idea...suggestion... >>>> >>>> i wanted to ask if there were any _plans_ to port >>>> JFS (Journaled File System) to FreeBSD... >>>> >>>> as for JFS, it is developed by IBM for Linux and >>>> is licensed under GPL, so we could put this into >>>> src/gnu/ >>>> >>>> It is used on IBM MainFrames and Enterprise servers >>>> for >>>> high performance and maximum throughput... >>> >>> I'm glad you took the time to read the marketting literature. >>> >>> The problem is that porting it is going to be a bit more complicated >>> than just dumping it into src/gnu. >>> >>> Feel free to take a shot at porting it though, let us know >>> when you're done. >> >> I'm gainfully employed by IBM (although not for FreeBSD pursuits), >> and have had this on my TODO list for a while. > > Well, I'm gainfully employed by IBM, both for FreeBSD and JFS. I've > thought (and spoken) about this from time to time. It would be a lot > of work. BTW, if anybody wants to do it anyway, let me know. I'm in a position to help with information, though possibly not with coding. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 16:35:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-d.strhg1.mi.home.com [24.13.43.207]) by hub.freebsd.org (Postfix) with ESMTP id 28F0937B416; Mon, 10 Dec 2001 16:35:35 -0800 (PST) Received: by turtle.looksharp.net (Postfix, from userid 1003) id 93CA23EB7; Mon, 10 Dec 2001 19:36:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turtle.looksharp.net (Postfix) with ESMTP id 85FAFBAA5; Mon, 10 Dec 2001 19:36:01 -0500 (EST) Date: Mon, 10 Dec 2001 19:36:01 -0500 (EST) From: "Brandon D. Valentine" To: Greg Lehey Cc: Hiten Pandya , Matthew Emmerton , Anthony Schneider , , , Alfred Perlstein Subject: Re: [SUGGESTION] - JFS for FreeBSD In-Reply-To: <20011211105617.K63585@monorchid.lemis.com> Message-ID: <20011210192952.C34440-100000@turtle.looksharp.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Dec 2001, Greg Lehey wrote: >On Monday, 10 December 2001 at 17:47:11 -0500, Anthony Schneider wrote: >> perhaps there could be an upgrade to offer >> options SOFTERUPDATES >> as an equal-but-different alternative to jfs? > >And what would that do? SOFTERUPDATES includes a switch to diffused gallery lighting and enhanced mood music. For the hacker in touch with his feminine side, it offers the ultimate in warm fuzzies. Brandon D. Valentine -- "Iam mens praetrepidans avet vagari." - G. Valerius Catullus, Carmina, XLVI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 16:36:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 6EAED37B41B; Mon, 10 Dec 2001 16:36:35 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id BF6BF786E7; Tue, 11 Dec 2001 11:06:33 +1030 (CST) Date: Tue, 11 Dec 2001 11:06:33 +1030 From: Greg Lehey To: Matthew Dillon Cc: Wilko Bulte , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011211110633.M63585@monorchid.lemis.com> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112101830.fBAIU4w47648@apollo.backplane.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > >>> performance without it - for reading OR writing. It doesn't matter >>> so much for RAID{1,10}, but it matters a whole lot for something like >>> RAID-5 where the difference between a spindle-synced read or write >>> and a non-spindle-synched read or write can be upwards of 35%. >> >> If you have RAID5 with I/O sizes that result in full-stripe operations. > > Well, 'more then one disk' operations anyway, for random-I/O. Caching > takes care of sequential I/O reasonably well but random-I/O goes down > the drain for writes if you aren't spindle synced, no matter what > the stripe size, Can you explain this? I don't see it. In FreeBSD, just about all I/O goes to buffer cache. > and will go down the drain for reads if you cross a stripe - > something that is quite common I think. I think this is what Mike was referring to when talking about parity calculation. In any case, going across a stripe boundary is not a good idea, though of course it can't be avoided. That's one of the arguments for large stripes. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 16:42:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id C318937B416 for ; Mon, 10 Dec 2001 16:42:14 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id E78AE786E7; Tue, 11 Dec 2001 11:12:03 +1030 (CST) Date: Tue, 11 Dec 2001 11:12:03 +1030 From: Greg Lehey To: Peter Wemm Cc: Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: "Dangerously Dedicated" (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011211111203.N63585@monorchid.lemis.com> References: <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011210005928.9538A3810@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011210005928.9538A3810@overcee.netplex.com.au> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 16:59:28 -0800, Peter Wemm wrote: > Joerg Wunsch wrote: >> Mike Smith wrote: >>> I'd love to never hear those invalid, unuseful, misleading opinions >>> from you again. >> >> ETOOMANYATTRIBUTES? :-) >> >> As long as you keep the feature of DD mode intact, i won't argue. If >> people feel like creating disks that aren't portable to another >> controller, they should do. I don't like this idea. > > We can just as easily have bootable-DD mode with a real MBR and have > freebsd start on sector #2 instead of overlapping boot1 and mbr. This would seem to be a reasonable alternative. > This costs only one sector instead of 64 sectors (a whopping 32K, > I'm sure that is going to break the bank on today's disks). Well, the real question is the space wasted at the end, which can be up to a megabyte. Still not going to kill you, but it's aesthetically displeasing. > I'd rather that we be specific about this. If somebody wants ad2e > or da2e then they should not be using *any* fdisk tables at all. > Ie: block 0 should be empty. The problem is that if you put > /boot/boot1 in there, then suddenly it looks like a fdisk disk and > we have to have ugly magic to detect it and prevent the fake table > from being used. I would prefer that the fdisk table come out of > /boot/boot1 so that we dont have to have it by default, and we use > fdisk to install the "DD magic table" if somebody wants to make it > bootable. So where would you put the bootstrap? In sector 2? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 16:46:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 3D64637B416 for ; Mon, 10 Dec 2001 16:46:32 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id ABCA2786E6; Tue, 11 Dec 2001 11:16:29 +1030 (CST) Date: Tue, 11 Dec 2001 11:16:29 +1030 From: Greg Lehey To: Joerg Wunsch Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011211111629.O63585@monorchid.lemis.com> References: <20011209102129.F97235@uriah.heep.sax.de> <20011210004350.6703C3810@overcee.netplex.com.au> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011210005928.9538A3810@overcee.netplex.com.au> <20011210091103.M97235@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011210091103.M97235@uriah.heep.sax.de> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday, 10 December 2001 at 9:11:03 +0100, Joerg Wunsch wrote: > Also, i think that: > > uriah /boot/kernel/kernel: da0: invalid primary partition table: Dangerously Dedicated (ignored) > uriah last message repeated 5 times > > ...73 of those silly messages are just beyond any form of usefulness. > Either we hide this completely behind bootverbose (back to the root of > this thread) since it bears no information at all (i already knew what > is written there, since it was my deliberate decision, and it could > not have happened unless being my deliberate decision), or we at least > ensure any of those messages is emitted at most once per drive. Hadn't we agreed to do this? I'm certainly in favour of the bootverbose approach. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 16:59:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from science.slc.edu (Science.SLC.Edu [198.83.6.248]) by hub.freebsd.org (Postfix) with ESMTP id 90B0637B405; Mon, 10 Dec 2001 16:59:07 -0800 (PST) Received: (from aschneid@localhost) by science.slc.edu (8.11.0/8.11.0) id fBB0vPg04755; Mon, 10 Dec 2001 19:57:25 -0500 (EST) (envelope-from aschneid) Date: Mon, 10 Dec 2001 19:57:25 -0500 From: Anthony Schneider To: Greg Lehey Cc: Hiten Pandya , Matthew Emmerton , current@FreeBSD.ORG, hackers@FreeBSD.ORG, Alfred Perlstein Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <20011210195725.A4697@mail.slc.edu> References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <002601c181cb$8c6a5e90$1200a8c0@gsicomp.on.ca> <20011210174711.A3208@mail.slc.edu> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <002601c181cb$8c6a5e90$1200a8c0@gsicomp.on.ca> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210174711.A3208@mail.slc.edu> <20011211105617.K63585@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211105617.K63585@monorchid.lemis.com>; from grog@FreeBSD.ORG on Tue, Dec 11, 2001 at 10:56:17AM +1030 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > On Monday, 10 December 2001 at 17:47:11 -0500, Anthony Schneider wrote: > > I'm no expert on journaled filesystems, but isn't the freebsd softupdat= es > > option similar? >=20 > No, at least not from a technical standpoint. From a user standpoint, > they both try to make things faster and more reliable, but they do it > in very different ways. >=20 Well, perhaps I should have made that clearer: I am not an expert on either journaled filesystems not am I an expert on FreeBSD's softupdates option, technically or other. > > perhaps there could be an upgrade to offer > > options SOFTERUPDATES > > as an equal-but-different alternative to jfs? >=20 > And what would that do? My thoughts were that if the two were similar in effect that it might be a relatively easy project to escalate towards achieving the same effects in one as the other. I understand that this is not necessarily the case. =20 > Greg -Anthony. --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwVWfEACgkQ+rDjkNht5F0tMQCfUGJdUfJ/VY4jz32OQc6zQYvq cEoAnRR/wlk0W2XKsd7zBYTwUjYx26tl =YSPd -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 18:11:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id E515937B41B; Mon, 10 Dec 2001 18:11:17 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fBB2BFP62867; Tue, 11 Dec 2001 03:11:15 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fBB2BWtx001080; Tue, 11 Dec 2001 03:11:32 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fBB2BVW05518; Tue, 11 Dec 2001 03:11:32 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fBB2BLx13783; Tue, 11 Dec 2001 03:11:21 +0100 (CET) (envelope-from ticso) Date: Tue, 11 Dec 2001 03:11:21 +0100 From: Bernd Walter To: Greg Lehey Cc: Matthew Dillon , Wilko Bulte , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011211031120.G11774@cicely8.cicely.de> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011211110633.M63585@monorchid.lemis.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > > > >>> performance without it - for reading OR writing. It doesn't matter > >>> so much for RAID{1,10}, but it matters a whole lot for something like > >>> RAID-5 where the difference between a spindle-synced read or write > >>> and a non-spindle-synched read or write can be upwards of 35%. > >> > >> If you have RAID5 with I/O sizes that result in full-stripe operations. > > > > Well, 'more then one disk' operations anyway, for random-I/O. Caching > > takes care of sequential I/O reasonably well but random-I/O goes down > > the drain for writes if you aren't spindle synced, no matter what > > the stripe size, > > Can you explain this? I don't see it. In FreeBSD, just about all I/O > goes to buffer cache. After waiting for the drives and not for vinum parity blocks. > > and will go down the drain for reads if you cross a stripe - > > something that is quite common I think. > > I think this is what Mike was referring to when talking about parity > calculation. In any case, going across a stripe boundary is not a > good idea, though of course it can't be avoided. That's one of the > arguments for large stripes. striped: If you have 512byte stripes and have 2 disks. You access 64k which is put into 2 32k transactions onto the disk. The wait time for the complete transaction is the worst of both, which is more than the average of a single disk. With spindle syncronisation the access time for both disks are beleaved to be identic and you get the same as with a single disk. Linear speed could be about twice the speed of a single drive. But this is more theoretic today than real. The average transaction size per disk decreases with growing number of spindles and you get more transaction overhead. Also the voice coil technology used in drives since many years add a random amount of time to the access time, which invalidates some of the spindle sync potential. Plus it may break some benefits of precaching mechanisms in drives. I'm almost shure there is no real performance gain with modern drives. raid5: For a write you have two read transactions and two writes. The two read are at the same position on two different spindless and there the same access time situation exists as in the case above. We don't have the problem with decreased transaction sizes. But we have the same problem with seek time and modern disks as in the case above plus we have the problem that the drives are not exactly equaly loaded which randomizes the access times again. I doubt that we have a performance gain with modern disks in the general case, but there might be some special uses. The last drives I saw which could do spindle sync was the IBM DCHS series. There are easier things to raise performance. Ever wondered why people claim vinums raid5 writes are slow? The answer is astonishing simple: Vinum does striped based locking, while the ufs tries to lay out data mostly ascending sectors. What happens here is that the first write has to wait for two reads and two writes. If we have an ascending write it has to wait for the first write to finish, because the stripe is still locked. The first is unlocked after both physical writes are on disk. Now we start our two reads which are (thanks to drives precache) most likely in the drives cache - than we write. The problem here is that physical writes gets serialized and the drive has to wait a complete rotation between each. If we had a fine grained locking which only locks the accessed sectors in the parity we would be able to have more than a single ascending write transaction onto a single drive. At best the stripe size is bigger than the maximum number of parallel ascending writes the OS does on the volume. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 18:26: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id A08DE37B637; Mon, 10 Dec 2001 18:25:28 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 2CE3881D01; Mon, 10 Dec 2001 20:25:28 -0600 (CST) Date: Mon, 10 Dec 2001 20:25:28 -0600 From: Alfred Perlstein To: "Brian F. Feldman" Cc: "Brandon D. Valentine" , freebsd-current@freebsd.org Subject: Re: Motion for removal of xargs(1) from base system Message-ID: <20011210202528.S92148@elvis.mu.org> References: <200112102311.fBANB3933575@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112102311.fBANB3933575@green.bikeshed.org>; from green@freebsd.org on Mon, Dec 10, 2001 at 06:11:03PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Brian F. Feldman [011210 17:11] wrote: > "Brandon D. Valentine" wrote: > > On Mon, 10 Dec 2001, Alfred Perlstein wrote: > > > > >* Jackie 'business-first' Cook [011210 16:19] wrote: > > >> > > >> As a replacement for the 'functionality' present in xargs(1), I propose > > >> implementing arbitrary length argument list passing right in the operating > > >> system. > > > > > >Nice proposal, where's the diff? > > > > I'd like to preempt the ensuing bikeshed by voting for green. > > I'd like to accept your nomination. People, I know you won't regret > choosing the right person for the job! I figured you'd be ok with removing xargs.... pfft. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 18:26:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 484E037B626; Mon, 10 Dec 2001 18:25:15 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fBB2PAf62929; Tue, 11 Dec 2001 03:25:10 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fBB2PVtx001312; Tue, 11 Dec 2001 03:25:31 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fBB2PTW05549; Tue, 11 Dec 2001 03:25:29 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fBB2PMV13813; Tue, 11 Dec 2001 03:25:22 +0100 (CET) (envelope-from ticso) Date: Tue, 11 Dec 2001 03:25:21 +0100 From: Bernd Walter To: Matthew Dillon Cc: Wilko Bulte , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011211032521.H11774@cicely8.cicely.de> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101849.fBAInSO47847@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112101849.fBAInSO47847@apollo.backplane.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 10, 2001 at 10:49:28AM -0800, Matthew Dillon wrote: > > :For RAID3 that is true. For the other ones... > : > :> performance without it - for reading OR writing. It doesn't matter > :> so much for RAID{1,10}, but it matters a whole lot for something like > :> RAID-5 where the difference between a spindle-synced read or write > :> and a non-spindle-synched read or write can be upwards of 35%. > : > :If you have RAID5 with I/O sizes that result in full-stripe operations. > : > :-- > :| / o / /_ _ email: wilko@FreeBSD.org > :|/|/ / / /( (_) Bulte Arnhem, The Netherlands > > Well, for reads a non-stripe-crossing op would still work reasonably > well. But for writes less then full-stripe operations without > spindle sync are going to be terrible due to the read-before-write > requirement (to calculate parity). The disk cache is useless in that > case. Modern disks do prereads and writes are streamed by tagged command queueing which invalidates this for linear access. For non linear access the syncronisation is shadowed partly by different seek times and different load on the spindles. The chance that the data and parity spindle have the heads on the same track is absolutely small for random access. With 15000 upm drives the maximum rotational delay is 4ms and the average is 2ms which gives you an maximum of only 1ms to gain under ideal conditions - which we don't have as I stated above. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 20:51:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43]) by hub.freebsd.org (Postfix) with ESMTP id 7591D37B405 for ; Mon, 10 Dec 2001 20:51:17 -0800 (PST) Received: (from nnd@localhost) by wint.itfs.nsk.su (8.11.6/8.11.4) id fBB4pBX33021; Tue, 11 Dec 2001 10:51:11 +0600 (NOVT) (envelope-from nnd) Date: Tue, 11 Dec 2001 10:51:11 +0600 (NOVT) Message-Id: <200112110451.fBB4pBX33021@wint.itfs.nsk.su> From: nnd@mail.nsk.ru (Nickolay Dudorov) To: current@FreeBSD.ORG Subject: Re: cvs commit: src/sbin/reboot boot_i386.8 src/sys/boot/i386/libi386 bootinfo.c src/sys/i386/i386 autoconf.c src/sys/kern tty_cons.c src/sys/sys cons.h reboot.h In-Reply-To: <200112102002.fBAK2Mh21219@freefall.freebsd.org> User-Agent: tin/1.5.9-20010723 ("Chord of Souls") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200112102002.fBAK2Mh21219@freefall.freebsd.org> Guido van Rooij wrote: > guido 2001/12/10 12:02:22 PST > > Modified files: > sbin/reboot boot_i386.8 > sys/boot/i386/libi386 bootinfo.c > sys/i386/i386 autoconf.c > sys/kern tty_cons.c > sys/sys cons.h reboot.h > Log: > Add new boot flag to i386 boot: -p. > This flag adds a pausing utility. When ran with -p, during the kernel > probing phase, the kernel will pause after each line of output. > This pausing can be ended with the '.' key, and is automatically > suspended when entering ddb. > > This flag comes in handy at systems without a serial port that either hang > during booting or reser. > Reviewed by: (partly by jlemon) > MFC after: 1 week > > Revision Changes Path > 1.32 +3 -1 src/sbin/reboot/boot_i386.8 > 1.31 +3 -0 src/sys/boot/i386/libi386/bootinfo.c > 1.160 +1 -1 src/sys/i386/i386/autoconf.c > 1.97 +24 -0 src/sys/kern/tty_cons.c > 1.27 +1 -0 src/sys/sys/cons.h > 1.20 +1 -0 src/sys/sys/reboot.h CURRENT kernel is not buildable (in fact "linkable") after this commit without DDB option. There is unguarded by "ifdef DDB" usage of 'db_active' variable at line 552 of 'src/sys/kern/tty_cons.c'. I know that using CURRENT without 'options DDB' is not recomended, but there is "MFC after: 1 week" in this commit, so this error must be corrected before this time. N.Dudorov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 22:42:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id B3D4B37B405 for ; Mon, 10 Dec 2001 22:42:21 -0800 (PST) Received: from pool0031.cvx40-bradley.dialup.earthlink.net ([216.244.42.31] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DgcF-0002Bj-00; Mon, 10 Dec 2001 22:42:11 -0800 Message-ID: <3C15AACB.A2FB565B@mindspring.com> Date: Mon, 10 Dec 2001 22:42:19 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jackie 'business-first' Cook Cc: freebsd-current@freebsd.org Subject: Re: Motion for removal of xargs(1) from base system References: <20011210221335.ACEB137B405@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jackie 'business-first' Cook wrote: [ ... plot to murder innocent xargs command ... ] Please don't. I use this on a daily basis. It is a much faster way to use find than "exec", since it doesn't require a billion instances of "grep". > As a replacement for the 'functionality' present in xargs(1), I propose > implementing arbitrary length argument list passing right in the operating > system. I would like to see how you propose to do this without making the kernel stack arbirarily large... and hacking up every shell, perl, mush, etc.. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 22:45:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 43AF637B405; Mon, 10 Dec 2001 22:45:15 -0800 (PST) Received: from pool0031.cvx40-bradley.dialup.earthlink.net ([216.244.42.31] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DgfC-00047P-00; Mon, 10 Dec 2001 22:45:14 -0800 Message-ID: <3C15AB82.FDF598A8@mindspring.com> Date: Mon, 10 Dec 2001 22:45:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hiten Pandya Cc: current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [SUGGESTION] - JFS for FreeBSD References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hiten Pandya wrote: > i wanted to ask if there were any _plans_ to port > JFS (Journaled File System) to FreeBSD... Not unless you have plans. When I was an IBM employee, they would not change the license, and so it's impossible to ship a CDROM where it's the boot FS, or boxes on which it is the boot FS, and still have it be legal, because of the license conflicts. I fought this for about a year within IBM, before I gave up. > It is used on IBM MainFrames and Enterprise servers > for high performance and maximum throughput... No, it's not. The Linux JFS is derived from the OS/2 JFS code, not the good AIX JFS code. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 23:51:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 00FE437B405 for ; Mon, 10 Dec 2001 23:51:14 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id IAA27652 for freebsd-current@FreeBSD.org; Tue, 11 Dec 2001 08:51:12 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fBB7dhK95573 for freebsd-current@FreeBSD.org; Tue, 11 Dec 2001 08:39:43 +0100 (MET) (envelope-from j) Date: Tue, 11 Dec 2001 08:39:43 +0100 From: Joerg Wunsch To: freebsd-current@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011211083943.Q97235@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , freebsd-current@FreeBSD.org References: <200112101150.aa33241@salmon.maths.tcd.ie> <20011210222003.4391539F0@overcee.netplex.com.au> <20011209102129.F97235@uriah.heep.sax.de> <20011210004350.6703C3810@overcee.netplex.com.au> <200112092200.fB9M0J660085@uriah.heep.sax.de> <20011210005928.9538A3810@overcee.netplex.com.au> <20011210091103.M97235@uriah.heep.sax.de> <20011211111629.O63585@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211111629.O63585@monorchid.lemis.com>; from grog@FreeBSD.org on Tue, Dec 11, 2001 at 11:16:29AM +1030 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As Peter Wemm wrote: > Yes, that is much safer, however there are certain bioses that have > interesting quirks that the MBR has to work around. The problem > when overlapping mbr and boot1 into the same block is that we no > longer have the space to do that. boot1.s has got *3* bytes free. Too bad. Peter, do you care to update the section about DD mode (and its dangers) in the FAQ after all this discussion? I could probably do it, too (the original entry is mine), but i had to quote your arguments only anyway. > Also (and I think this is more likely to be the problem you ran > into) many newer PC's are looking at the partition tables for a > suspend-to-disk partition or a FAT filesystem with a suspend-to-disk > dump file. Seems i really love my Toshiba (Libretto) that simply hibernates to the last nnn MB of the physical disk. ;-) (I have reserved a FreeBSD partition as a placeholder for the hibernation data.) > However, there is light at the end of the tunnel. EFI GPT is pretty > clean. Good to hear. While this sounds like dedicated disks will be gone then :), at least the format looks rationale enough. > It supports up to something like 16384 partitions ... It would be interesting to see how Windoze will arrange for 16K "drive" letters. :-)) The day vinum is up and ready to also cover the root FS, i won't need /any/ partition at all anymore. ;-) As Greg Lehey wrote: > > ...73 of those silly messages are just beyond any form of usefulness. > Hadn't we agreed to do this? I'm certainly in favour of the > bootverbose approach. I can't remember any agreement so far. But thinking a bit more about it, it sounds like the best solution to me, too. The only other useful option would be to restrict the message to once per drive, but that'll cost an additional per-drive flag, which is probably too much effort just for that message. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Dec 10 23:59: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 65C5537B405; Mon, 10 Dec 2001 23:58:59 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id EB8C9786E6; Tue, 11 Dec 2001 18:28:56 +1030 (CST) Date: Tue, 11 Dec 2001 18:28:56 +1030 From: Greg Lehey To: Terry Lambert Cc: Hiten Pandya , current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <20011211182856.A67986@monorchid.lemis.com> References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <3C15AB82.FDF598A8@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C15AB82.FDF598A8@mindspring.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday, 10 December 2001 at 22:45:22 -0800, Terry Lambert wrote: > Hiten Pandya wrote: >> i wanted to ask if there were any _plans_ to port >> JFS (Journaled File System) to FreeBSD... > > Not unless you have plans. When I was an IBM employee, they would > not change the license, and so it's impossible to ship a CDROM > where it's the boot FS, or boxes on which it is the boot FS, and > still have it be legal, because of the license conflicts. > > I fought this for about a year within IBM, before I gave up. Since then, it has become possible for the loader to load modules before booting the kernel. This means that, theoretically, it would be possible to have a JFS root file system. Given the strong opposition to the GPL in some factions of the FreeBSD project, I don't see this happening any time soon, especially since we still don't know if it will buy us anything. >> It is used on IBM MainFrames and Enterprise servers >> for high performance and maximum throughput... > > No, it's not. The Linux JFS is derived from the OS/2 JFS code, not > the good AIX JFS code. That's correct, but note that AIX is moving to this code base too, so it's not as if it's second-rate. From what I've seen of the structures, JFS2 is *much* better than JFS1. I haven't compared performance. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 0: 4:46 2001 Delivered-To: freebsd-current@freebsd.org Received: from FLA9Aaa003.fko.mesh.ad.jp (FLA9Aaa003.fko.mesh.ad.jp [61.193.66.195]) by hub.freebsd.org (Postfix) with SMTP id D3BF537B41B for ; Tue, 11 Dec 2001 00:04:40 -0800 (PST) Message-ID: <20011211.1659140285.babaq@haisin-000012-neko.gasuki.com> Date: Tue, 11 Dec 2001 16:59:17 +0900 From: haisin-000012@neko.gasuki.com Subject: =?ISO-2022-JP?B?GyRCkXQlaSVWISYlXiU4JUQlL5BzGyhC?= MIME-Version: 1.0 X-Mail-Agent: BSMTP DLL Jan 13 2001 by Tatsuo Baba Content-Type: text/plain; charset=ISO-2022-JP To: undisclosed-recipients:; Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG $B$"$C$?$+$$29$b$j;}$C$F$^$9$+!)(B $B4($$?4$rKd$a$F$/$l$k$=$s$J=P2q$$$,$3$3$K$O$"$j$^$9!#(B $B$?$a$7$K$"$J$?$N5$;}$A$r=q$-9~$s$G$4$i$s(B $B4j$$$O$+$J$i$:3p$$$^$9$h!*(B Http://www.if-j.net $B=P2q$$7O%5%$%H!V%$%U!W$G$9!#(B $B$"$J$?$KKbK!$r%F%/%^%/%^%d%3%s‘{(B $B=w@-L5NA$5$i$K%-%c%C%7%g%P%C%/!*(B $BCK@-$b#3#0%]%$%s%HL5NACf!*(B $B7HBSEEOC$+$4<+Bp$NEEOCHV9f$GEPO?$7$F$/$@$5$$!#(B $B%"%I%l%9EyHs8x3+$G$9$N$G0B?4$7$F$4MxMQ$/$@$5$$!#(B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 0:54:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id B8DE637B405; Tue, 11 Dec 2001 00:54:10 -0800 (PST) Received: from pool0063.cvx21-bradley.dialup.earthlink.net ([209.179.192.63] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Difs-0000WL-00; Tue, 11 Dec 2001 00:54:05 -0800 Message-ID: <3C15C9B4.C74F914@mindspring.com> Date: Tue, 11 Dec 2001 00:54:12 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: Hiten Pandya , current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [SUGGESTION] - JFS for FreeBSD References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <3C15AB82.FDF598A8@mindspring.com> <20011211182856.A67986@monorchid.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg Lehey wrote: > Since then, it has become possible for the loader to load modules > before booting the kernel. This means that, theoretically, it would > be possible to have a JFS root file system. Given the strong > opposition to the GPL in some factions of the FreeBSD project, I don't > see this happening any time soon, especially since we still don't know > if it will buy us anything. ? OK, I load the kernel from the JFS. I mount the root FS, which is a JFS. I read the module "jfs.ko" from the JFS so that I can mount the root FS, which is a JFS, so I can read the module "jfs.ko" from the JFS so that I can mount the root FS, which is a JFS, so I can read the module "jfs.ko" from the JFS so that I can mount the root FS, which is a JFS, so I can... Do you see the problem yet? > >> It is used on IBM MainFrames and Enterprise servers > >> for high performance and maximum throughput... > > > > No, it's not. The Linux JFS is derived from the OS/2 JFS code, not > > the good AIX JFS code. > > That's correct, but note that AIX is moving to this code base too, so > it's not as if it's second-rate. From what I've seen of the > structures, JFS2 is *much* better than JFS1. I haven't compared > performance. None of the Web Connections RS/6000 machines ran this OS/2 derived code. I was under the impression that it was there for Linux compatability. My impression is, layout or not, the original JFS is much better code, overall. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 1:15:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id 4CB6337B416; Tue, 11 Dec 2001 01:14:41 -0800 (PST) Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id LAA11498; Tue, 11 Dec 2001 11:14:26 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (h88.229.dialup.iptcom.net [212.9.229.88]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id LAA42169; Tue, 11 Dec 2001 11:14:23 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id fBB9DCF01541; Tue, 11 Dec 2001 11:13:12 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3C15CED5.20D65BFE@FreeBSD.org> Date: Tue, 11 Dec 2001 11:16:05 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Terry Lambert Cc: Greg Lehey , Hiten Pandya , current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [SUGGESTION] - JFS for FreeBSD References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <3C15AB82.FDF598A8@mindspring.com> <20011211182856.A67986@monorchid.lemis.com> <3C15C9B4.C74F914@mindspring.com> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Greg Lehey wrote: > > Since then, it has become possible for the loader to load modules > > before booting the kernel. This means that, theoretically, it would > > be possible to have a JFS root file system. Given the strong > > opposition to the GPL in some factions of the FreeBSD project, I don't > > see this happening any time soon, especially since we still don't know > > if it will buy us anything. > > ? > > OK, I load the kernel from the JFS. I mount the root FS, which > is a JFS. I read the module "jfs.ko" from the JFS so that I can > mount the root FS, which is a JFS, so I can read the module "jfs.ko" > from the JFS so that I can mount the root FS, which is a JFS, so I > can read the module "jfs.ko" from the JFS so that I can mount the > root FS, which is a JFS, so I can... > > Do you see the problem yet? Libstand (and hence the loader) could be extended to allow reading files from jfs without using any GPL'ed code. For example our loader can load modules from the FAT even though we do not have any M$ code. :) Alternatively, /boot could be placed on separate filesystem, which could be ufs or anything else supported by the loader. -Maxim > > >> It is used on IBM MainFrames and Enterprise servers > > >> for high performance and maximum throughput... > > > > > > No, it's not. The Linux JFS is derived from the OS/2 JFS code, not > > > the good AIX JFS code. > > > > That's correct, but note that AIX is moving to this code base too, so > > it's not as if it's second-rate. From what I've seen of the > > structures, JFS2 is *much* better than JFS1. I haven't compared > > performance. > > None of the Web Connections RS/6000 machines ran this OS/2 derived > code. I was under the impression that it was there for Linux > compatability. My impression is, layout or not, the original JFS > is much better code, overall. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 1:15:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from draco.macsch.com (draco.macsch.com [192.73.8.1]) by hub.freebsd.org (Postfix) with ESMTP id 36F0B37B42C for ; Tue, 11 Dec 2001 01:14:49 -0800 (PST) Received: from mailmuc.muc.eu.mscsoftware.com (mailmuc.muc.macsch.com [161.34.37.20]) by draco.macsch.com (8.9.3/8.9.3) with ESMTP id BAA24634 for ; Tue, 11 Dec 2001 01:10:24 -0800 (PST) Received: from hunter.muc.macsch.com (hunter.muc.macsch.com [172.17.22.32]) by mailmuc.muc.eu.mscsoftware.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id fBB9EWn22623; Tue, 11 Dec 2001 10:14:32 +0100 Received: from hunter.muc.macsch.com (localhost.muc.macsch.com [127.0.0.1]) by hunter.muc.macsch.com (8.11.6/8.11.6) with ESMTP id fBB9Cu904925; Tue, 11 Dec 2001 10:12:57 +0100 (CET) (envelope-from Georg.Koltermann@mscsoftware.com) Date: Tue, 11 Dec 2001 10:12:56 +0100 Message-ID: From: Georg-W Koltermann To: current@freebsd.org Subject: panic: kernel trap doesn't have ucred User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/21.1 (i386--freebsd) MULE/5.0 (SAKAKI) Organization: MSC Software X-Attribution: gwk MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I get a panic "kernel trap doesn't have ucred" when I try to install Linux ORACLE 8.1.7. The ORACLE installation program is a JAVA application and only seems to work with the included JRE (the IBM 1.1.8 JRE according to the LICENSE file). The JRE is using native Linux threads, and I know I the FreeBSD linuxulator doesn't completely support Linux threads. It shouldn't panic, however. -current was CVSuped on 12/6 at 6 p.m. CET. Any clues from the stack trace below? Anything else I should provide? -- Regards, Georg. hunter# gdb -k /usr/obj/usr/src/sys/HUNTER/kernel.debug vmcore.5 GNU gdb 4.18 Copyright 1998 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-unknown-freebsd"... IdlePTD 4333568 initial pcb at 330560 panicstr: kernel trap doesn't have ucred panic messages: --- panic: kernel trap doesn't have ucred panic: kernel trap doesn't have ucred Uptime: 9h57m30s dumping to dev ad0s2b, offset 2000128 dump ata0: resetting devices .. done 1023 1022 1021 1020 (--snip--) --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492 492 if (!dodump) (kgdb) where #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492 #1 0xc019b6e3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:335 #2 0xc019bb1d in panic (fmt=0xc02dfec0 "kernel trap doesn't have ucred") at /usr/src/sys/kern/kern_shutdown.c:634 #3 0xc0296660 in trap (frame={tf_fs = 24, tf_es = -1070792688, tf_ds = 16, tf_edi = 0, tf_esi = 256, tf_ebp = -570946320, tf_isp = -570946352, tf_ebx = 514, tf_edx = -1070159328, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071077920, tf_cs = 8, tf_eflags = 70, tf_esp = -1070736513, tf_ss = -1070870117}) at /usr/src/sys/i386/i386/trap.c:412 #4 0xc028a5e0 in Debugger (msg=0xc02bd19b "panic") at machine/cpufunc.h:63 #5 0xc019bb08 in panic (fmt=0xc02dfec0 "kernel trap doesn't have ucred") at /usr/src/sys/kern/kern_shutdown.c:621 #6 0xc0296660 in trap (frame={tf_fs = -1072168945, tf_es = -1088487377, tf_ds = -1071120337, tf_edi = -1088422624, tf_esi = 3, tf_ebp = -1088422712, tf_isp = -570946200, tf_ebx = 17, tf_edx = 16, tf_ecx = -1088422668, tf_eax = 3, tf_trapno = 9, tf_err = 28, tf_eip = -1071071377, tf_cs = 8, tf_eflags = 65666, tf_esp = 673044849, tf_ss = 31}) at /usr/src/sys/i386/i386/trap.c:412 #7 0xc028bf6f in doreti_iret () #8 0x281dd9d4 in ?? () #9 0x281dc55a in ?? () #10 0x2807feca in ?? () (kgdb) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 1:35:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 642BC37B417; Tue, 11 Dec 2001 01:35:51 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011211093551.BEIG4213.rwcrmhc52.attbi.com@peter3.wemm.org>; Tue, 11 Dec 2001 09:35:51 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBB9Zos37788; Tue, 11 Dec 2001 01:35:50 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D4BF638CC; Tue, 11 Dec 2001 01:35:50 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Greg Lehey , Hiten Pandya , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: [SUGGESTION] - JFS for FreeBSD In-Reply-To: <3C15C9B4.C74F914@mindspring.com> Date: Tue, 11 Dec 2001 01:35:50 -0800 From: Peter Wemm Message-Id: <20011211093550.D4BF638CC@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > Greg Lehey wrote: > > Since then, it has become possible for the loader to load modules > > before booting the kernel. This means that, theoretically, it would > > be possible to have a JFS root file system. Given the strong > > opposition to the GPL in some factions of the FreeBSD project, I don't > > see this happening any time soon, especially since we still don't know > > if it will buy us anything. > > ? > > OK, I load the kernel from the JFS. I mount the root FS, which > is a JFS. I read the module "jfs.ko" from the JFS so that I can > mount the root FS, which is a JFS, so I can read the module "jfs.ko" > from the JFS so that I can mount the root FS, which is a JFS, so I > can read the module "jfs.ko" from the JFS so that I can mount the > root FS, which is a JFS, so I can... > > Do you see the problem yet? It is not a problem. The *kernel* does not load jfs.ko, it is loader itself. There is no reason why a trivial non-gpl jfs reader couldn't be written for boot2 and loader if the need was great enough. Or have /boot as a seperate file system (eg: UFS or FAT32). We do this on IA64 where /boot is a FAT32 filesystem (not exactly, but close enough. I usually mount it on /efi and make /boot/ a symlink to /efi/boot so that in EFI we have a /boot as well). Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 3:16: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id F138437B416 for ; Tue, 11 Dec 2001 03:15:55 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16Dkuv-000AEA-00 for current@FreeBSD.org; Tue, 11 Dec 2001 13:17:45 +0200 From: Sheldon Hearn To: current@FreeBSD.org Subject: __xuname gone AWOL? Date: Tue, 11 Dec 2001 13:17:45 +0200 Message-ID: <39317.1008069465@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi folks, Since last week, I'm having trouble compiling one of the utilities supplied with Exim, which calls uname(): gcc -O -pipe -march=pentiumpro -march=pentiumpro \ -o exim_lock exim_lock.c -lcrypt -lpam /tmp/cc2YeHtC.o: In function `main': /tmp/cc2YeHtC.o(.text+0x50d): undefined reference to `__xuname' *** Error code 1 __xuname.c is still included in SRCS in src/lib/libc/gen/Makefile.inc, but the symbol isn't in my installed libc. Any ideas? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 3:29:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by hub.freebsd.org (Postfix) with ESMTP id 8FF1A37B417 for ; Tue, 11 Dec 2001 03:29:18 -0800 (PST) Received: from host213-123-128-3.in-addr.btopenworld.com ([213.123.128.3] helo=there) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 16Dl64-0007O5-00; Tue, 11 Dec 2001 11:29:16 +0000 Content-Type: text/plain; charset="iso-8859-1" From: Dominic Marks To: Sheldon Hearn , current@FreeBSD.org Subject: Re: __xuname gone AWOL? Date: Tue, 11 Dec 2001 11:28:58 +0000 X-Mailer: KMail [version 1.3.2] References: <39317.1008069465@axl.seasidesoftware.co.za> In-Reply-To: <39317.1008069465@axl.seasidesoftware.co.za> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 11 December 2001 11:17 am, Sheldon Hearn wrote: > Hi folks, > > Since last week, I'm having trouble compiling one of the utilities > supplied with Exim, which calls uname(): > > gcc -O -pipe -march=pentiumpro -march=pentiumpro \ > -o exim_lock exim_lock.c -lcrypt -lpam > /tmp/cc2YeHtC.o: In function `main': > /tmp/cc2YeHtC.o(.text+0x50d): undefined reference to `__xuname' > *** Error code 1 > > __xuname.c is still included in SRCS in > src/lib/libc/gen/Makefile.inc, but the symbol isn't in my installed > libc. On a complete different application, but similar problem. KDE Konqueror on -CURRENT also crashes because of this. > Any ideas? > > Ciao, > Sheldon. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- Dominic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 6: 8: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 574CA37B416; Tue, 11 Dec 2001 06:07:59 -0800 (PST) Received: from pool0114.cvx21-bradley.dialup.earthlink.net ([209.179.192.114] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DnZd-0002IS-00; Tue, 11 Dec 2001 06:07:58 -0800 Message-ID: <3C161343.A62C005C@mindspring.com> Date: Tue, 11 Dec 2001 06:08:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: Greg Lehey , Hiten Pandya , current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [SUGGESTION] - JFS for FreeBSD References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <3C15AB82.FDF598A8@mindspring.com> <20011211182856.A67986@monorchid.lemis.com> <3C15C9B4.C74F914@mindspring.com> <3C15CED5.20D65BFE@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > > OK, I load the kernel from the JFS. I mount the root FS, which > > is a JFS. I read the module "jfs.ko" from the JFS so that I can > > mount the root FS, which is a JFS, so I can read the module "jfs.ko" > > from the JFS so that I can mount the root FS, which is a JFS, so I > > can read the module "jfs.ko" from the JFS so that I can mount the > > root FS, which is a JFS, so I can... > > > > Do you see the problem yet? > > Libstand (and hence the loader) could be extended to allow reading > files from jfs without using any GPL'ed code. For example our loader > can load modules from the FAT even though we do not have any M$ code. > :) Alternatively, /boot could be placed on separate filesystem, which > could be ufs or anything else supported by the loader. Patches appreciated. Note that if you do a read-only JFS, you are more than half way there to a n0n-GPL'ed implementation, so you might as well finish it off, instead of porting the IBM code. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 6: 9:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 9DB9A37B419; Tue, 11 Dec 2001 06:09:43 -0800 (PST) Received: from pool0114.cvx21-bradley.dialup.earthlink.net ([209.179.192.114] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DnbK-0003zf-00; Tue, 11 Dec 2001 06:09:42 -0800 Message-ID: <3C1613AD.53C45B3@mindspring.com> Date: Tue, 11 Dec 2001 06:09:49 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Greg Lehey , Hiten Pandya , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: [SUGGESTION] - JFS for FreeBSD References: <20011211093550.D4BF638CC@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > It is not a problem. The *kernel* does not load jfs.ko, it is loader > itself. There is no reason why a trivial non-gpl jfs reader couldn't be > written for boot2 and loader if the need was great enough. Or have /boot > as a seperate file system (eg: UFS or FAT32). We do this on IA64 where > /boot is a FAT32 filesystem (not exactly, but close enough. I usually > mount it on /efi and make /boot/ a symlink to /efi/boot so that in EFI > we have a /boot as well). JFS patches? Sysinstall patches? /usr/src/lib/stand patches? /usr/src/sys/boot/* patches? 8^). --- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 6:34:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 4D5C937B416; Tue, 11 Dec 2001 06:34:39 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id fBBEYbS69823; Tue, 11 Dec 2001 15:34:37 +0100 (CET) (envelope-from wkb) Date: Tue, 11 Dec 2001 15:34:37 +0100 From: Wilko Bulte To: Greg Lehey Cc: Matthew Dillon , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011211153437.A69755@freebie.xs4all.nl> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211110633.M63585@monorchid.lemis.com>; from grog@FreeBSD.org on Tue, Dec 11, 2001 at 11:06:33AM +1030 X-OS: FreeBSD 4.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > > > >>> performance without it - for reading OR writing. It doesn't matter > >>> so much for RAID{1,10}, but it matters a whole lot for something like > >>> RAID-5 where the difference between a spindle-synced read or write > >>> and a non-spindle-synched read or write can be upwards of 35%. > >> > >> If you have RAID5 with I/O sizes that result in full-stripe operations. > > > > Well, 'more then one disk' operations anyway, for random-I/O. Caching > > takes care of sequential I/O reasonably well but random-I/O goes down > > the drain for writes if you aren't spindle synced, no matter what > > the stripe size, > > Can you explain this? I don't see it. In FreeBSD, just about all I/O > goes to buffer cache. > > > and will go down the drain for reads if you cross a stripe - > > something that is quite common I think. > > I think this is what Mike was referring to when talking about parity > calculation. In any case, going across a stripe boundary is not a > good idea, though of course it can't be avoided. That's one of the > arguments for large stripes. In a former life I was involved with a HB striping product for SysVr2 that had a slightly modified filesystem that 'knew' when it was working on a striped disk. And as it know, it avoided posting I/O s that crossed stripes. W/ -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 8: 8:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 0B54037B416; Tue, 11 Dec 2001 08:08:22 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fBBG8Kg69863; Tue, 11 Dec 2001 17:08:20 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fBBG8Itx005977; Tue, 11 Dec 2001 17:08:18 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fBBG8HW06693; Tue, 11 Dec 2001 17:08:17 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fBBG85V15507; Tue, 11 Dec 2001 17:08:05 +0100 (CET) (envelope-from ticso) Date: Tue, 11 Dec 2001 17:08:04 +0100 From: Bernd Walter To: Wilko Bulte Cc: Greg Lehey , Matthew Dillon , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011211170803.C15004@cicely8.cicely.de> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211153437.A69755@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011211153437.A69755@freebie.xs4all.nl> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 11, 2001 at 03:34:37PM +0100, Wilko Bulte wrote: > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > > I think this is what Mike was referring to when talking about parity > > calculation. In any case, going across a stripe boundary is not a > > good idea, though of course it can't be avoided. That's one of the > > arguments for large stripes. > > In a former life I was involved with a HB striping product for SysVr2 > that had a slightly modified filesystem that 'knew' when it was > working on a striped disk. And as it know, it avoided posting I/O s > that crossed stripes. Here some real world statistics with UFS softupdates: Plex d1.p0: Size: 8736473088 bytes (8331 MB) Subdisks: 3 State: up Organization: striped Stripe size: 256 kB Part of volume d1 Reads: 83546 Bytes read: 258429952 (246 MB) Average read: 3093 bytes Writes: 100109 Bytes written: 818750464 (780 MB) Average write: 8178 bytes Multiblock: 279 (0%) Multistripe: 82 (0%) Subdisk 0: d1.p0.s0 state: up size 2912157696 (2777 MB) Subdisk 1: d1.p0.s1 state: up size 2912157696 (2777 MB) Subdisk 2: d1.p0.s2 state: up size 2912157696 (2777 MB) You can easily see that the number of Multistripe transactions are unnoticeable low. Here another case with 64k stripe size: Plex d7.p0: Size: 36419796992 bytes (34732 MB) Subdisks: 2 State: up Organization: striped Stripe size: 64 kB Part of volume d7 Reads: 934001 Bytes read: 3718752768 (3546 MB) Average read: 3981 bytes Writes: 220293 Bytes written: 3702993920 (3531 MB) Average write: 16809 bytes Multiblock: 50037 (4%) Multistripe: 25047 (2%) Subdisk 0: d7.p0.s0 state: up size 18209898496 (17366 MB) Subdisk 1: d7.p0.s1 state: up size 18209898496 (17366 MB) You can see that even we have an absolute extrem situation the number of multistripe transactions is still very low. But a value of 384k would be a much better value for other reasons. You may want to compare the multistripe number with the multiblock number and yes it doesn't look that good anymore, but you also see that the change from 64k to 256k get much better results, while the average transaction size is 5865 bytes for the first case and 6429 bytes for the second - not that different. Most of my plexes are concat anyway. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 13:50:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id F06E837B417 for ; Tue, 11 Dec 2001 13:50:43 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id WAA08214; Tue, 11 Dec 2001 22:50:42 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fBBLRsr09655; Tue, 11 Dec 2001 22:27:54 +0100 (MET) (envelope-from j) Date: Tue, 11 Dec 2001 22:27:54 +0100 (MET) Message-Id: <200112112127.fBBLRsr09655@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> From: j@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: [SUGGESTION] - JFS for FreeBSD X-Original-Newsgroups: local.freebsd.current To: freebsd-current@freebsd.org Cc: Hiten Pandya Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hiten Pandya wrote: > i wanted to ask if there were any _plans_ to port > JFS (Journaled File System) to FreeBSD... As long as nobody gets the idea to import VxFS... It's dog slow compared to UFS+softupdates. :-) Dog slow even compared to Solaris 8 UFS+logging. Of course, i know it has other advantages, but the journalling feature doesn't seem to be the best. Even my notebook with its slooow (low-power) IDE drive is faster than Solaris 8 fibre-channel disks running with VxFS. ;-) ("faster" means in terms of filesystem metadata operation, like file creations and deletions, since that's the area you normally want to employ journalling or softupdates for.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 14: 7:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id E30AD37B41C for ; Tue, 11 Dec 2001 14:07:43 -0800 (PST) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.11.4/8.11.4) id fBBM7eO96852; Tue, 11 Dec 2001 14:07:40 -0800 (PST) (envelope-from sgk) Date: Tue, 11 Dec 2001 14:07:40 -0800 From: Steve Kargl To: Joerg Wunsch Cc: freebsd-current@FreeBSD.ORG, Hiten Pandya Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <20011211140740.A96338@troutmask.apl.washington.edu> References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <200112112127.fBBLRsr09655@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112112127.fBBLRsr09655@uriah.heep.sax.de>; from j@uriah.heep.sax.de on Tue, Dec 11, 2001 at 10:27:54PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 11, 2001 at 10:27:54PM +0100, Joerg Wunsch wrote: > Hiten Pandya wrote: > > > i wanted to ask if there were any _plans_ to port > > JFS (Journaled File System) to FreeBSD... > > As long as nobody gets the idea to import VxFS... It's dog slow > compared to UFS+softupdates. :-) Dog slow even compared to [This is directed at Joerg, but I deleted the original email. URL is wrapped with a \.] http://www.usenix.org/publications/library/proceedings/usenix2000/general\ /full_papers/seltzer/seltzer_html/index.html -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 14:16:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from acc0.visti.net (acc0.visti.net [195.64.225.233]) by hub.freebsd.org (Postfix) with ESMTP id F159A37B416 for ; Tue, 11 Dec 2001 14:16:06 -0800 (PST) Received: from gw0.visti.net (gw0.visti.net [195.64.225.229]) by acc0.visti.net (8.8.8-Elvisti-980428/8.8.8) with ESMTP id AAA16541 for ; Wed, 12 Dec 2001 00:16:04 +0200 (EET) Received: from cscorp.com.ua (Ivanov-gw7r.visti.net [195.64.224.210] (may be forged)) by gw0.visti.net (8.12.1/8.12.1) with ESMTP id fBBLlx7s082230 for ; Wed, 12 Dec 2001 00:16:00 +0200 (EET)?g (envelope-from csc_seminar@cscorp.com.ua) Date: Wed, 12 Dec 2001 00:16:00 +0200 (EET) Message-Id: <200112112216.fBBLlx7s082230@gw0.visti.net> Received: from tanydura [192.168.101.101] by cscorp.com.ua [195.64.224.210] with SMTP (MDaemon.PRO.v5.0.4.R) for ; Tue, 11 Dec 2001 20:20:40 +0000 From: csc_seminar To: freebsd-current@freebsd.org Subject: Invitation for seminar. Ïðèãëàøåíèå íà ñåìèíàð Reply-To: csc_seminar@cscorp.com.ua Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251 X-MDRemoteIP: 192.168.101.101 X-Return-Path: csc_seminar@cscorp.com.ua X-MDaemon-Deliver-To: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ïðåäñòàâèòåëüñòâî Êîìïàíèè Capital Standard Corporation ïðèãëàøàåò Âàñ ïðèíÿòü ó÷àñòèå â îäíîäíåâíûõ êîíñóëüòàöèîííûõ ñåìèíàðàõ-ïðàêòèêóìàõ äëÿ ýôôåêòèâíîãî è áûñòðîãî ïîâûøåíèÿ êâàëèôèêàöèè ñîòðóäíèêîâ Âàøåé êîìïàíèè Îäíîäíåâíûé êîíñóëüòàöèîííûé ñåìèíàð-ïðàêòèêóì «Áèðæåâàÿ òîðãîâëÿ íà ìåæäóíàðîäíûõ ôèíàíñîâûõ ðûíêàõ. Ïðàêòè÷åñêèå àñïåêòû» Äàòà ïðîâåäåíèÿ: 19 äåêàáðÿ 2001 ãîäà Âðåìÿ ïðîâåäåíèÿ ñåìèíàðà: 9.30-17.30 Ìåñòî ïðîâåäåíèÿ: Èíñòèòóò ìåæäóíàðîäíûõ îòíîøåíèé  ïðîãðàììå ñåìèíàðà: 1. Ñïåêóëÿöèè - êàê ñïîñîá ïðèóìíîæåíèÿ êàïèòàëà: - ×àñòíûå èíâåñòîðû - Êîðïîðàòèâíûå è äðóãèå ó÷àñòíèêè ðûíêà - Ñóììà, äîñòàòî÷íàÿ äëÿ ðàáîòû 2. Èíñòðóìåíòû ìèðîâûõ òîâàðíûõ è ôèíàíñîâûõ ðûíêîâ: - FOREX - ìåæäóíàðîäíûé ðûíîê îáìåíà âàëþò - Ôüþ÷åðñíûå è îïöèîííûå êîíòðàêòû 3. Òåõíîëîãèÿ è ìåõàíèçì áèðæåâûõ è âíåáèðæåâûõ îïåðàöèé: - Çàêîíîäàòåëüíàÿ áàçà, ïðàâèëà è ïðàêòèêà àìåðèêàíñêîé ìîäåëè òîðãîâëè - Âàëþòíûé ðûíîê «spot» - Áèðæåâûå òîðãîâûå ñèñòåìû - Êîìïüþòåðíûå òîðãîâûå ñèñòåìû - Èíôîðìàöèîííûå ñèñòåìû è êîìïüþòåðíûå òåõíîëîãèè ïî îáåñïå÷åíèþ äèëèíãîâûõ îïåðàöèé 4. Êàê «äîòÿíóòüñÿ» äî ðûíêà: - Áðîêåðñêàÿ êîìïàíèÿ - Ïðèíöèïàë (ìàðêåò-ìåéêåð) - Òîðãîâûé ñ÷¸ò - Ìàðæà - Êðåäèòíîå ïëå÷î - Ñîâåðøåíèå ñäåëêè - Ïëþñû è ìèíóñû "èíòåðíåò-òîðãîâëè" - Ïðèáûëüíîñòü îïåðàöèé 5. Ïðîãíîçèðîâàíèå ðûíî÷íûõ òåíäåíöèé: - Òåõíè÷åñêèé àíàëèç - Ôóíäàìåíòàëüíûé àíàëèç - Ïðîôåññèîíàëüíûå êîìïüþòåðíûå ñèñòåìû è ïðîãðàììíîå îáåñïå÷åíèå, èñïîëüçóåìîå â ðàáîòå äèëåðîâ Ñòîèìîñòü ó÷àñòèÿ â ñåìèíàðå: 440 ãðèâåí Äëÿ âòîðîãî è òðåòüåãî ó÷àñòíèêà îò îäíîé êîìïàíèè ñêèäêà – 10%.  ñòîèìîñòü âêëþ÷åíû: îáó÷åíèå è êîíñóëüòàöèè íà ñåìèíàðå, îáåä, êîôå-áðåéêè. Ýêñêëþçèâíûé àëüáîì ìàòåðèàëîâ «Áèðæåâàÿ òîðãîâëÿ íà ìåæäóíàðîäíûõ ôèíàíñîâûõ ðûíêàõ. Ïðàêòè÷åñêèå àñïåêòû», ïîäãîòîâëåííîãî ýêñïåðòàìè ñïåöèàëüíî äëÿ ó÷àñòíèêîâ ñ ó÷¸òîì âñåõ ïîñëåäíèõ èçìåíåíèé è äîïîëíåíèé. Îäíîäíåâíûé êîíñóëüòàöèîííûé ñåìèíàð-ïðàêòèêóì: «Òàìîæåííîå ðåãóëèðîâàíèå âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè» Äàòà ïðîâåäåíèÿ: 21 äåêàáðÿ 2001 ãîäà Âðåìÿ ïðîâåäåíèÿ ñåìèíàðà: 9.30-17.30 Ìåñòî ïðîâåäåíèÿ: Êîíôåðåíö-çàë ãîñòèíèöû «Ñàíêò-Ïåòåðáóðã» Â ïðîãðàììå ñåìèíàðà: Îñîáåííîñòè òàìîæåííîãî çàêîíîäàòåëüñòâà â ñôåðå âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè. Çàêîí Óêðàèíû «Î Òàìîæåííîì òàðèôå Óêðàèíû» îò 5.04.2001 ¹ 2371-²²². Èçìåíåíèÿ è äîïîëíåíèÿ â Çàêîí Óêðàèíû ïî ñîñòîÿíèþ íà 1.12.01. Óêðàèíñêàÿ òîâàðíàÿ íîìåíêëàòóðà âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè. Îñîáåííîñòè òàìîæåííîãî îôîðìëåíèÿ â ðàìêàõ ñîãëàøåíèé î ñâîáîäíîé òîðãîâëå. Ïåðñïåêòèâà ðàçâèòèÿ çîíû ñâîáîäíîé òîðãîâëè. Íîâûå ïðàâèëà ñòðàíû ïðîèñõîæäåíèÿ òîâàðîâ. Ïîðÿäîê ïðèìåíåíèÿ ñåðòèôèêàòîâ CT-1, EUR 1,2. Âîïðîñû êëàññèôèêàöèè òîâàðîâ. Îáçîð íîðìàòèâíûõ äîêóìåíòîâ ÃÒÑÓ ïî âîïðîñàì òàðèôíîãî ðåãóëèðîâàíèÿ ïî ñîñòîÿíèþ íà 1.12.01. Îñîáåííîñòè çàïîëíåíèÿ ÃÒÄ ïðè ðàçëè÷íûõ òàìîæåííûõ ðåæèìàõ. Ëèçèíãîâûå êîíòðàêòû, âðåìåííûé ââîç òîâàðà. Îôîðìëåíèå ÃÒÄ ïî âíåøíåýêîíîìè÷åñêèì äîãîâîðàì ñ ó÷àñòèåì áîëåå äâóõ ñòîðîí. Êðèòåðèè îïðåäåëåíèÿ òàìîæåííûìè îðãàíàìè Óêðàèíû «ãðóïï ðèñêà» (âíåøíåýêîíîìè÷åñêèå îïåðàöèè, êîòîðûå òðåáóþò äåòàëüíîé ïðîâåðêè íà çàêîííîñòü ñäåëêè). Óñòàíîâëåíèå ôàêòîâ òàìîæåííûõ ïðàâîíàðóøåíèé, êëàññèôèêàöèÿ è ïðîöåññóàëüíîå îôîðìëåíèå ôàêòîâ ïðàâîíàðóøåíèé, ñàíêöèè, ïðåäóñìîòðåííûå çàêîíîäàòåëüñòâîì, ïîñëåäñòâèÿ âîçìîæíûå äëÿ ñóáúåêòîâ ÂÝÄ. Ïðàâîâûå îñíîâû äëÿ îñóùåñòâëåíèÿ ìåæäóíàðîäíîé àäìèíèñòðàòèâíîé ïîìîùè â òàìîæåííûõ çîíàõ (ó÷àñòèå Óêðàèíû â ìåæäóíàðîäíûõ êîíâåíöèÿõ ïî òàìîæåííûì âîïðîñàì, äâóõ- è ìíîãîñòîðîííèå ìåæãîñóäàðñòâåííûå äîãîâîðà). Ïîðÿäîê ðåàëèçàöèè êîíâåíöèé, ñîãëàøåíèé, î âçàèìíîé àäìèíèñòðàòèâíîé ïîìîùè â òàìîæåííûõ âîïðîñàõ. Ñòîèìîñòü ó÷àñòèÿ â ñåìèíàðå 570 ãðèâåí Äëÿ âòîðîãî è òðåòüåãî ó÷àñòíèêà îò îäíîé ôèðìû ñêèäêà – 10%.  ñòîèìîñòü âêëþ÷åíû: îáó÷åíèå è êîíñóëüòàöèè íà ñåìèíàðå, îáåä, êîôå-áðåéêè. Ýêñêëþçèâíûé àëüáîì ìàòåðèàëîâ «Òàìîæåííîå ðåãóëèðîâàíèå âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè», ïîäãîòîâëåííîãî ýêñïåðòàìè ñïåöèàëüíî äëÿ ó÷àñòíèêîâ ñ ó÷¸òîì âñåõ ïîñëåäíèõ èçìåíåíèé è äîïîëíåíèé Íàøà êîìïàíèÿ ïðåäëàãàåò òàêóþ óñëóãó êàê ïðîâåäåíèå èíäèâèäóàëüíûõ êîíñóëüòàöèîííûõ ñåìèíàðîâ ïî âûáðàííîé Âàìè òåìàòèêå ó Âàñ â îôèñå. Äëÿ ó÷àñòèÿ â ñåìèíàðå íåîáõîäèìî çàðåãèñòðèðîâàòüñÿ ïî íàøèì òåëåôîíàì è ïîäòâåðäèòü ñâîå ó÷àñòèå îïëàòîé (044) 494 46 58, E-mail: csc_seminar@cscorp.com.ua Ìû ïðèíîñèì ñâîè èçâèíåíèÿ, åñëè ïîäîáíàÿ ðàññûëêà Âàì íå èíòåðåñíà. Óäàëèòü ñâîé àäðåñ èç ñïèñêà ïîäïèñ÷èêîâ Âû ìîæåòå, îòîñëàâ ïèñüìî ïî àäðåñó unsubscribe_sem@cscorp.com.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 14:30:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 626B137B405; Tue, 11 Dec 2001 14:30:37 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 8C2B2786E6; Wed, 12 Dec 2001 09:00:34 +1030 (CST) Date: Wed, 12 Dec 2001 09:00:34 +1030 From: Greg Lehey To: Wilko Bulte Cc: Matthew Dillon , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011212090034.C67986@monorchid.lemis.com> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211153437.A69755@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011211153437.A69755@freebie.xs4all.nl> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote: > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: >> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: >>> >>>>> performance without it - for reading OR writing. It doesn't matter >>>>> so much for RAID{1,10}, but it matters a whole lot for something like >>>>> RAID-5 where the difference between a spindle-synced read or write >>>>> and a non-spindle-synched read or write can be upwards of 35%. >>>> >>>> If you have RAID5 with I/O sizes that result in full-stripe operations. >>> >>> Well, 'more then one disk' operations anyway, for random-I/O. Caching >>> takes care of sequential I/O reasonably well but random-I/O goes down >>> the drain for writes if you aren't spindle synced, no matter what >>> the stripe size, >> >> Can you explain this? I don't see it. In FreeBSD, just about all I/O >> goes to buffer cache. >> >>> and will go down the drain for reads if you cross a stripe - >>> something that is quite common I think. >> >> I think this is what Mike was referring to when talking about parity >> calculation. In any case, going across a stripe boundary is not a >> good idea, though of course it can't be avoided. That's one of the >> arguments for large stripes. > > In a former life I was involved with a HB striping product for SysVr2 > that had a slightly modified filesystem that 'knew' when it was > working on a striped disk. And as it know, it avoided posting I/O s > that crossed stripes. So what did it do with user requests which crossed stripes? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 14:37:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id 950B837B427 for ; Tue, 11 Dec 2001 14:36:44 -0800 (PST) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.11.4/8.11.4) id fBBMag997272; Tue, 11 Dec 2001 14:36:42 -0800 (PST) (envelope-from sgk) Date: Tue, 11 Dec 2001 14:36:42 -0800 From: Steve Kargl To: Joerg Wunsch Cc: freebsd-current@FreeBSD.ORG, Hiten Pandya Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <20011211143642.A96859@troutmask.apl.washington.edu> References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <200112112127.fBBLRsr09655@uriah.heep.sax.de> <20011211140740.A96338@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211140740.A96338@troutmask.apl.washington.edu>; from sgk@troutmask.apl.washington.edu on Tue, Dec 11, 2001 at 02:07:40PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 11, 2001 at 02:07:40PM -0800, Steve Kargl wrote: > On Tue, Dec 11, 2001 at 10:27:54PM +0100, Joerg Wunsch wrote: > > Hiten Pandya wrote: > > > > > i wanted to ask if there were any _plans_ to port > > > JFS (Journaled File System) to FreeBSD... > > > > As long as nobody gets the idea to import VxFS... It's dog slow > > compared to UFS+softupdates. :-) Dog slow even compared to > > [This is directed at Joerg, but I deleted the original email. ^ not > URL is wrapped with a \.] > > http://www.usenix.org/publications/library/proceedings/usenix2000/general\ > /full_papers/seltzer/seltzer_html/index.html > > -- > Steve > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 14:42: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id ABE9D37B405; Tue, 11 Dec 2001 14:41:57 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id fBBMfqO72106; Tue, 11 Dec 2001 23:41:52 +0100 (CET) (envelope-from wkb) Date: Tue, 11 Dec 2001 23:41:51 +0100 From: Wilko Bulte To: Greg Lehey Cc: Matthew Dillon , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011211234151.A72046@freebie.xs4all.nl> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211153437.A69755@freebie.xs4all.nl> <20011212090034.C67986@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011212090034.C67986@monorchid.lemis.com>; from grog@FreeBSD.org on Wed, Dec 12, 2001 at 09:00:34AM +1030 X-OS: FreeBSD 4.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Dec 12, 2001 at 09:00:34AM +1030, Greg Lehey wrote: > On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote: > > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > >> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > >>> .. > >>> and will go down the drain for reads if you cross a stripe - > >>> something that is quite common I think. > >> > >> I think this is what Mike was referring to when talking about parity > >> calculation. In any case, going across a stripe boundary is not a > >> good idea, though of course it can't be avoided. That's one of the > >> arguments for large stripes. > > > > In a former life I was involved with a HB striping product for SysVr2 > > that had a slightly modified filesystem that 'knew' when it was > > working on a striped disk. And as it know, it avoided posting I/O s > > that crossed stripes. > > So what did it do with user requests which crossed stripes? Memory is dim, but I think the fs code created a second i/o to the driver layer. So the fs never sent out an i/o that the driver layer had to break up. In case of a pre-fetch while reading I think the f/s would just pre-fetch until the stripe border and not bother sending out a second i/o down. In the end all of this benchmarked quite favorably. Note that this was 386/486 era, with the classic SysV filesystem. -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 15: 2:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 879B737B41B for ; Tue, 11 Dec 2001 15:02:23 -0800 (PST) Received: (qmail 17807 invoked from network); 11 Dec 2001 23:02:21 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 11 Dec 2001 23:02:21 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011206201803.Q14784-100000@gamplex.bde.org> Date: Tue, 11 Dec 2001 15:02:16 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: Patch Review: i386 asm cleanups in the kernel Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 06-Dec-01 Bruce Evans wrote: > That gives a hint about where to look for the clobbering conventions. From > gcc/config/i386/i386.c: > > ! /* Set the cc_status for the results of an insn whose pattern is EXP. > ! On the 80386, we assume that only test and compare insns, as well > ! as SI, HI, & DI mode ADD, SUB, NEG, AND, IOR, XOR, BSF, ASHIFT, > ! ASHIFTRT, and LSHIFTRT instructions set the condition codes usefully. > ! Also, we assume that jumps, moves and sCOND don't affect the condition > ! codes. All else clobbers the condition codes, by assumption. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ! > ! We assume that ALL integer add, minus, etc. instructions effect the > ! condition codes. This MUST be consistent with i386.md. > ! > ! We don't record any float test or compare - the redundant test & > ! compare check in final.c does not handle stack-like regs correctly. */ > ! > ! void > ! notice_update_cc (exp) > ! rtx exp; > > Application asms are apparently in the "All else" set. Ok, I've axed all the "cc" clobbers from the patch now. Any objections to it now? It's still at ~jhb/patches/i386_asm.patch. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 15:20:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id B3D4437B419; Tue, 11 Dec 2001 15:20:07 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011211232006.XSLH4213.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 11 Dec 2001 23:20:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA06696; Tue, 11 Dec 2001 15:01:51 -0800 (PST) Date: Tue, 11 Dec 2001 15:01:50 -0800 (PST) From: Julian Elischer To: Kaltashkin Eugene Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, freebsd-question@FreeBSD.ORG Subject: Re: NCP Broken ? In-Reply-To: <20011210120131.33ce1f7a.zhecka@klondike.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Dec 2001, Kaltashkin Eugene wrote: > On Fri, 7 Dec 2001 10:55:03 -0800 (PST) > Julian Elischer wrote: > > JE: yes ncp and nwfs are broken in -current > > Hm, and when this be work ? when someone who understands the protocol can get time to retrofit teh KSE changes into it.. > > > -- > Best Regards > Kaltashkin Eugene > ZHECKA-RIPN > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 16:53:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from smluc.org (smluc.org [206.138.44.17]) by hub.freebsd.org (Postfix) with ESMTP id 292E237B416 for ; Tue, 11 Dec 2001 16:53:47 -0800 (PST) Received: from lazarus.smluc.org (erik@lazarus.smluc.org [206.138.44.17]) by smluc.org (8.9.3/8.9.3) with ESMTP id OAA27571 for ; Tue, 11 Dec 2001 14:16:22 -0600 Date: Tue, 11 Dec 2001 14:16:21 -0600 (EST) From: Erik Greenwald To: freebsd-current@freebsd.org Subject: noise in audio Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, not sure quite how to do a bug report on this, and didn't see any bug reports that matched, so I thought I'd throw it to the list to see... Audio output on my compile of current has noise in the audio stream, it's usually very regular... an mp3 pops at a little more than 1hz, a wav is too fast to guess on, almost a buzz. 'sync' and other utils that force disk io make a nasty beep noise, I'm guessing the popping is a very short occurance of that. Compiling puts some ugly noises out through it. 4.4 didn't do it, and I'm dual booting with linux and that doesn't do it, so I don't believe it's strictly hardware. I've posted my kernel config, uname, and dmesg at http://www.smluc.org/~erik/fbsd/ I'm willing to work on this, but I don't want to duplicate effort or spend too long fighting it if it's a stupid config mistake or something :) -Erik [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 18:34:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from hotmail.com (f43.law9.hotmail.com [64.4.9.43]) by hub.freebsd.org (Postfix) with ESMTP id 9C28E37B405 for ; Tue, 11 Dec 2001 18:34:51 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 Dec 2001 18:34:51 -0800 Received: from 202.98.16.2 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 12 Dec 2001 02:34:51 GMT X-Originating-IP: [202.98.16.2] From: "Liu Siwei" To: current@freebsd.org Subject: Hi,All Date: Wed, 12 Dec 2001 02:34:51 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Dec 2001 02:34:51.0338 (UTC) FILETIME=[93332AA0:01C182B5] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi,All: I love FreeBSD! But.. Can it support CD-RW disc and Simplie Chinese Filename? A lot of files in CD-ROM that have Chinese name, how can i open it under FreeBSD? Oh...Oh.... Best Regard. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 18:41:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id C6B9137B405; Tue, 11 Dec 2001 18:41:32 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 46A9A786E3; Wed, 12 Dec 2001 13:11:25 +1030 (CST) Date: Wed, 12 Dec 2001 13:11:25 +1030 From: Greg Lehey To: Terry Lambert , Hiten Pandya Cc: Alfred Perlstein , hackers@FreeBSD.org, Peter Wemm , current@FreeBSD.ORG Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <20011212131125.A82733@monorchid.lemis.com> References: <3C1613AD.53C45B3@mindspring.com> <20011211102645.46795.qmail@web21110.mail.yahoo.com> <20011211093550.D4BF638CC@overcee.netplex.com.au> <20011211102645.46795.qmail@web21110.mail.yahoo.com> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <3C15AC5A.44BFD2BD@mindspring.com> <20011211183001.B67986@monorchid.lemis.com> <3C15CD07.6D5FC2E7@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C1613AD.53C45B3@mindspring.com> <20011211102645.46795.qmail@web21110.mail.yahoo.com> <3C15CD07.6D5FC2E7@mindspring.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 11 December 2001 at 1:08:23 -0800, Terry Lambert wrote: > Greg Lehey wrote: >>> FS porting to FreeBSD is actually pretty trivial(*), though some >>> transactioning changes to the FreeBSD VFS layer consumers (the >>> system calls and NFS server code) would be necessary to make >>> the journal roll-back function correctly, following a failure. >>> >>> (*) Trivial: meaning grunt work is required; not necessarily an >>> indicator of the amount of work, only the intellectual effort >>> required for the job >> >> Considering that the current UFS implementation didn't need to be >> ported, and people are still working on the details, I think that this >> is a highly misleading statement. > > The current UFS has a number of issues which make it non-trivial; > it was, in effect, a port; here is the short list: > > > > Live code always has issues, particularly if you are trying to > pound a round peg into a square hole (hence Kirk taking up the > task of a redesign). Of course. But you're missing the point: ufs is *not* a port, it has been with BSD since the beginning. There is a similar list of items for JFS which would need to be addressed, with the additional issue of the fact that it was not designed for FreeBSD. > I think that everyone saying "Ut oh! SCARY!" gives people the wrong > idea, and scares off potential contributors in these areas. I'm not saying that. I'm saying that it's non-trivial, which I suppose is what you mean when you say "where are the patches?". As I said, I'm quite happy to help people port JFS2 to FreeBSD. On Tuesday, 11 December 2001 at 2:26:45 -0800, Hiten Pandya wrote: >> [... Hiten want's to GPL'ify FreeBSD ...] > > hi, > first of all, i would like to clear of some point which have been > taken wrongly. > > o My Intentions were never to GPL'ify FreeBSD :-) Agreed, I don't think anybody thought that. > o The reason i started this discussion was because > i think JFS/JFS2 would be a nice addition to > FreeBSD like the rest of the other filesystems. > > o The JFS does _not_ have to be root, and even if > people were to download it because it is GPL'ed, > the size of the filesystem is only around 1.0MB If we port JFS2, it will be relatively trivial to have it as the root file system too. > o It is hard to Port AIX or OS/2 based code, but we > have to agree that, BSD Users were meant to take > that kind of challenges, have taken before It's probably easier to port AIX based code than OS/2 or Linux based code. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 19:42:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 5EE5237B41C; Tue, 11 Dec 2001 19:42:26 -0800 (PST) Received: from pool0608.cvx22-bradley.dialup.earthlink.net ([209.179.200.98] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16E0Ho-00024G-00; Tue, 11 Dec 2001 19:42:24 -0800 Message-ID: <3C16D226.F169C43D@mindspring.com> Date: Tue, 11 Dec 2001 19:42:30 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: Hiten Pandya , Alfred Perlstein , hackers@FreeBSD.org, Peter Wemm , current@FreeBSD.ORG Subject: Re: [SUGGESTION] - JFS for FreeBSD References: <3C1613AD.53C45B3@mindspring.com> <20011211102645.46795.qmail@web21110.mail.yahoo.com> <20011211093550.D4BF638CC@overcee.netplex.com.au> <20011211102645.46795.qmail@web21110.mail.yahoo.com> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <3C15AC5A.44BFD2BD@mindspring.com> <20011211183001.B67986@monorchid.lemis.com> <3C15CD07.6D5FC2E7@mindspring.com> <20011212131125.A82733@monorchid.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg Lehey wrote: > Of course. But you're missing the point: ufs is *not* a port, it has > been with BSD since the beginning. There is a similar list of items > for JFS which would need to be addressed, with the additional issue of > the fact that it was not designed for FreeBSD. I maintain that the FreeBSD UFS *is* a port of the Heidemann implementation from the FICUS project, which had to be done because certain files were claimed to be "contaminated" with USL IP, and were removed as part of the USL/UCB settlement (6 key files from 5 subsystems, which they thought we couldn't rewrite from scratch in time to be a competitive threat). I also maintain that the most difficult thing is getting the list of items, and, with the information from the UFS work in hand, the JFS specific items not on that list are trivial (there are exactly two items, in fact: log roll forward/backward, and transaction abort). > > I think that everyone saying "Ut oh! SCARY!" gives people the wrong > > idea, and scares off potential contributors in these areas. > > I'm not saying that. I'm saying that it's non-trivial, which I > suppose is what you mean when you say "where are the patches?". As I > said, I'm quite happy to help people port JFS2 to FreeBSD. I ported the entire GFS user space tools set, sans two, to FreeBSD in about 2 hours. If FreeBSD had the necessary hardware drivers for shared disks, I would have finished the two that I didn't do, and then I would have gone to Frys, bought the necessary controllers, disk, and two scratch boxes, and finished porting the whole damn thing. I think I could have it all up and running in about 4 weeks, assuming the Linux implementation actually works for more than one machine, and my test machines were configured dual boot for Linux/FreeBSD. Unlike IBM, the GFS people have indicated a willingness to bend on the license issue. When I say "trivial", I mean "trivial", as the term is used in physics or mathematics: a well understood operation that can be performed rote, and does not require significant original thinking to perform. When I say "where are the patches?" I mean "that's an incredibly stupid idea, given the license, and you aren't going to get me to do that work without paying me, so you might as well send patches -- do the work yourself -- because you are going to have a hell of a time getting buy-in from anyone clued enough to do the work for you". > If we port JFS2, it will be relatively trivial to have it as the root > file system too. Only, you will never be able to build a firewall, router, or other product that ships with it statically linked into the kernel, since that would violate the terms of the GPL (additional restrictions, and linked code not being GPL'ed). What good is the damn thing, if the only people who can use it are big site admins who build their own kernels, and never expect to sell their company to anyone (or are prepared to recompile all the kernels on all their machines, should the company ever sell, since they can't transfer ownership of a FreeBSD kernel with GPL'ed code in it directly, without violating the license)? RMS has indicated a willingness to sue people distributing bipartite distributions, where the linking is delayed until installation to work around the letter of the GPL. Given his religious convictions, I can't see him *not*. Factor that into your decision. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 21: 2:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6663637B405 for ; Tue, 11 Dec 2001 21:02:34 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBC52Xa83757; Tue, 11 Dec 2001 22:02:33 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBC52VM32978; Tue, 11 Dec 2001 22:02:32 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112120502.fBC52VM32978@harmony.village.org> To: "Pierre Y. Dampure" Subject: Re: dhclient busted for -current? Cc: jparker@emunix.emich.edu, current@FreeBSD.ORG In-reply-to: Your message of "Sat, 08 Dec 2001 18:10:44 GMT." <20011208181044.566a0ebf.Pierre.Dampure@westmarsh.com> References: <20011208181044.566a0ebf.Pierre.Dampure@westmarsh.com> <200112080216.fB82GhM02156@harmony.village.org> <20011208020722.A15023@emunix.emich.edu> Date: Tue, 11 Dec 2001 22:02:31 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011208181044.566a0ebf.Pierre.Dampure@westmarsh.com> "Pierre Y. Dampure" writes: : Are you asking for specific options (my dhclient.conf is empty)? are you using a reservation? I'm 100% sure it worked before the upgrade. :-(. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 21:52:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 293D137B405; Tue, 11 Dec 2001 21:52:13 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 2EAFD786E8; Wed, 12 Dec 2001 16:22:05 +1030 (CST) Date: Wed, 12 Dec 2001 16:22:05 +1030 From: Greg Lehey To: Bernd Walter Cc: Matthew Dillon , Wilko Bulte , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)) Message-ID: <20011212162205.I82733@monorchid.lemis.com> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211031120.G11774@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20011211031120.G11774@cicely8.cicely.de> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: >> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: >>> >>>>> performance without it - for reading OR writing. It doesn't matter >>>>> so much for RAID{1,10}, but it matters a whole lot for something like >>>>> RAID-5 where the difference between a spindle-synced read or write >>>>> and a non-spindle-synched read or write can be upwards of 35%. >>>> >>>> If you have RAID5 with I/O sizes that result in full-stripe operations. >>> >>> Well, 'more then one disk' operations anyway, for random-I/O. Caching >>> takes care of sequential I/O reasonably well but random-I/O goes down >>> the drain for writes if you aren't spindle synced, no matter what >>> the stripe size, >> >> Can you explain this? I don't see it. In FreeBSD, just about all I/O >> goes to buffer cache. > > After waiting for the drives and not for vinum parity blocks. > >>> and will go down the drain for reads if you cross a stripe - >>> something that is quite common I think. >> >> I think this is what Mike was referring to when talking about parity >> calculation. In any case, going across a stripe boundary is not a >> good idea, though of course it can't be avoided. That's one of the >> arguments for large stripes. > > striped: > If you have 512byte stripes and have 2 disks. > You access 64k which is put into 2 32k transactions onto the disk. Only if your software optimizes the transfers. There are reasons why it should not. Without optimization, you get 128 individual transfers. > The wait time for the complete transaction is the worst of both, > which is more than the average of a single disk. Agreed. > With spindle syncronisation the access time for both disks are > beleaved to be identic and you get the same as with a single disk. Correct. > Linear speed could be about twice the speed of a single drive. But > this is more theoretic today than real. The average transaction > size per disk decreases with growing number of spindles and you get > more transaction overhead. Also the voice coil technology used in > drives since many years add a random amount of time to the access > time, which invalidates some of the spindle sync potential. Plus it > may break some benefits of precaching mechanisms in drives. I'm > almost shure there is no real performance gain with modern drives. The real problem with this scenario is that you're missing a couple of points: 1. Typically it's not the latency that matters. If you have to wait a few ms longer, that's not important. What's interesting is the case of a heavily loaded system, where the throughput is much more important than the latency. 2. Throughput is the data transferred per unit time. There's active transfer time, nowadays in the order of 500 µs, and positioning time, in the order of 6 ms. Clearly the fewer positioning operations, the better. This means that you should want to put most transfers on a single spindle, not a single stripe. To do this, you need big stripes. > raid5: > For a write you have two read transactions and two writes. This is the way Vinum does it. There are other possibilities: 1. Always do full-stripe writes. Then you don't need to read the old contents. 2. Cache the parity blocks. This is an optimization which I think would be very valuable, but which Vinum doesn't currently perform. > There are easier things to raise performance. > Ever wondered why people claim vinums raid5 writes are slow? > The answer is astonishing simple: > Vinum does striped based locking, while the ufs tries to lay out data > mostly ascending sectors. > What happens here is that the first write has to wait for two reads > and two writes. > If we have an ascending write it has to wait for the first write to > finish, because the stripe is still locked. > The first is unlocked after both physical writes are on disk. > Now we start our two reads which are (thanks to drives precache) > most likely in the drives cache - than we write. > > The problem here is that physical writes gets serialized and the drive > has to wait a complete rotation between each. Not if the data is in the drive cache. > If we had a fine grained locking which only locks the accessed sectors > in the parity we would be able to have more than a single ascending > write transaction onto a single drive. Hmm. This is something I hadn't thought about. Note that sequential writes to a RAID-5 volume don't go to sequential addresses on the spindles; they will work up to the end of the stripe on one spindle, then start on the next spindle at the start of the stripe. You can do that as long as the address ranges in the parity block don't overlap, but the larger the stripe, the greater the likelihood of this would be. This might also explain the following observed behaviour: 1. RAID-5 writes slow down when the stripe size gets > 256 kB or so. I don't know if this happens on all disks, but I've seen it often enough. 2. rawio write performance is better than ufs write performance. rawio does "truly" random transfers, where ufs is a mixture. Do you feel like changing the locking code? It shouldn't be that much work, and I'd be interested to see how much performance difference it makes. Note that there's another possible optimization here: delay the writes by a certain period of time and coalesce them if possible. I haven't finished thinking about the implications. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 21:53:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 3584337B417; Tue, 11 Dec 2001 21:53:11 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 6BC1D786E6; Wed, 12 Dec 2001 16:23:09 +1030 (CST) Date: Wed, 12 Dec 2001 16:23:09 +1030 From: Greg Lehey To: Wilko Bulte Cc: Matthew Dillon , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011212162309.J82733@monorchid.lemis.com> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211153437.A69755@freebie.xs4all.nl> <20011212090034.C67986@monorchid.lemis.com> <20011211234151.A72046@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011211234151.A72046@freebie.xs4all.nl> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 11 December 2001 at 23:41:51 +0100, Wilko Bulte wrote: > On Wed, Dec 12, 2001 at 09:00:34AM +1030, Greg Lehey wrote: >> On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote: >>> On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: >>>> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: >>>>> > > .. > >>>>> and will go down the drain for reads if you cross a stripe - >>>>> something that is quite common I think. >>>> >>>> I think this is what Mike was referring to when talking about parity >>>> calculation. In any case, going across a stripe boundary is not a >>>> good idea, though of course it can't be avoided. That's one of the >>>> arguments for large stripes. >>> >>> In a former life I was involved with a HB striping product for SysVr2 >>> that had a slightly modified filesystem that 'knew' when it was >>> working on a striped disk. And as it know, it avoided posting I/O s >>> that crossed stripes. >> >> So what did it do with user requests which crossed stripes? > > Memory is dim, but I think the fs code created a second i/o to the > driver layer. So the fs never sent out an i/o that the driver layer had > to break up. That's what Vinum does. > In case of a pre-fetch while reading I think the f/s would just > pre-fetch until the stripe border and not bother sending out a > second i/o down. Yes, that's reasonable. > In the end all of this benchmarked quite favorably. Note that this > was 386/486 era, with the classic SysV filesystem. I don't think that UFS would behave that differently, just faster :-) Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 21:58:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from hotmail.com (f240.law8.hotmail.com [216.33.241.240]) by hub.freebsd.org (Postfix) with ESMTP id 229C737B41C; Tue, 11 Dec 2001 21:58:38 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 Dec 2001 21:58:37 -0800 Received: from 209.52.193.196 by lw8fd.law8.hotmail.msn.com with HTTP; Wed, 12 Dec 2001 05:58:37 GMT X-Originating-IP: [209.52.193.196] From: "Craig R" To: hackers@freebsd.org, current@freebsd.org Subject: Re: [SUGGESTION] - JFS for FreeBSD Date: Tue, 11 Dec 2001 21:58:37 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Dec 2001 05:58:37.0977 (UTC) FILETIME=[0AD83890:01C182D2] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think I would rather see people tweaking the heck out of the existing UFS filesystem and implementing new ways of getting it to go faster. Implementing a whole new filesystem would probably take a lot of work, and the performance wouldn't be much better anyways. IMHO, people interested in making a filesystem faster should stick with UFS. FreeBSD should not do what Linux does, which is make a whole bunch of different filesystems that all suck in a different way. This is an opinion and should be taken as such, not an insult to those that like the whole JFS idea. -Craig _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Dec 11 22:50:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 912DF37B416; Tue, 11 Dec 2001 22:50:23 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id DD78B786E6; Wed, 12 Dec 2001 17:20:21 +1030 (CST) Date: Wed, 12 Dec 2001 17:20:21 +1030 From: Greg Lehey To: Terry Lambert Cc: Hiten Pandya , Alfred Perlstein , hackers@FreeBSD.org, Peter Wemm , current@FreeBSD.ORG Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <20011212172021.L82733@monorchid.lemis.com> References: <20011211093550.D4BF638CC@overcee.netplex.com.au> <20011211102645.46795.qmail@web21110.mail.yahoo.com> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <3C15AC5A.44BFD2BD@mindspring.com> <20011211183001.B67986@monorchid.lemis.com> <3C15CD07.6D5FC2E7@mindspring.com> <20011212131125.A82733@monorchid.lemis.com> <3C16D226.F169C43D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C16D226.F169C43D@mindspring.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 11 December 2001 at 19:42:30 -0800, Terry Lambert wrote: > Greg Lehey wrote: >> Of course. But you're missing the point: ufs is *not* a port, it has >> been with BSD since the beginning. There is a similar list of items >> for JFS which would need to be addressed, with the additional issue of >> the fact that it was not designed for FreeBSD. > > I maintain that the FreeBSD UFS *is* a port of the Heidemann > implementation from the FICUS project, which had to be done because > certain files were claimed to be "contaminated" with USL IP, and > were removed as part of the USL/UCB settlement (6 key files from 5 > subsystems, which they thought we couldn't rewrite from scratch in > time to be a competitive threat). Which files? Did they require adapting to a different environment? > I also maintain that the most difficult thing is getting the list of > items, and, with the information from the UFS work in hand, the JFS > specific items not on that list are trivial (there are exactly two > items, in fact: log roll forward/backward, and transaction abort). I'd expect these to be the easiest parts, since they don't have too much to do with the rest of the system. One of the issues with Linux is that the interface to the rest of the system, and I don't expect these parts to have much interfacing to do. >>> I think that everyone saying "Ut oh! SCARY!" gives people the wrong >>> idea, and scares off potential contributors in these areas. >> >> I'm not saying that. I'm saying that it's non-trivial, which I >> suppose is what you mean when you say "where are the patches?". As I >> said, I'm quite happy to help people port JFS2 to FreeBSD. > > I ported the entire GFS user space tools set, sans two, to FreeBSD in > about 2 hours. I expect the user space tools for JFS2 to be pretty straightforward too. >> If we port JFS2, it will be relatively trivial to have it as the root >> file system too. > > Only, you will never be able to build a firewall, router, or other > product that ships with it statically linked into the kernel, since > that would violate the terms of the GPL (additional restrictions, > and linked code not being GPL'ed). Fine, so we load the module. What's your point? > What good is the damn thing, if the only people who can use it are > ... Well, I suppose it'll still be good for them. Maybe. > RMS has indicated a willingness to sue people distributing bipartite > distributions, where the linking is delayed until installation to > work around the letter of the GPL. Given his religious convictions, > I can't see him *not*. Factor that into your decision. You want me personally to get him to agree that loading modules at boot time does not violate the GPL? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 0: 1:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id 8877F37B416 for ; Wed, 12 Dec 2001 00:01:39 -0800 (PST) Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id KAA77294; Wed, 12 Dec 2001 10:01:23 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (h156.228.dialup.iptcom.net [212.9.228.156]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id KAA10738; Wed, 12 Dec 2001 10:01:22 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id fBC80pF22304; Wed, 12 Dec 2001 10:00:51 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3C170F56.435FA023@FreeBSD.org> Date: Wed, 12 Dec 2001 10:03:34 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Liu Siwei Cc: current@FreeBSD.org Subject: Re: Hi,All References: Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Liu Siwei wrote: > > Hi,All: > I love FreeBSD! But.. Can it support CD-RW disc and Simplie Chinese > Filename? A lot of files in CD-ROM that have Chinese name, how can i open it > under FreeBSD? Oh...Oh.... What is the official name for Simplie Chinese codepage? If it is a 1-byte charset, then I could probably add support for it into cd9660_unicode ports, which would allow accessing files with such filenames on them. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 0:12: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 8E4E237B41B for ; Wed, 12 Dec 2001 00:11:54 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBC8Af715217; Wed, 12 Dec 2001 10:10:41 +0200 (EET) (envelope-from ru) Date: Wed, 12 Dec 2001 10:10:41 +0200 From: Ruslan Ermilov To: "Jackie 'business-first' Cook" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Motion for removal of xargs(1) from base system Message-ID: <20011212101041.E11552@sunbay.com> References: <20011210221335.ACEB137B405@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011210221335.ACEB137B405@hub.freebsd.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 10, 2001 at 02:13:35PM -0800, Jackie 'business-first' Cook wrote: > There are days when people get tired with the lagacy code in the system - when > things of the past just have to go. Recently I got sick and tired with one of > those things. The command is, as you could have guessed from the subject, > xags(1) aka /usr/bin/xargs. It is buggy and cluttered piece of code. Faulty and > hard to use command. It's idiosyncratic syntax makes people dizzy everytime they > use/or just try to use it. > It's also a part of just ratified POSIX.1-2001 standard. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 0:27:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from white.imgsrc.co.jp (ns.imgsrc.co.jp [210.226.20.2]) by hub.freebsd.org (Postfix) with ESMTP id AA89E37B405 for ; Wed, 12 Dec 2001 00:27:33 -0800 (PST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [2001:218:422:2:290:27ff:fe98:c0b7]) by white.imgsrc.co.jp (Postfix) with ESMTP id A23C924D22 for ; Wed, 12 Dec 2001 17:27:32 +0900 (JST) Received: from waterblue.imgsrc.co.jp (waterblue.imgsrc.co.jp [2001:218:422:2:230:48ff:fe41:161b]) by black.imgsrc.co.jp (Postfix) with ESMTP id 1B322D1401 for ; Wed, 12 Dec 2001 17:27:31 +0900 (JST) Date: Wed, 12 Dec 2001 17:27:32 +0900 Message-ID: <7my9k8derv.wl@waterblue.imgsrc.co.jp> From: Jun Kuriyama To: Current Subject: XF86 with agp.ko and mga.ko User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm using XFree86-Server-4.1.0_2 and drm-kmod-0.9.4 with ----- module_path="/;/boot;/modules;/usr/local/lib/drm" agp_load="YES" mga_load="YES" linux_load="YES" ----- lines in /boot/loader.conf. World at 2001/12/10 is fine for me, but after installworld'ing of today's world (2001/12/12) my X server is slowed down. My kernel shows too many lines to console like this: ----- Dec 12 17:06:03 waterblue kernel: error: [drm:mga_dma_flush] *ERROR* mga_dma_flush called without lock held Dec 12 17:06:03 waterblue kernel: error: [drm:mga_dma_reset] *ERROR* mga_dma_reset called without lock held ----- I re-installed XFree86-Server and drm-kmod but X is still really slow. I'm using X without mga.ko (this shows reasonable speed). Does anyone know any hints about this? -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 2:30:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from theinternet.com.au (c20631.kelvn1.qld.optusnet.com.au [203.164.207.8]) by hub.freebsd.org (Postfix) with ESMTP id 6E3BA37B416 for ; Wed, 12 Dec 2001 02:30:24 -0800 (PST) Received: (from akm@localhost) by theinternet.com.au (8.11.6/8.11.4) id fBCAUHp76347 for current@freebsd.org; Wed, 12 Dec 2001 20:30:17 +1000 (EST) (envelope-from akm) Date: Wed, 12 Dec 2001 20:30:17 +1000 From: Andrew Kenneth Milton To: current@freebsd.org Subject: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD Message-ID: <20011212203016.O46324@zeus.theinternet.com.au> References: <20011211093550.D4BF638CC@overcee.netplex.com.au> <20011211102645.46795.qmail@web21110.mail.yahoo.com> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <3C15AC5A.44BFD2BD@mindspring.com> <20011211183001.B67986@monorchid.lemis.com> <3C15CD07.6D5FC2E7@mindspring.com> <20011212131125.A82733@monorchid.lemis.com> <3C16D226.F169C43D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <3C16D226.F169C43D@mindspring.com>; from Terry Lambert on Tue, Dec 11, 2001 at 07:42:30PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG +-------[ Terry Lambert ]---------------------- | | RMS has indicated a willingness to sue people distributing bipartite | distributions, where the linking is delayed until installation to | work around the letter of the GPL. Given his religious convictions, | I can't see him *not*. Factor that into your decision. Just to balance this point out; Only the copyright holder can do this, what code of any significance has RMS contributed recently to this or any other project where this would be a consideration? Not everyone has the religious conviction of RMS. In 1983 RMS promised a kernel for GNU too, it hasn't arrived yet. He talks a lot. Remeber to factor that into your decisions d8) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 2:32:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1E32E37B419 for ; Wed, 12 Dec 2001 02:32:12 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBCAUTj52755; Wed, 12 Dec 2001 11:30:30 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Andrew Kenneth Milton Cc: current@FreeBSD.ORG Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD In-Reply-To: Your message of "Wed, 12 Dec 2001 20:30:17 +1000." <20011212203016.O46324@zeus.theinternet.com.au> Date: Wed, 12 Dec 2001 11:30:29 +0100 Message-ID: <52753.1008153029@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011212203016.O46324@zeus.theinternet.com.au>, Andrew Kenneth Milt on writes: >+-------[ Terry Lambert ]---------------------- >| >| RMS has indicated a willingness to sue people distributing bipartite >| distributions, where the linking is delayed until installation to >| work around the letter of the GPL. Given his religious convictions, >| I can't see him *not*. Factor that into your decision. > >Just to balance this point out; > >Only the copyright holder can do this, what code of any significance has >RMS contributed recently to this or any other project where this would be >a consideration? Uh, people have been signing their copyright over to FSF for a long time... -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 2:56: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from web21103.mail.yahoo.com (web21103.mail.yahoo.com [216.136.227.105]) by hub.freebsd.org (Postfix) with SMTP id 6E9CB37B405 for ; Wed, 12 Dec 2001 02:55:59 -0800 (PST) Message-ID: <20011212105559.19177.qmail@web21103.mail.yahoo.com> Received: from [62.254.0.5] by web21103.mail.yahoo.com via HTTP; Wed, 12 Dec 2001 02:55:59 PST Date: Wed, 12 Dec 2001 02:55:59 -0800 (PST) From: Hiten Pandya Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD To: Poul-Henning Kamp Cc: current@FreeBSD.org In-Reply-To: <52753.1008153029@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi, why would RMS sue, lets say me, for porting IBM's piece of GPL'ed code to FreeBSD src/gnu. What i will be doing (if the votes come out positive), will be exactly as how his law says... --- Poul-Henning Kamp wrote: > In message > <20011212203016.O46324@zeus.theinternet.com.au>, > Andrew Kenneth Milt > on writes: > >+-------[ Terry Lambert ]---------------------- > >| > >| RMS has indicated a willingness to sue people > distributing bipartite > >| distributions, where the linking is delayed until > installation to > >| work around the letter of the GPL. Given his > religious convictions, > >| I can't see him *not*. Factor that into your > decision. > > > >Just to balance this point out; > > > >Only the copyright holder can do this, what code of > any significance has > >RMS contributed recently to this or any other > project where this would be > >a consideration? > > Uh, people have been signing their copyright over to > FSF for a long > time... > > -- > 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. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of > the message ===== -Hiten, Thank You, Yours Sincerely, Hiten Pandya, __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 3:27: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 806A337B405 for ; Wed, 12 Dec 2001 03:26:56 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBCBQnU42672 for current@FreeBSD.org; Wed, 12 Dec 2001 13:26:49 +0200 (EET) (envelope-from ru) Date: Wed, 12 Dec 2001 13:26:49 +0200 From: Ruslan Ermilov To: current@FreeBSD.org Subject: pam_ssh support for static PAM library Message-ID: <20011212132649.D32012@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! There's a number of build problems exists with libssh, pam_ssh, and libpam triple. The major issue being that the static PAM library, libpam.a, doesn't currently support pam_ssh. There have been a semi-private discussion taking place between me and Mark Murray on the subject, and I've prepared a set of patches to address these issues. First approach proposed was to make libssh a "standard" FreeBSD library, in that sense that it has its name in bsd.libnames.mk namespace, and is installable under /usr/lib, and is available for dynamic linking. This approach was rejected, because libssh is believed to be of no common interest to be available under /usr/lib, in that sense when we call such a library "internal". The latest patch on the subject is believed to fix all these issues, while still preserving libssh from being visible under /usr/lib. I've already sent a notification to Mark, and he promised to look into my patch during the next week or so. For those also interested, I've put my patch and the detailed log here: http://people.FreeBSD.org/~ru/patches/libssh.patch http://people.FreeBSD.org/~ru/patches/libssh.patch.log In order to test it without a full "buildworld", you'll have to proceed in this order: 1. Install updated bsd.lib.mk and bsd.libnames.mk. 2. Build secure/lib/libssh. 3. Build and install lib/libpam. Now you're ready to build/install any PAMified stuff statically, and pam_ssh should be available. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 3:30:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 75C9837B405; Wed, 12 Dec 2001 03:30:33 -0800 (PST) Received: from pool0012.cvx22-bradley.dialup.earthlink.net ([209.179.198.12] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16E7ap-0001Dd-00; Wed, 12 Dec 2001 03:30:32 -0800 Message-ID: <3C173FDD.5CB96DE4@mindspring.com> Date: Wed, 12 Dec 2001 03:30:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: Liu Siwei , current@FreeBSD.org Subject: Re: Hi,All References: <3C170F56.435FA023@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > Liu Siwei wrote: > > I love FreeBSD! But.. Can it support CD-RW disc and Simplie Chinese > > Filename? A lot of files in CD-ROM that have Chinese name, how can i open it > > under FreeBSD? Oh...Oh.... > > What is the official name for Simplie Chinese codepage? If it is a > 1-byte charset, then I could probably add support for it into > cd9660_unicode ports, which would allow accessing files with such > filenames on them. The most common character sets for Chinese are: GB-2312 Simplified Chinese EUC-TW Traditional Chinese Big-5 Traditional Chinese The one in most common use is Big-5. Unicode supports Chinese through its CJK unification, and can have characters in it round-tripped into any of the above character set standards. All of these are multibyte character sets. Unfortunately, UTF-7 and UTF-8 tend to be used with Unicode, which destroys fixed field storage of data (since any character can take up to 5 bytes to store, depending on its code point, when UTF encoding is used). The answer to the original question is "it depends on how the Chinese character data is stored on the CDROM". If the storage is as multibyte, then decoding it is the job of the rendering engine. In other words, you leave it alone, and use a Chinese display program and input method for X Windows, and it will "just work". If the storage is as Unicode code points, then, since tty interfaces are currently single byte, then you would need to have a converter program between the FS and the directory code, to convert it to multibyte, so that when you list the directory, you get the multibyte values out, and that, in turn, is rendered by the Chinese capable multibyte program (xterm/etc.). Right now, FreeBSD does not convert to/from Unicode 2/4 byte encoding (Windows uses 2 byte encoding, as does Joliet, the Windows CDROM standard, which *is* supported by FreeBSD); it merely masks off the high byte of the two bytes, taking advantage of the fact that the first 256 bytes of Unicode is identical to ISO 8859-1 (Latin-1). You would need to be able to throw down round trip tables (probably via an ioctl() to load them) to the kernel (this is what Windows does). Note that because of the expansion requirements, it's possible to have 256 Unicode stored Chinese characters bloat to 1280 characters, which exceeds both the maximum file name component length (256) and path name length (1024) set by UNIX (and copied by FreeBSD). It's highly unlikely that anyone has encoded this type of data, but the possibility is there. Ignoring all that, you should be able to do a lookup from the Unicode table to to, say, Big-5, and back, with one 64K table in each direction, and EUC or otherwise multibyte encode the result before returning it via getdirentries(). This will break under Linux emulation (I believe), since it uses the directory lookup restart code, which will be variant under multibyte translation. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 3:42:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 3D46137B417 for ; Wed, 12 Dec 2001 03:42:13 -0800 (PST) Received: from pool0012.cvx22-bradley.dialup.earthlink.net ([209.179.198.12] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16E7ll-0006I2-00; Wed, 12 Dec 2001 03:41:50 -0800 Message-ID: <3C174284.8F0B3B7B@mindspring.com> Date: Wed, 12 Dec 2001 03:41:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Kenneth Milton Cc: current@freebsd.org Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD References: <20011211093550.D4BF638CC@overcee.netplex.com.au> <20011211102645.46795.qmail@web21110.mail.yahoo.com> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <3C15AC5A.44BFD2BD@mindspring.com> <20011211183001.B67986@monorchid.lemis.com> <3C15CD07.6D5FC2E7@mindspring.com> <20011212131125.A82733@monorchid.lemis.com> <3C16D226.F169C43D@mindspring.com> <20011212203016.O46324@zeus.theinternet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andrew Kenneth Milton wrote: > +-------[ Terry Lambert ]---------------------- > | RMS has indicated a willingness to sue people distributing bipartite > | distributions, where the linking is delayed until installation to > | work around the letter of the GPL. Given his religious convictions, > | I can't see him *not*. Factor that into your decision. > > Just to balance this point out; > > Only the copyright holder can do this, what code of any significance has > RMS contributed recently to this or any other project where this would be > a consideration? I can't argue with that; historically, IBM has never sued anyone, and they were oh so happy to consider another license for the year I tried to push for it for use in a FreeBSD based IBM product. Not. 8^p -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 3:44:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id C34EE37B405 for ; Wed, 12 Dec 2001 03:44:40 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBCBh5j53886 for ; Wed, 12 Dec 2001 12:43:05 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: buildworld broken on globaldata.h From: Poul-Henning Kamp Date: Wed, 12 Dec 2001 12:43:05 +0100 Message-ID: <53884.1008157385@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG My buildworld breaks: [...] /flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52: machine/globaldata.h: No such file or directory Any workarounds/fixes ? -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 3:56:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 8E12537B405; Wed, 12 Dec 2001 03:56:23 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fBCBuLR80911; Wed, 12 Dec 2001 12:56:21 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fBCBrstx013368; Wed, 12 Dec 2001 12:53:54 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fBCBrrW08162; Wed, 12 Dec 2001 12:53:53 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fBCBrcI18117; Wed, 12 Dec 2001 12:53:38 +0100 (CET) (envelope-from ticso) Date: Wed, 12 Dec 2001 12:53:37 +0100 From: Bernd Walter To: Greg Lehey Cc: Matthew Dillon , Wilko Bulte , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)) Message-ID: <20011212125337.D15654@cicely8.cicely.de> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211031120.G11774@cicely8.cicely.de> <20011212162205.I82733@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20011212162205.I82733@monorchid.lemis.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote: > On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: > > striped: > > If you have 512byte stripes and have 2 disks. > > You access 64k which is put into 2 32k transactions onto the disk. > > Only if your software optimizes the transfers. There are reasons why > it should not. Without optimization, you get 128 individual > transfers. If the software does not we end with 128 transactions anyway, which is not very good becuase of the overhead for each of them. UFS does a more or less good job in doing this. > > Linear speed could be about twice the speed of a single drive. But > > this is more theoretic today than real. The average transaction > > size per disk decreases with growing number of spindles and you get > > more transaction overhead. Also the voice coil technology used in > > drives since many years add a random amount of time to the access > > time, which invalidates some of the spindle sync potential. Plus it > > may break some benefits of precaching mechanisms in drives. I'm > > almost shure there is no real performance gain with modern drives. > > The real problem with this scenario is that you're missing a couple of > points: > > 1. Typically it's not the latency that matters. If you have to wait > a few ms longer, that's not important. What's interesting is the > case of a heavily loaded system, where the throughput is much more > important than the latency. Agreed - especially because we don't wait for writes as most are async. > 2. Throughput is the data transferred per unit time. There's active > transfer time, nowadays in the order of 500 µs, and positioning > time, in the order of 6 ms. Clearly the fewer positioning > operations, the better. This means that you should want to put > most transfers on a single spindle, not a single stripe. To do > this, you need big stripes. In the general case yes. > > raid5: > > For a write you have two read transactions and two writes. > > This is the way Vinum does it. There are other possibilities: > > 1. Always do full-stripe writes. Then you don't need to read the old > contents. Which isn't that good with the big stripes we usually want. > 2. Cache the parity blocks. This is an optimization which I think > would be very valuable, but which Vinum doesn't currently perform. I thought of connecting the parity to the wait lock. If there's a waiter for the same parity data it's not droped. This way we don't waste memory but still have an efect. > > There are easier things to raise performance. > > Ever wondered why people claim vinums raid5 writes are slow? > > The answer is astonishing simple: > > Vinum does striped based locking, while the ufs tries to lay out data > > mostly ascending sectors. > > What happens here is that the first write has to wait for two reads > > and two writes. > > If we have an ascending write it has to wait for the first write to > > finish, because the stripe is still locked. > > The first is unlocked after both physical writes are on disk. > > Now we start our two reads which are (thanks to drives precache) > > most likely in the drives cache - than we write. > > > > The problem here is that physical writes gets serialized and the drive > > has to wait a complete rotation between each. > > Not if the data is in the drive cache. This example was for writing. Reads get precached by the drive and have a very good chance of beeing in the cache. It doesn't matter on IDE disks, because if you have write cache enabled the write gets acked from the cache and not the media. If write cache is disabled writes gets serialized anyway. > > If we had a fine grained locking which only locks the accessed sectors > > in the parity we would be able to have more than a single ascending > > write transaction onto a single drive. > > Hmm. This is something I hadn't thought about. Note that sequential > writes to a RAID-5 volume don't go to sequential addresses on the > spindles; they will work up to the end of the stripe on one spindle, > then start on the next spindle at the start of the stripe. You can do > that as long as the address ranges in the parity block don't overlap, > but the larger the stripe, the greater the likelihood of this would > be. This might also explain the following observed behaviour: > > 1. RAID-5 writes slow down when the stripe size gets > 256 kB or so. > I don't know if this happens on all disks, but I've seen it often > enough. I would guess it when the stripe size is bigger than the preread cache the drives uses. This would mean we have a less chance to get parity data out of the drive cache. > 2. rawio write performance is better than ufs write performance. > rawio does "truly" random transfers, where ufs is a mixture. The current problem is to increase linear write performance. I don't see a chance that rawio benefit of it, but ufs will. > Do you feel like changing the locking code? It shouldn't be that much > work, and I'd be interested to see how much performance difference it > makes. I put it onto my todo list. > Note that there's another possible optimization here: delay the writes > by a certain period of time and coalesce them if possible. I haven't > finished thinking about the implications. That's exactly what the ufs clustering and softupdates does. If it doesn't fit modern drives anymore it should get tuned there. Whenever a write hits a driver there is a waiter for it. Either a softdep, a memory freeing or an application doing an sync transfer. I'm almost shure delaying writes will harm performance in upper layers. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 3:57:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from theinternet.com.au (c20631.kelvn1.qld.optusnet.com.au [203.164.207.8]) by hub.freebsd.org (Postfix) with ESMTP id 7A4F237B405 for ; Wed, 12 Dec 2001 03:57:06 -0800 (PST) Received: (from akm@localhost) by theinternet.com.au (8.11.6/8.11.4) id fBCBurt76513; Wed, 12 Dec 2001 21:56:53 +1000 (EST) (envelope-from akm) Date: Wed, 12 Dec 2001 21:56:53 +1000 From: Andrew Kenneth Milton To: Poul-Henning Kamp Cc: Andrew Kenneth Milton , current@FreeBSD.ORG Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD Message-ID: <20011212215653.P46324@zeus.theinternet.com.au> References: <20011212203016.O46324@zeus.theinternet.com.au> <52753.1008153029@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <52753.1008153029@critter.freebsd.dk>; from Poul-Henning Kamp on Wed, Dec 12, 2001 at 11:30:29AM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG +-------[ Poul-Henning Kamp ]---------------------- | In message <20011212203016.O46324@zeus.theinternet.com.au>, Andrew Kenneth Milt | on writes: | >+-------[ Terry Lambert ]---------------------- | >| | >| RMS has indicated a willingness to sue people distributing bipartite | >| distributions, where the linking is delayed until installation to | >| work around the letter of the GPL. Given his religious convictions, | >| I can't see him *not*. Factor that into your decision. | > | >Just to balance this point out; | > | >Only the copyright holder can do this, what code of any significance has | >RMS contributed recently to this or any other project where this would be | >a consideration? | | Uh, people have been signing their copyright over to FSF for a long | time... That still doesn't answer the question though. I'm pretty sure IBM didn't sign *their* copyright over to the FSF. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 4: 1:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from theinternet.com.au (c20631.kelvn1.qld.optusnet.com.au [203.164.207.8]) by hub.freebsd.org (Postfix) with ESMTP id 89F6537B417 for ; Wed, 12 Dec 2001 04:01:39 -0800 (PST) Received: (from akm@localhost) by theinternet.com.au (8.11.6/8.11.4) id fBCC1ZM76556; Wed, 12 Dec 2001 22:01:35 +1000 (EST) (envelope-from akm) Date: Wed, 12 Dec 2001 22:01:35 +1000 From: Andrew Kenneth Milton To: Terry Lambert Cc: Andrew Kenneth Milton , current@FreeBSD.ORG Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD Message-ID: <20011212220135.Q46324@zeus.theinternet.com.au> References: <20011211102645.46795.qmail@web21110.mail.yahoo.com> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <3C15AC5A.44BFD2BD@mindspring.com> <20011211183001.B67986@monorchid.lemis.com> <3C15CD07.6D5FC2E7@mindspring.com> <20011212131125.A82733@monorchid.lemis.com> <3C16D226.F169C43D@mindspring.com> <20011212203016.O46324@zeus.theinternet.com.au> <3C174284.8F0B3B7B@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <3C174284.8F0B3B7B@mindspring.com>; from Terry Lambert on Wed, Dec 12, 2001 at 03:41:56AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG +-------[ Terry Lambert ]---------------------- | | > Only the copyright holder can do this, what code of any significance has | > RMS contributed recently to this or any other project where this would be | > a consideration? | | I can't argue with that; historically, IBM has never sued anyone, and | they were oh so happy to consider another license for the year I tried | to push for it for use in a FreeBSD based IBM product. Not. Of course not, the GPL protects them from competitors taking and improving their product and selling it at a profit without having to share. Ironic isn't it, that the GPL has become a tool of the "oppressors" d8) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 4: 6:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id C81EB37B428 for ; Wed, 12 Dec 2001 04:06:06 -0800 (PST) Received: from pool0012.cvx22-bradley.dialup.earthlink.net ([209.179.198.12] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16E897-0002Dy-00; Wed, 12 Dec 2001 04:05:58 -0800 Message-ID: <3C17482C.3792DAA9@mindspring.com> Date: Wed, 12 Dec 2001 04:06:04 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hiten Pandya Cc: Poul-Henning Kamp , current@FreeBSD.org Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD References: <20011212105559.19177.qmail@web21103.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hiten Pandya wrote: > why would RMS sue, lets say me, for porting IBM's > piece of GPL'ed code to FreeBSD src/gnu. RMS wouldn't, not being directly involved. IBM might. I am a former IBM employee, of IBM GSB division (Global Small Business). I became an IBM employee when IBM bought Whistle Communications, Inc., which produced a SOHO connectivity product called the InterJet. This became the basis of the IBM Web Connections offering (the purchase of Whistle was portrayed as a time-to-market decision). The InterJet II product is what funded the Soft Updates port to FreeBSD. The idea was to get rid of the internal UPS that was otherwise required, to reduce the COGS (Cost Of Goods Sold). With Soft Updates, we were able to replace the UPS with a power supply with a large DC holdup time, and AC fail notification. This work occured mostly before the IBM acquisition. When the GPL JFS was announced, I tried within IBM for a year to get the code under other terms for use in an IBM GSB product, specifically, the InterJet. The people involved were on a religious/marketing GPL crusade, however. If we had been able to use a JFS, we would have been able to get rid of the remainder of the extra cost in the power supply, and get our costs down further, by using an off-the-shelf supply. Despite the fact that this was costing another division of IBM money, the people releasing the JFS refused to relicense, even for internal use only, the JFS code that they were giving away to the Linux community (I'm sure that, if the AIX people had the code, that it was possible, were we to commit a large enough chunk of our operating budget, to get the code from the AIX people, but the amortized cost of this would not have reduced our COGS). With JFS under non-GPL'ed terms, we wuld have been able to get perhaps another $120 per unit out of the final end customer cost. In the U.S., this would have let us drop our subscription cost $10/month. In Japan, it would have dropped ~20,000 Yen from the total per unit cost. Forgive me if I don't think that someone outside IBM is going to have any better luck than a group of high band people inside IBM who could demonstrate a business case pertinenet to IBMs financial interests. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 4: 9:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from mx6.airmail.net (mx6.airmail.net [209.196.77.103]) by hub.freebsd.org (Postfix) with ESMTP id 07D0637B416; Wed, 12 Dec 2001 04:09:29 -0800 (PST) Received: from covert.black-ring.iadfw.net ([209.196.123.142]) by mx6.airmail.net with smtp (Exim 3.16 #10) id 16E8CX-000Oi2-00; Wed, 12 Dec 2001 06:09:29 -0600 Received: from fanec from [213.121.101.252] by covert.black-ring.iadfw.net (/\##/\ Smail3.1.30.16 #30.55) with smtp for sender: id ; Wed, 12 Dec 2001 06:10:57 -0600 (CST) From: "Alan Edmonds" To: "Poul-Henning Kamp" , Subject: RE: buildworld broken on globaldata.h Date: Wed, 12 Dec 2001 12:09:24 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <53884.1008157385@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > -----Original Message----- > From: owner-freebsd-current@FreeBSD.ORG > [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of=20 > Poul-Henning Kamp > Sent: 12 December 2001 11:43 > To: current@freebsd.org > Subject: buildworld broken on globaldata.h >=20 >=20 >=20 > My buildworld breaks: >=20 > [...] > /flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52:=20 > machine/globaldata.h: No=20 > such file or directory >=20 > Any workarounds/fixes ? Ditto here. I just tried a rm -fr /usr/obj and then make buildworld.=20 It's still running but it's a slow machine. Alan Edmonds To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 4: 9:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id D963037B420 for ; Wed, 12 Dec 2001 04:09:49 -0800 (PST) Received: from pool0012.cvx22-bradley.dialup.earthlink.net ([209.179.198.12] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16E8Cn-00042g-00; Wed, 12 Dec 2001 04:09:45 -0800 Message-ID: <3C17490F.4D1992A7@mindspring.com> Date: Wed, 12 Dec 2001 04:09:51 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Kenneth Milton Cc: current@FreeBSD.ORG Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD References: <20011211102645.46795.qmail@web21110.mail.yahoo.com> <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <3C15AC5A.44BFD2BD@mindspring.com> <20011211183001.B67986@monorchid.lemis.com> <3C15CD07.6D5FC2E7@mindspring.com> <20011212131125.A82733@monorchid.lemis.com> <3C16D226.F169C43D@mindspring.com> <20011212203016.O46324@zeus.theinternet.com.au> <3C174284.8F0B3B7B@mindspring.com> <20011212220135.Q46324@zeus.theinternet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andrew Kenneth Milton wrote: > | I can't argue with that; historically, IBM has never sued anyone, and > | they were oh so happy to consider another license for the year I tried > | to push for it for use in a FreeBSD based IBM product. Not. > > Of course not, the GPL protects them from competitors taking and improving > their product and selling it at a profit without having to share. Ironic > isn't it, that the GPL has become a tool of the "oppressors" d8) Perhaps you missed the fact that I was *ALSO* IBM at the time. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 4:15:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from theinternet.com.au (c20631.kelvn1.qld.optusnet.com.au [203.164.207.8]) by hub.freebsd.org (Postfix) with ESMTP id A169D37B405 for ; Wed, 12 Dec 2001 04:15:42 -0800 (PST) Received: (from akm@localhost) by theinternet.com.au (8.11.6/8.11.4) id fBCCFYu76681; Wed, 12 Dec 2001 22:15:34 +1000 (EST) (envelope-from akm) Date: Wed, 12 Dec 2001 22:15:34 +1000 From: Andrew Kenneth Milton To: Terry Lambert Cc: Andrew Kenneth Milton , current@FreeBSD.ORG Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD Message-ID: <20011212221534.R46324@zeus.theinternet.com.au> References: <20011210161410.L92148@elvis.mu.org> <3C15AC5A.44BFD2BD@mindspring.com> <20011211183001.B67986@monorchid.lemis.com> <3C15CD07.6D5FC2E7@mindspring.com> <20011212131125.A82733@monorchid.lemis.com> <3C16D226.F169C43D@mindspring.com> <20011212203016.O46324@zeus.theinternet.com.au> <3C174284.8F0B3B7B@mindspring.com> <20011212220135.Q46324@zeus.theinternet.com.au> <3C17490F.4D1992A7@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <3C17490F.4D1992A7@mindspring.com>; from Terry Lambert on Wed, Dec 12, 2001 at 04:09:51AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG +-------[ Terry Lambert ]---------------------- | Andrew Kenneth Milton wrote: | > | I can't argue with that; historically, IBM has never sued anyone, and | > | they were oh so happy to consider another license for the year I tried | > | to push for it for use in a FreeBSD based IBM product. Not. | > | > Of course not, the GPL protects them from competitors taking and improving | > their product and selling it at a profit without having to share. Ironic | > isn't it, that the GPL has become a tool of the "oppressors" d8) | | Perhaps you missed the fact that I was *ALSO* IBM at the time. I didn't. I wasn't saying you were a competitor, just that the GPL is a convenient license for corporations to use. IBM are bigger than most governments, were you surprised that the bureaucracy is too? -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 4:50:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id BE47B37B419; Wed, 12 Dec 2001 04:50:49 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id fBCCom511498; Wed, 12 Dec 2001 13:50:48 +0100 (MET) Date: Wed, 12 Dec 2001 13:50:48 +0100 (CET) From: Harti Brandt To: Poul-Henning Kamp Cc: current@FreeBSD.ORG, Subject: Re: buildworld broken on globaldata.h In-Reply-To: <53884.1008157385@critter.freebsd.dk> Message-ID: <20011212134719.Y36662-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 12 Dec 2001, Poul-Henning Kamp wrote: PK> PK>My buildworld breaks: PK> PK>[...] PK>/flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52: machine/globaldata.h: No PK>such file or directory PK> PK>Any workarounds/fixes ? This was broken by jhb's large commit yesterday to break globaldata in MI and MD parts. The following patch to gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c let's you compile gdb. Don't know whether it works. Maybe there are other problems further down in the buildworld (mine is still working) harti Index: kvm-fbsd.c =================================================================== RCS file: /usr/ncvs/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c,v retrieving revision 1.32 diff -r1.32 kvm-fbsd.c 52c52,53 < #include --- > #include > #include 121c122 < offsetof(struct globaldata, gd_ ## name) --- > offsetof(struct pcpu, pc_ ## name) 788,789c789,790 < struct globaldata lgd; < struct globaldata *gd; --- > struct pcpu lgd; > struct pcpu *gd; 794c795 < for (; gd != NULL; gd = SLIST_NEXT (&lgd, gd_allcpu)) --- > for (; gd != NULL; gd = SLIST_NEXT (&lgd, pc_allcpu)) 797c798 < if (lgd.gd_cpuid == cpuid) --- > if (lgd.pc_cpuid == cpuid) -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 6:15:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from savvyworld.net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id E124F37B419 for ; Wed, 12 Dec 2001 06:15:35 -0800 (PST) Received: (from root@localhost) by savvyworld.net (8.11.6/8.11.4) id fBCEFZj21177 for current@FreeBSD.ORG; Wed, 12 Dec 2001 06:15:35 -0800 (PST) (envelope-from eculp@EnContacto.Net) Received: from 64.173.182.155 ( [64.173.182.155]) as user eculp@EnContacto.Net by Mail.SavvyWorld.Net with HTTP; Wed, 12 Dec 2001 06:15:35 -0800 Message-ID: <1008166535.3c17668798a2c@Mail.SavvyWorld.Net> Date: Wed, 12 Dec 2001 06:15:35 -0800 From: Edwin Culp To: current@FreeBSD.ORG Subject: Re: dhclient busted for -current? References: <20011208181044.566a0ebf.Pierre.Dampure@westmarsh.com> <200112080216.fB82GhM02156@harmony.village.org> <20011208020722.A15023@emunix.emich.edu> <200112120502.fBC52VM32978@harmony.village.org> In-Reply-To: <200112120502.fBC52VM32978@harmony.village.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 64.173.182.155 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This may explain my problem with the excite@home/attbi.com change over. According to them it is pure dhcp. Since it has always just worked when I needed it, I haven't really tested. ed Quoting Warner Losh : > In message <20011208181044.566a0ebf.Pierre.Dampure@westmarsh.com> "Pierre Y. > Dampure" writes: > : Are you asking for specific options (my dhclient.conf is empty)? are you > using a reservation? > > I'm 100% sure it worked before the upgrade. :-(. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 6:25:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3E92D37B417; Wed, 12 Dec 2001 06:25:09 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA30995; Thu, 13 Dec 2001 01:25:00 +1100 Date: Thu, 13 Dec 2001 01:25:47 +1100 (EST) From: Bruce Evans X-X-Sender: To: Georg-W Koltermann Cc: , Subject: Re: panic: kernel trap doesn't have ucred In-Reply-To: Message-ID: <20011213012402.S35305-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Dec 2001, Georg-W Koltermann wrote: > I get a panic "kernel trap doesn't have ucred" when I try to install > Linux ORACLE 8.1.7. Looks like the trap handling for invalid segment registers on return to user mode is broken. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 7:45:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id EAB0537B41B; Wed, 12 Dec 2001 07:45:41 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id fBCFjWH57147; Wed, 12 Dec 2001 07:45:32 -0800 (PST) (envelope-from david) Date: Wed, 12 Dec 2001 07:45:32 -0800 (PST) From: David Wolfskill Message-Id: <200112121545.fBCFjWH57147@bunrab.catwhisker.org> To: brandt@fokus.gmd.de, phk@FreeBSD.ORG Subject: Re: buildworld broken on globaldata.h Cc: current@FreeBSD.ORG, jhb@FreeBSD.ORG In-Reply-To: <20011212134719.Y36662-100000@beagle.fokus.gmd.de> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Date: Wed, 12 Dec 2001 13:50:48 +0100 (CET) >From: Harti Brandt >PK>My buildworld breaks: >PK>[...] >This was broken by jhb's large commit yesterday to break globaldata in MI >and MD parts. The following patch to >gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c let's you compile gdb. Don't know >whether it works. Maybe there are other problems further down in the >buildworld (mine is still working) Maybe I'm just lucky, but today's -CURRENT built just fine for me on my build machine (without hand-patching of any kind): Last login: Wed Dec 12 06:42:43 2001 from bunrab.catwhiske Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT (FREEBEAST) #6: Wed Dec 12 07:19:55 PST 2001 freebeast[1] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #6: Wed Dec 12 07:19:55 PST 2001 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast[2] tail /var/log/cvsup-history.log CVSup ended from cvsup14.freebsd.org at Sat Dec 8 03:53:49 PST 2001 CVSup begin from cvsup14.freebsd.org at Sun Dec 9 03:47:03 PST 2001 CVSup ended from cvsup14.freebsd.org at Sun Dec 9 03:53:45 PST 2001 CVSup begin from cvsup10.freebsd.org at Mon Dec 10 03:47:33 PST 2001 CVSup begin from cvsup13.freebsd.org at Mon Dec 10 04:04:34 PST 2001 CVSup ended from cvsup13.freebsd.org at Mon Dec 10 04:11:34 PST 2001 CVSup begin from cvsup14.freebsd.org at Tue Dec 11 03:47:02 PST 2001 CVSup ended from cvsup14.freebsd.org at Tue Dec 11 03:53:23 PST 2001 CVSup begin from cvsup14.freebsd.org at Wed Dec 12 03:47:02 PST 2001 CVSup ended from cvsup14.freebsd.org at Wed Dec 12 03:53:39 PST 2001 freebeast[3] (Still cranking away on the laptop....) Cheers, david -- David H. Wolfskill david@catwhisker.org I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 12:26:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from mout01.kundenserver.de (mout01.kundenserver.de [195.20.224.132]) by hub.freebsd.org (Postfix) with ESMTP id EB5D237B416 for ; Wed, 12 Dec 2001 12:26:11 -0800 (PST) Received: from [172.19.20.60] (helo=mrelayng0.kundenserver.de) by mout01.kundenserver.de with esmtp (Exim 2.12 #2) id 16EFx7-0007Kf-00 for current@freebsd.org; Wed, 12 Dec 2001 21:26:05 +0100 Received: from pd9007851.dip.t-dialin.net ([217.0.120.81] helo=freebsd.mheller.org) by mrelayng0.kundenserver.de with asmtp (Exim 3.22 #2) id 16EFx7-0006UJ-00 for current@FreeBSD.ORG; Wed, 12 Dec 2001 21:26:05 +0100 Message-ID: <3C17BD34.4050704@freebsd.mheller.org> Date: Wed, 12 Dec 2001 21:25:24 +0100 From: Martin Heller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: de-DE MIME-Version: 1.0 To: current Subject: Re: Junior Kernel hacker task: Floppy driver mode handling. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello! After a quick glance thru the TUHS.org archives, I found a quick & dirty hack for 4.0-Stable by Jason T. Miller The README for this thing is as follows: >This tarball contains a dumb hack to read and write DEC RX50 diskettes >under FreeBSD. It consists of two pieces, a kernel patch and a set of >filters. The kernel patch, which should be applied to SYS/isa/fd.c, >adds >the RX50 physical format to the FreeBSD floppy driver. The patch is >based >on FreeBSD 4.0-STABLE, your mileage may vary. However, it is >conceptually >simple and should be easy enough to apply by hand. Note that this >format >is identical to the 5.25" 800K format, but with only one side. >Also in the kernel/ directory is a patch for MAKEDEV which adds device >nodes for the new format, with the name fd[n].rx50. Note that using >this >node with a drive that is not a high-density 5.25" floppy results in a >"device not configured" error. > >The filters/ directory contains two filters, rx50in and rx50out, which >deal with the logical sector interleave performed by the RQDX >controllers >on the PDP-11 and VAX; ideally, this would be handled in the driver; >like >I said, this is a dumb hack. Note that the filters read or write the >_entire_ disk; short input results in null-padding. This shouldn't be a >big deal, but it does result in a bit of extra disk I/O. C'est la vie. >They use standard input and standard output, and no output (except for >an >error message on standard error) is created if the input exceeds the >capacity of an RX50. Also keep in mind that non-PDP, non-VAX >implementations of the RX50 used different layouts, so the filters are >not >appropriate, for example, for DECmate or DEC Rainbow disks. The kernel >patch is, however, and this is the sole advantage of doing the >interleave >in userland. > >EXAMPLES: > >Create a tar archive of 'directory' on an RX50: > tar cf- directory/ | rx50out >/dev/fd1.rx50 > >Extract a tar archive from an RX50: > rx50in >Finally, you can try to format a disk as an RX50 with > fdformat /dev/fd1.rx50 > >I say 'try to format' because the diskettes I format in this fashion >are >prone to read/write errors on a real RX50. This is probably due to head >alignment issues, but it could, of course, be something else. I've had >no >problems reading and writing disks formatted in other ways (by DEC or >using custom hardware, in my case a Shaffstall 6000 media conversion >unit) >Bear in mind that RX50s, though they are written at 96tpi and thus >require >a high-density drive to read and write on a PC, are _not_ a >high-density >format, and using HD media will likely result in _lots_ of errors. I >use >96tpi double-density media myself, but good luck finding it. The best >substitute that is commonly available seems to be standard 360K >double-density media without hub rings. Once again, your mileage may >vary. >Please send any questions or comments, bugfixes or patches to >jasomill@shaffstall.com; once again, this is a dumb hack, written in an >evening, full of sound and fury, signifying nothing. The code is ugly, >but >the results, I'm happy to report, are not. > >-Jason T. Miller > June 9, 2000 Hope this helps , Martin Heller To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 12:35: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 027C937B417 for ; Wed, 12 Dec 2001 12:35:06 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBCKXOj63416; Wed, 12 Dec 2001 21:33:29 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Martin Heller Cc: current Subject: Re: Junior Kernel hacker task: Floppy driver mode handling. In-Reply-To: Your message of "Wed, 12 Dec 2001 21:25:24 +0100." <3C17BD34.4050704@freebsd.mheller.org> Date: Wed, 12 Dec 2001 21:33:24 +0100 Message-ID: <63414.1008189204@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3C17BD34.4050704@freebsd.mheller.org>, Martin Heller writes: >Hello! >After a quick glance thru the TUHS.org archives, I found a quick & dirty >hack for 4.0-Stable by Jason T. Miller >The README for this thing is as follows: That is where I got the inspiration to clean up our floppy driver. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 12:54:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 50B8A37B417 for ; Wed, 12 Dec 2001 12:54:24 -0800 (PST) Received: (qmail 9838 invoked from network); 12 Dec 2001 20:54:23 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Dec 2001 20:54:23 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011213012402.S35305-100000@gamplex.bde.org> Date: Wed, 12 Dec 2001 12:54:17 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: panic: kernel trap doesn't have ucred Cc: current@FreeBSD.ORG, Georg-W Koltermann Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 12-Dec-01 Bruce Evans wrote: > On Tue, 11 Dec 2001, Georg-W Koltermann wrote: > >> I get a panic "kernel trap doesn't have ucred" when I try to install >> Linux ORACLE 8.1.7. > > Looks like the trap handling for invalid segment registers on return to > user mode is broken. That would panic in that case, yes. For now that KASSERT() can just be commented out until I figure out how to make that a more proper assert. > Bruce -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 12:54:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 1D14637B41B for ; Wed, 12 Dec 2001 12:54:25 -0800 (PST) Received: (qmail 31888 invoked from network); 12 Dec 2001 20:54:24 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Dec 2001 20:54:24 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011212134719.Y36662-100000@beagle.fokus.gmd.de> Date: Wed, 12 Dec 2001 12:54:19 -0800 (PST) From: John Baldwin To: Harti Brandt Subject: Re: buildworld broken on globaldata.h Cc: current@FreeBSD.ORG, Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 12-Dec-01 Harti Brandt wrote: > On Wed, 12 Dec 2001, Poul-Henning Kamp wrote: > > PK> > PK>My buildworld breaks: > PK> > PK>[...] > PK>/flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52: > machine/globaldata.h: No > PK>such file or directory > PK> > PK>Any workarounds/fixes ? > > This was broken by jhb's large commit yesterday to break globaldata in MI > and MD parts. The following patch to > gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c let's you compile gdb. Don't know > whether it works. Maybe there are other problems further down in the > buildworld (mine is still working) You should only have to include (it includes already), but that patch looks ok. libkvm will need the same fix. My bad, I was so busy testing kernels and making sure they worked in various combinations I didn't test a buildworld. :( -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 16:53:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 202E737B417; Wed, 12 Dec 2001 16:53:16 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 804B3786E7; Thu, 13 Dec 2001 10:54:13 +1030 (CST) Date: Thu, 13 Dec 2001 10:54:13 +1030 From: Greg Lehey To: Bernd Walter Cc: Matthew Dillon , Wilko Bulte , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)) Message-ID: <20011213105413.G76019@monorchid.lemis.com> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211031120.G11774@cicely8.cicely.de> <20011212162205.I82733@monorchid.lemis.com> <20011212125337.D15654@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011212125337.D15654@cicely8.cicely.de> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote: > On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote: >> On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: >>> striped: >>> If you have 512byte stripes and have 2 disks. >>> You access 64k which is put into 2 32k transactions onto the disk. >> >> Only if your software optimizes the transfers. There are reasons why >> it should not. Without optimization, you get 128 individual >> transfers. > > If the software does not we end with 128 transactions anyway, which is > not very good becuase of the overhead for each of them. Correct. > UFS does a more or less good job in doing this. Well, it requires a lot of moves. Vinum *could* do this, but for the reasons specified below, there's no need. >>> raid5: >>> For a write you have two read transactions and two writes. >> >> This is the way Vinum does it. There are other possibilities: >> >> 1. Always do full-stripe writes. Then you don't need to read the old >> contents. > > Which isn't that good with the big stripes we usually want. Correct. That's why most RAID controllers limit stripe size to something sub-optimal, because it simplifies the code to do full-stripe writes. >> 2. Cache the parity blocks. This is an optimization which I think >> would be very valuable, but which Vinum doesn't currently perform. > > I thought of connecting the parity to the wait lock. > If there's a waiter for the same parity data it's not droped. > This way we don't waste memory but still have an efect. That's a possibility, though it doesn't directly address parity block caching. The problem is that by the time you find another lock, you've already performed part of the parity calculation, and probably part of the I/O transfer. But it's an interesting consideration. >>> If we had a fine grained locking which only locks the accessed sectors >>> in the parity we would be able to have more than a single ascending >>> write transaction onto a single drive. >> >> Hmm. This is something I hadn't thought about. Note that sequential >> writes to a RAID-5 volume don't go to sequential addresses on the >> spindles; they will work up to the end of the stripe on one spindle, >> then start on the next spindle at the start of the stripe. You can do >> that as long as the address ranges in the parity block don't overlap, >> but the larger the stripe, the greater the likelihood of this would >> be. This might also explain the following observed behaviour: >> >> 1. RAID-5 writes slow down when the stripe size gets > 256 kB or so. >> I don't know if this happens on all disks, but I've seen it often >> enough. > > I would guess it when the stripe size is bigger than the preread cache > the drives uses. > This would mean we have a less chance to get parity data out of the > drive cache. Yes, this was one of the possibilities we considered. >> 2. rawio write performance is better than ufs write performance. >> rawio does "truly" random transfers, where ufs is a mixture. > > The current problem is to increase linear write performance. > I don't see a chance that rawio benefit of it, but ufs will. Well, rawio doesn't need to benefit. It's supposed to be a neutral observer, but in this case it's not doing too well. >> Do you feel like changing the locking code? It shouldn't be that much >> work, and I'd be interested to see how much performance difference it >> makes. > > I put it onto my todo list. Thanks. >> Note that there's another possible optimization here: delay the writes >> by a certain period of time and coalesce them if possible. I haven't >> finished thinking about the implications. > > That's exactly what the ufs clustering and softupdates does. > If it doesn't fit modern drives anymore it should get tuned there. This doesn't have too much to do with modern drives; it's just as applicable to 70s drives. > Whenever a write hits a driver there is a waiter for it. > Either a softdep, a memory freeing or an application doing an sync > transfer. > I'm almost shure delaying writes will harm performance in upper layers. I'm not so sure. Full stripe writes, where needed, are *much* faster than partial strip writes. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 18: 6:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 32A0D37B419; Wed, 12 Dec 2001 18:06:23 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fBD26Fw88194; Thu, 13 Dec 2001 03:06:15 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fBD26Ntx019121; Thu, 13 Dec 2001 03:06:23 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fBD26MW08858; Thu, 13 Dec 2001 03:06:22 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fBD26EQ20074; Thu, 13 Dec 2001 03:06:14 +0100 (CET) (envelope-from ticso) Date: Thu, 13 Dec 2001 03:06:14 +0100 From: Bernd Walter To: Greg Lehey Cc: Matthew Dillon , Wilko Bulte , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)) Message-ID: <20011213030613.A18679@cicely8.cicely.de> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211031120.G11774@cicely8.cicely.de> <20011212162205.I82733@monorchid.lemis.com> <20011212125337.D15654@cicely8.cicely.de> <20011213105413.G76019@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011213105413.G76019@monorchid.lemis.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 13, 2001 at 10:54:13AM +1030, Greg Lehey wrote: > On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote: > > On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote: > >> On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: > >> 2. Cache the parity blocks. This is an optimization which I think > >> would be very valuable, but which Vinum doesn't currently perform. > > > > I thought of connecting the parity to the wait lock. > > If there's a waiter for the same parity data it's not droped. > > This way we don't waste memory but still have an efect. > > That's a possibility, though it doesn't directly address parity block > caching. The problem is that by the time you find another lock, > you've already performed part of the parity calculation, and probably > part of the I/O transfer. But it's an interesting consideration. I know that it doesn't do the best, but it's easy to implement. A more complex handling for the better results can still be done. > >>> If we had a fine grained locking which only locks the accessed sectors > >>> in the parity we would be able to have more than a single ascending > >>> write transaction onto a single drive. > >> > >> Hmm. This is something I hadn't thought about. Note that sequential > >> writes to a RAID-5 volume don't go to sequential addresses on the > >> spindles; they will work up to the end of the stripe on one spindle, > >> then start on the next spindle at the start of the stripe. You can do > >> that as long as the address ranges in the parity block don't overlap, > >> but the larger the stripe, the greater the likelihood of this would > >> be. This might also explain the following observed behaviour: > >> > >> 1. RAID-5 writes slow down when the stripe size gets > 256 kB or so. > >> I don't know if this happens on all disks, but I've seen it often > >> enough. > > > > I would guess it when the stripe size is bigger than the preread cache > > the drives uses. > > This would mean we have a less chance to get parity data out of the > > drive cache. > > Yes, this was one of the possibilities we considered. It should be measured and compared after I changed the looking. It will look different after that and may lead to other reasons, because we will have a different load characteristic on the drives. Currently if we have two writes in two stripes each, all initated before the first finished, the drive has to seek between the two stripes, as the second write to the same stripe has to wait. > >> Note that there's another possible optimization here: delay the writes > >> by a certain period of time and coalesce them if possible. I haven't > >> finished thinking about the implications. > > > > That's exactly what the ufs clustering and softupdates does. > > If it doesn't fit modern drives anymore it should get tuned there. > > This doesn't have too much to do with modern drives; it's just as > applicable to 70s drives. One of softupdates job is to eliminate redundant writes and to do async writes without loosing consistency of the on media structure. This also means that we have a better chance that data is written in big chunks. In general the wire speed of data to the drive is increased with every new bus generation but usually big parts of the overhead is keeped for compatibility with older drives. I agree that the parity based raid situation does depend more on principle than on the age of the drive. > > Whenever a write hits a driver there is a waiter for it. > > Either a softdep, a memory freeing or an application doing an sync > > transfer. > > I'm almost shure delaying writes will harm performance in upper layers. > > I'm not so sure. Full stripe writes, where needed, are *much* faster > than partial strip writes. Hardware raid usually comes with NVRAM and can cache write data without delaying the acklowledge to the initiator. That option is not available to software raid. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 18:18: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 945A037B417; Wed, 12 Dec 2001 18:17:55 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id BE352786E3; Thu, 13 Dec 2001 12:47:53 +1030 (CST) Date: Thu, 13 Dec 2001 12:47:53 +1030 From: Greg Lehey To: Bernd Walter Cc: Matthew Dillon , Wilko Bulte , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)) Message-ID: <20011213124753.Q3448@monorchid.lemis.com> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211031120.G11774@cicely8.cicely.de> <20011212162205.I82733@monorchid.lemis.com> <20011212125337.D15654@cicely8.cicely.de> <20011213105413.G76019@monorchid.lemis.com> <20011213030613.A18679@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011213030613.A18679@cicely8.cicely.de> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday, 13 December 2001 at 3:06:14 +0100, Bernd Walter wrote: > On Thu, Dec 13, 2001 at 10:54:13AM +1030, Greg Lehey wrote: >> On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote: >>> On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote: >>>> On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: >>>> 2. Cache the parity blocks. This is an optimization which I think >>>> would be very valuable, but which Vinum doesn't currently perform. >>> >>> I thought of connecting the parity to the wait lock. >>> If there's a waiter for the same parity data it's not droped. >>> This way we don't waste memory but still have an efect. >> >> That's a possibility, though it doesn't directly address parity block >> caching. The problem is that by the time you find another lock, >> you've already performed part of the parity calculation, and probably >> part of the I/O transfer. But it's an interesting consideration. > > I know that it doesn't do the best, but it's easy to implement. > A more complex handling for the better results can still be done. I don't have the time to work out an example, but I don't think it would change anything until you had two lock waits. I could be wrong, though: you've certainly brought out something here that I hadn't considered, so if you can write up a detailed example (preferably after you've looked at the code and decided how to handle it), I'd certainly be interested. >>> I would guess it when the stripe size is bigger than the preread >>> cache the drives uses. This would mean we have a less chance to >>> get parity data out of the drive cache. >> >> Yes, this was one of the possibilities we considered. > > It should be measured and compared after I changed the looking. > It will look different after that and may lead to other reasons, > because we will have a different load characteristic on the drives. > Currently if we have two writes in two stripes each, all initated before > the first finished, the drive has to seek between the two stripes, as > the second write to the same stripe has to wait. I'm not sure I understand this. The stripes are on different drives, after all. >>> Whenever a write hits a driver there is a waiter for it. >>> Either a softdep, a memory freeing or an application doing an sync >>> transfer. >>> I'm almost shure delaying writes will harm performance in upper layers. >> >> I'm not so sure. Full stripe writes, where needed, are *much* faster >> than partial strip writes. > > Hardware raid usually comes with NVRAM and can cache write data without > delaying the acklowledge to the initiator. > That option is not available to software raid. It could be. It's probably something worth investigating and supporting. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 19:20:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id AA97137B419; Wed, 12 Dec 2001 19:20:04 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fBD3K2b88616; Thu, 13 Dec 2001 04:20:02 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fBD317tx019640; Thu, 13 Dec 2001 04:01:07 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fBD316W09538; Thu, 13 Dec 2001 04:01:06 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fBD30sK20204; Thu, 13 Dec 2001 04:00:54 +0100 (CET) (envelope-from ticso) Date: Thu, 13 Dec 2001 04:00:53 +0100 From: Bernd Walter To: Greg Lehey Cc: Matthew Dillon , Wilko Bulte , Mike Smith , Terry Lambert , Joerg Wunsch , freebsd-current@FreeBSD.org Subject: Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)) Message-ID: <20011213040053.A20140@cicely8.cicely.de> References: <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211031120.G11774@cicely8.cicely.de> <20011212162205.I82733@monorchid.lemis.com> <20011212125337.D15654@cicely8.cicely.de> <20011213105413.G76019@monorchid.lemis.com> <20011213030613.A18679@cicely8.cicely.de> <20011213124753.Q3448@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011213124753.Q3448@monorchid.lemis.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 13, 2001 at 12:47:53PM +1030, Greg Lehey wrote: > On Thursday, 13 December 2001 at 3:06:14 +0100, Bernd Walter wrote: > > Currently if we have two writes in two stripes each, all initated before > > the first finished, the drive has to seek between the two stripes, as > > the second write to the same stripe has to wait. > > I'm not sure I understand this. The stripes are on different drives, > after all. Lets asume a 256k striped single plex volume with 3 subdisks. We get a layout like this: sd1 sd2 sd3 256k 256k parity 256k parity 256k parity 256k 256k 256k 256k parity ... ... ... Now we write on the volume the blocks 1, 10, 1040 and 1045. All writes are initated at the same time. Good would be to write first 1 then 10 then 1040 and finaly 1045. What we currently see is write 1 then 1040 then 10 and finaly 1045. This is because we can't write 10 unless 1 is finished but we already start with 1040 because it's independend. The result is avoidable seeking in subdisk 1. Back to the >256k performance breakdown you described. Because of the seeks we have not only unneeded seeks on the drive but also have a different use pattern on the drive cache. Once the locks are untangled it is required to verify the situation as the drive cache may behave differently. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Dec 12 22:42:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 0E4EA37B417 for ; Wed, 12 Dec 2001 22:42:07 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBD6g6X36061; Wed, 12 Dec 2001 22:42:06 -0800 (PST) (envelope-from rizzo) Date: Wed, 12 Dec 2001 22:42:06 -0800 From: Luigi Rizzo To: current@freebsd.org Subject: -current vs. -stable network performance Message-ID: <20011212224206.D35108@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I am testing the forwarding performance of CURRENT vs. STABLE (both more or less up to date, unmodified, with the latest performance patches to the "dc" driver, which I am using) and I am having some surprises. STABLE can forward approx 125Kpps, whereas CURRENT tops at approx 80Kpps. This is on the same hardware, 750MHz Athlon, fastforwarding enabled, a 4-port 21143 card, one input driven with a stream of up to 148Kpps (64 bytes each). Ability to transmit seems roughly the same (in both cases 138Kpps), and lack of CPU does not seem to be the problem (at least for CURRENT), so I am suspecting some difference in the initialization of PCI parameters, such as burst size etc, but I am unclear on where to look at. Any ideas ? cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 0:47:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id AC9D237B419; Thu, 13 Dec 2001 00:47:08 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id fBD8l6511781; Thu, 13 Dec 2001 09:47:06 +0100 (MET) Date: Thu, 13 Dec 2001 09:47:06 +0100 (CET) From: Harti Brandt To: John Baldwin Cc: Harti Brandt , , Poul-Henning Kamp Subject: Re: buildworld broken on globaldata.h In-Reply-To: Message-ID: <20011213094636.B97693-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 12 Dec 2001, John Baldwin wrote: JB> JB>On 12-Dec-01 Harti Brandt wrote: JB>> On Wed, 12 Dec 2001, Poul-Henning Kamp wrote: JB>> JB>> PK> JB>> PK>My buildworld breaks: JB>> PK> JB>> PK>[...] JB>> PK>/flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52: JB>> machine/globaldata.h: No JB>> PK>such file or directory JB>> PK> JB>> PK>Any workarounds/fixes ? JB>> JB>> This was broken by jhb's large commit yesterday to break globaldata in MI JB>> and MD parts. The following patch to JB>> gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c let's you compile gdb. Don't know JB>> whether it works. Maybe there are other problems further down in the JB>> buildworld (mine is still working) JB> JB>You should only have to include (it includes JB>already), but that patch looks ok. libkvm will need the same fix. My bad, I JB>was so busy testing kernels and making sure they worked in various combinations JB>I didn't test a buildworld. :( Hmmm, libkvm just built without patches... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 2:52:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by hub.freebsd.org (Postfix) with ESMTP id C278037B41A; Thu, 13 Dec 2001 02:52:33 -0800 (PST) Received: (from hk@localhost) by alogis.com (8.11.1/8.9.3) id fBDAqV988628; Thu, 13 Dec 2001 11:52:31 +0100 (CET) (envelope-from hk) Date: Thu, 13 Dec 2001 11:52:31 +0100 From: Holger Kipp To: Greg Lehey Cc: Mike Smith , Joerg Wunsch , freebsd-current@FreeBSD.ORG Subject: Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011213115231.A85142@intserv.int1.b.intern> Reply-To: Holger.Kipp@alogis.com References: <20011210130713.C63585@monorchid.lemis.com> <200112100817.fBA8HEe07837@mass.dis.org> <20011210192709.H63585@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: <20011210192709.H63585@monorchid.lemis.com>; from grog@FreeBSD.ORG on Mon, Dec 10, 2001 at 07:27:09PM +1030 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 10, 2001 at 07:27:09PM +1030, Greg Lehey wrote: > suggests, that this is a fixable bug, but every time I mention it, I > get shouted down. And yes, like Jörg, I don't care enough. I'm not > saying "ditch the Microsoft partition table", I'm saying "don't ditch > disks without the Microsoft partition table". Note also that, > although this is so "dangerous", it has never bitten me on any system. So far I had no problems with dangerously dedicated mode. As I usually use FreeBSD on dedicated server hardware, I prefer the "dangerously" dedicated style. => Add me to the list of people who'd like the "dangerously dedicated" option to stay in. > What is it about this particular topic brings out such irrational > emotions in you and others? On my part I am very calm (for now). I see it this way: on FreeBSD I can choose if I want to use M$ partition table or not. This is what I call freedom of choice, and I don't want to loose it, if there are no substantial reasons to do so. Currently I don't see any. Just my two Pfennigs (soon only 1 Eurocent) Regards, Holger Kipp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 3:31:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4FE8B37B416; Thu, 13 Dec 2001 03:31:28 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA18813; Thu, 13 Dec 2001 22:31:25 +1100 Date: Thu, 13 Dec 2001 22:32:20 +1100 (EST) From: Bruce Evans X-X-Sender: To: John Baldwin Cc: Subject: Re: Patch Review: i386 asm cleanups in the kernel In-Reply-To: Message-ID: <20011213215212.O277-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Dec 2001, John Baldwin wrote: > Ok, I've axed all the "cc" clobbers from the patch now. Any objections to it > now? It's still at ~jhb/patches/i386_asm.patch. Review of what I can see: the URL still appears to be well formed ;-). But it didn't seem to work, so I scp'ed the file. > Index: i386/i386/identcpu.c > =================================================================== > RCS file: /usr/cvs/src/sys/i386/i386/identcpu.c,v > retrieving revision 1.96 > diff -u -r1.96 identcpu.c > --- i386/i386/identcpu.c 30 Nov 2001 11:57:23 -0000 1.96 > +++ i386/i386/identcpu.c 6 Dec 2001 07:58:25 -0000 > @@ -115,10 +115,11 @@ > static void > do_cpuid(u_int ax, u_int *p) > { > + > + p[0] = ax; > __asm __volatile( > "cpuid" > - : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) > - : "0" (ax) > + : "+a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) > ); > } > "0" here was bogus. Just replace it by "a". > Index: i386/i386/math_emulate.c > =================================================================== > RCS file: /usr/cvs/src/sys/i386/i386/math_emulate.c,v > retrieving revision 1.40 > diff -u -r1.40 math_emulate.c > --- i386/i386/math_emulate.c 28 Nov 2001 01:42:16 -0000 1.40 > +++ i386/i386/math_emulate.c 7 Dec 2001 19:07:16 -0000 > ... > @@ -771,14 +770,13 @@ > "addl %0,%0 ; adcl %1,%1\n\t" \ > "addl %0,%0 ; adcl %1,%1\n\t" \ > "addl %%ecx,%0 ; adcl %%ebx,%1" \ > - : "=a" (low), "=d" (high) \ > - : "0" (low), "1" (high) \ > - : "cx", "bx") > + : "+a" (low), "+d" (high) \ > + : : "ecx", "ebx") Weren't the register names in the clobber list the normal ones? > @@ -938,7 +935,7 @@ > "movl 4(%0),%%eax ; adcl %%eax,4(%0)\n\t" > "movl 8(%0),%%eax ; adcl %%eax,8(%0)\n\t" > "movl 12(%0),%%eax ; adcl %%eax,12(%0)" > - ::"r" (c):"ax"); > + : :"r" (c):"eax", "memory"); > } > > static void This should use output operands c[0]..c[3], not a general "memory" clobber. > [... more suboptimal "memory" clobbers] I wouldn't trust all the little changes to math_emulate.c without runtime testing. It won't be tested by using it in normal operation. > Index: i386/include/bus_pc98.h > =================================================================== > RCS file: /usr/cvs/src/sys/i386/include/bus_pc98.h,v > retrieving revision 1.19 > diff -u -r1.19 bus_pc98.h > --- i386/include/bus_pc98.h 7 Oct 2001 10:04:18 -0000 1.19 > +++ i386/include/bus_pc98.h 7 Dec 2001 19:10:37 -0000 > @@ -203,11 +203,10 @@ > \ > __asm __volatile("call *%2" \ > :"=a" (result), \ > - "=d" (offset) \ > + "+d" (offset) \ > :"o" (bsh->bsh_bam.bs_read_##BWN), \ > - "b" (bsh), \ > - "1" (offset) \ > - ); \ > + "b" (bsh) \ > + :"ecx","memory"); \ > \ > return result; \ > } It's surprising that the missing "ecx" in lots of clobber lists in this file didn't cause problems. > Index: i386/include/cpufunc.h > =================================================================== > RCS file: /usr/cvs/src/sys/i386/include/cpufunc.h,v > retrieving revision 1.105 > diff -u -r1.105 cpufunc.h > --- i386/include/cpufunc.h 28 Jun 2001 02:08:13 -0000 1.105 > +++ i386/include/cpufunc.h 7 Dec 2001 19:11:47 -0000 > @@ -66,18 +66,18 @@ > static __inline u_int > bsfl(u_int mask) > { > - u_int result; > + u_int result = mask; Style bug: initialization in declaration. > > - __asm __volatile("bsfl %0,%0" : "=r" (result) : "0" (mask)); > + __asm __volatile("bsfl %0,%0" : "+r" (result)); > return (result); > } "0" here was bogus, except we abuse the same operand for input and output. I checked that gcc does the right thing (reuse the input register for output if the input operand becomes dead) with a non-hand-optimized version: __asm __volatile("bsfl %1,%0" : "=r" (result) : "r" (mask)); ... main() { return bsfl(23); } "rm" (mask) works too. > > static __inline u_int > bsrl(u_int mask) > { > - u_int result; > + u_int result = mask; > > - __asm __volatile("bsrl %0,%0" : "=r" (result) : "0" (mask)); > + __asm __volatile("bsrl %0,%0" : "+r" (result)); > return (result); > } Similarly. The other changes seem to be OK. I checked about 1/4 of them. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 4:57:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7078637B41C for ; Thu, 13 Dec 2001 04:57:49 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 7AA3C14C53; Thu, 13 Dec 2001 13:57:47 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Luigi Rizzo Cc: current@freebsd.org Subject: Re: -current vs. -stable network performance References: <20011212224206.D35108@iguana.aciri.org> From: Dag-Erling Smorgrav Date: 13 Dec 2001 13:57:46 +0100 In-Reply-To: <20011212224206.D35108@iguana.aciri.org> Message-ID: Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo writes: > STABLE can forward approx 125Kpps, whereas CURRENT tops at approx 80Kpps. Kernel configs, please. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 6:15:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from savvyworld.net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id E3D7637B405 for ; Thu, 13 Dec 2001 06:15:39 -0800 (PST) Received: (from root@localhost) by savvyworld.net (8.11.6/8.11.4) id fBDEFWn71993 for current@FreeBSD.Org; Thu, 13 Dec 2001 06:15:32 -0800 (PST) (envelope-from eculp@EnContacto.Net) Received: from 64.173.182.155 ( [64.173.182.155]) as user eculp@EnContacto.Net by Mail.SavvyWorld.Net with HTTP; Thu, 13 Dec 2001 06:15:32 -0800 Message-ID: <1008252932.3c18b80413c6e@Mail.SavvyWorld.Net> Date: Thu, 13 Dec 2001 06:15:32 -0800 From: Edwin Culp To: current@FreeBSD.Org Subject: dhclient MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 64.173.182.155 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is anyone using dhclient successfully with Current of the last week or so? I don't use it all the time but I have been trying for the last couple of days without success. It accesses the server and changes the interface ip to 0.0.0.0 netmask 255.255.255.255. Thanks, ce --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 7:18: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 947B237B41F for ; Thu, 13 Dec 2001 07:17:53 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id 2AF571C26; Thu, 13 Dec 2001 16:17:27 +0100 (CET) Date: Thu, 13 Dec 2001 16:17:27 +0100 From: Emiel Kollof To: Edwin Culp Cc: current@FreeBSD.Org Subject: Re: dhclient Message-ID: <20011213151727.GC658@laptop.hackerheaven.org> References: <1008252932.3c18b80413c6e@Mail.SavvyWorld.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1008252932.3c18b80413c6e@Mail.SavvyWorld.Net> User-Agent: Mutt/1.3.24i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.org/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Edwin Culp (eculp@EnContacto.Net) wrote: > Is anyone using dhclient successfully with Current of the last week or so? > I don't use it all the time but I have been trying for the last couple of > days without success. > > It accesses the server and changes the interface ip to 0.0.0.0 netmask > 255.255.255.255. No problems here, I just made world and kernel yesterday night (or this morining, depends on how you put it :) after a bout of cvsupping. FreeBSD tiamat.ipv6.hackerheaven.org 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Thu Dec 13 04:08:33 CET 2001 root@tiamat.ipv6.hackerheaven.org:/usr/obj/usr/src/sys/TIAMAT i386 dhclient works and acks fine for me. Cheers, Emiel -- Are you a turtle? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 7:25:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 3A96B37B41B for ; Thu, 13 Dec 2001 07:25:24 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id fBDFPKO60377; Thu, 13 Dec 2001 07:25:20 -0800 (PST) (envelope-from david) Date: Thu, 13 Dec 2001 07:25:20 -0800 (PST) From: David Wolfskill Message-Id: <200112131525.fBDFPKO60377@bunrab.catwhisker.org> To: current@FreeBSD.ORG, eculp@EnContacto.Net Subject: Re: dhclient In-Reply-To: <1008252932.3c18b80413c6e@Mail.SavvyWorld.Net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Date: Thu, 13 Dec 2001 06:15:32 -0800 >From: Edwin Culp >Is anyone using dhclient successfully with Current of the last week or so? Sure; hadn't noticed any problems with it. >I don't use it all the time but I have been trying for the last couple of >days without success. >It accesses the server and changes the interface ip to 0.0.0.0 netmask >255.255.255.255. Odd. Looks like symptom of a failure to get a lease (to me, though I'm not an expert in DHCP). Do you have available IP addresses to hand out? Are you sure the NIC is operating properly? (E.g., can you put it in promiscuous mode & see traffic on the net, via tcpdump or ethereal?) (I've been tracking both -STABLE & -CURRENT daily(*), both on my laptop (which is a DHCP client) and my build machine (which isn't) for several months now....) * OK; modulo the occasional breakage. But that's been pretty rare -- even in -CURRENT, for me. Cheers, david -- David H. Wolfskill david@catwhisker.org I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 7:45:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 4ACAF37B405 for ; Thu, 13 Dec 2001 07:45:12 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16EY3x-0004aU-00 for current@FreeBSD.org; Thu, 13 Dec 2001 17:46:21 +0200 From: Sheldon Hearn To: current@FreeBSD.org Subject: Re: __xuname gone AWOL? In-reply-to: Your message of "Tue, 11 Dec 2001 13:17:45 +0200." <39317.1008069465@axl.seasidesoftware.co.za> Date: Thu, 13 Dec 2001 17:46:21 +0200 Message-ID: <17637.1008258381@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Dec 2001 13:17:45 +0200, Sheldon Hearn wrote: > Since last week, I'm having trouble compiling one of the utilities > supplied with Exim, which calls uname(): > > gcc -O -pipe -march=pentiumpro -march=pentiumpro \ > -o exim_lock exim_lock.c -lcrypt -lpam > /tmp/cc2YeHtC.o: In function `main': > /tmp/cc2YeHtC.o(.text+0x50d): undefined reference to `__xuname' > *** Error code 1 Hi folks, Yesterday's -CURRENT install fixed the problem, although it may have been resolved before that. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 8: 0:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2CB0C37B41C for ; Thu, 13 Dec 2001 08:00:28 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBDG0Oq39665; Thu, 13 Dec 2001 08:00:24 -0800 (PST) (envelope-from rizzo) Date: Thu, 13 Dec 2001 08:00:24 -0800 From: Luigi Rizzo To: Dag-Erling Smorgrav Cc: current@freebsd.org Subject: Re: -current vs. -stable network performance Message-ID: <20011213080024.A39631@iguana.aciri.org> References: <20011212224206.D35108@iguana.aciri.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Dec 13, 2001 at 01:57:46PM +0100, Dag-Erling Smorgrav wrote: > Luigi Rizzo writes: > > STABLE can forward approx 125Kpps, whereas CURRENT tops at approx 80Kpps. > > Kernel configs, please. Attached. PICO5 is for CURRENT, PICO4 is for STABLE. In my testbed i am using the "dc" driver. cheers luigi --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=PICO4 # # $FreeBSD: src/release/picobsd/bridge/PICOBSD,v 1.1.4.3 2001/01/29 22:40:02 luigi Exp $ # # Line starting with #PicoBSD contains PicoBSD build parameters #marker def_sz init MFS_inodes floppy_inodes #PicoBSD 4200 init 8192 32768 options MD_ROOT_SIZE=4200 # same as def_sz #makeoptions CWARNFLAGS="-pedantic -Werror" #makeoptions COPTFLAGS="-O2" # next to each option there is the approx. space used in the # picobsd image. machine i386 #cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident PICOBSD maxusers 20 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] #options BOOTP options MFS #Memory Filesystem options MD_ROOT #MFS as root options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options MSDOSFS #MSDOS Filesystem #options CD9660 #ISO 9660 Filesystem, 12KB #options PROCFS #Process filesystem, 4KB #options USERCONFIG #boot -c editor, 4KB #options INTRO_USERCONFIG #imply -c and parse info area #options VISUAL_USERCONFIG #visual boot -c editor options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT # divert (for natd, 4KB) #options DEVFS options PCI_QUIET # Support for bridging and bandwidth limiting options DUMMYNET options BRIDGE options HZ=1000 #options NMBCLUSTERS=16384 options NMBCLUSTERS=8192 #config kernel root on fd0a device isa0 device pci0 device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device ata0 at isa? port IO_WD1 irq 14 #device ata1 at isa? port IO_WD2 irq 15 #device ata device atadisk #device atapicd # 8KB # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 #device psm0 at atkbdc? irq 12 # 8KB device vga0 at isa? # syscons is the default console driver, resembling an SCO console device sc0 at isa? device npx0 at nexus? port IO_NPX irq 13 # flags 0x30 means console, does not work on vmware. device sio0 at isa? port IO_COM1 flags 0x30 irq 4 device sio1 at isa? port IO_COM2 irq 3 # device ppc0 at isa? port? flags 0x40 irq 7 # device ppbus0 # device nlpt0 at ppbus? # device plip0 at ppbus? # device ppi0 at ppbus? # # The following Ethernet NICs are all PCI devices. # device miibus #device de0 # DEC/Intel DC21x4x (``Tulip'') device fxp0 # Intel, 4KB #device xl0 # 3Com #device ep0 device rl0 # Realtek 8139, 4KB device dc0 # New Dec/Intel DC21x4x, 8KB device sis0 device lnc0 device ed0 at isa? port 0x280 irq 5 iomem 0xd8000 device ed1 at isa? port 0x300 irq 5 iomem 0xd0000 pseudo-device loop pseudo-device ether #pseudo-device tun 2 # 4KB, for ppp #pseudo-device vn pseudo-device pty 16 pseudo-device md # memory disk #options MATH_EMULATE #Support for x87 emulation, 4KB pseudo-device bpf 4 # 4KB, for tcpdump #options NFS #Network Filesystem #options NFS_NOSERVER #Network Filesystem options DDB #options DEVICE_POLLING --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=PICO5 # # $FreeBSD: src/release/picobsd/bridge/PICOBSD,v 1.12 2001/10/01 17:32:43 luigi Exp $ # # Line starting with #PicoBSD contains PicoBSD build parameters #marker def_sz init MFS_inodes floppy_inodes #PicoBSD 3200 init 8192 32768 options MD_ROOT_SIZE=3200 # same as def_sz hints "PICOBSD.hints" machine i386 #cpu I386_CPU # we do not want this on current... #cpu I486_CPU cpu I586_CPU cpu I686_CPU ident PICOBSD maxusers 20 #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking #options INET6 options FFS #Berkeley Fast Filesystem #options BOOTP #Use BOOTP to obtain IP address/hostname options MD_ROOT #MD is a potential root device #options NFS #Network Filesystem #options NFS_ROOT #NFS usable as root device, NFS required #options MSDOSFS #MSDOS Filesystem #options CD9660 #ISO 9660 Filesystem #options CD9660_ROOT #CD-ROM usable as root, CD9660 required #options DEVFS #Device Filesystem #options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options DDB options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT # divert (for natd) options PCI_QUIET #quiets PCI code on chipset settings # Support for bridging and bandwidth limiting options DUMMYNET options BRIDGE options HZ=1000 options NMBCLUSTERS=8192 device isa device pci # Floppy drives device fdc # ATA and ATAPI devices #device ata #device atadisk # ATA disk drives #device atapicd # ATAPI CDROM drives #options ATA_STATIC_ID #Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc 1 # At keyboard controller device atkbd #device psm # do we need the mouse ?? device vga # VGA screen # syscons is the default console driver, resembling an SCO console device sc 1 # Floating point support - do not disable. device npx # Serial (COM) ports device sio # Audio support #device pcm # PCCARD (PCMCIA) support #device card # pccard bus #device pcic # PCMCIA bridge # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device # # The following Ethernet NICs are all PCI devices. # device miibus #device de # DEC/Intel DC21x4x (``Tulip'') device lnc device fxp # Intel EtherExpress PRO/100B (82557, 82558) device xl # 3Com device rl # RealTek 8129/8139 device vx # 3Com 3c590, 3c595 (``Vortex'') #device wx # Intel Gigabit Ethernet Card (``Wiseman'') device dc # DEC/Intel 21143 and various workalikes device ed device sis device loop # Network loopback device ether # Ethernet support device tun # Packet tunnel. #device vn #Vnode driver (turns a file into a device) device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" #device gif 4 # IPv6 and IPv4 tunneling #device faith 1 # IPv6-to-IPv4 relaying (translation) #device tap # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter #options DEVICE_POLLING --tThc/1wpZn/ma/RB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 10: 0: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from savvyworld.net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id 7F0A737B416 for ; Thu, 13 Dec 2001 09:59:55 -0800 (PST) Received: (from root@localhost) by savvyworld.net (8.11.6/8.11.4) id fBDHxpB97725; Thu, 13 Dec 2001 09:59:51 -0800 (PST) (envelope-from eculp@EnContacto.Net) Received: from 64.173.182.155 ( [64.173.182.155]) as user eculp@EnContacto.Net by Mail.SavvyWorld.Net with HTTP; Thu, 13 Dec 2001 09:59:51 -0800 Message-ID: <1008266391.3c18ec9761e01@Mail.SavvyWorld.Net> Date: Thu, 13 Dec 2001 09:59:51 -0800 From: Edwin Culp To: Emiel Kollof Cc: current@FreeBSD.Org Subject: Re: dhclient References: <1008252932.3c18b80413c6e@Mail.SavvyWorld.Net> <20011213151727.GC658@laptop.hackerheaven.org> In-Reply-To: <20011213151727.GC658@laptop.hackerheaven.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 64.173.182.155 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Emiel, Thanks a lot for the feedback. I have to look further. Hmmm... Maybe it is my dhcp server but the problem originated with the excite@home service change to attbi.com and their dhcp. Neither work:-( ed Quoting Emiel Kollof : > * Edwin Culp (eculp@EnContacto.Net) wrote: > > Is anyone using dhclient successfully with Current of the last week or > so? > > I don't use it all the time but I have been trying for the last couple of > > days without success. > > > > It accesses the server and changes the interface ip to 0.0.0.0 netmask > > 255.255.255.255. > > No problems here, I just made world and kernel yesterday night (or this > morining, depends on how you put it :) after a bout of cvsupping. > > FreeBSD tiamat.ipv6.hackerheaven.org 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Thu > Dec 13 04:08:33 CET 2001 > root@tiamat.ipv6.hackerheaven.org:/usr/obj/usr/src/sys/TIAMAT i386 > > dhclient works and acks fine for me. > > Cheers, > Emiel > -- > Are you a turtle? > --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 10: 4:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from savvyworld.net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id D50EE37B416 for ; Thu, 13 Dec 2001 10:04:10 -0800 (PST) Received: (from root@localhost) by savvyworld.net (8.11.6/8.11.4) id fBDI42P97784; Thu, 13 Dec 2001 10:04:02 -0800 (PST) (envelope-from eculp@EnContacto.Net) Received: from 64.173.182.155 ( [64.173.182.155]) as user eculp@EnContacto.Net by Mail.SavvyWorld.Net with HTTP; Thu, 13 Dec 2001 10:04:01 -0800 Message-ID: <1008266641.3c18ed9202dfb@Mail.SavvyWorld.Net> Date: Thu, 13 Dec 2001 10:04:02 -0800 From: Edwin Culp To: David Wolfskill Cc: current@FreeBSD.ORG Subject: Re: dhclient References: <200112131525.fBDFPKO60377@bunrab.catwhisker.org> In-Reply-To: <200112131525.fBDFPKO60377@bunrab.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 64.173.182.155 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks, David. I'm going to have to go through the whole troubleshooting process. Both the server and the client, my laptop, are running current and to make it worse I did a portupgrade -Rria on both since I used dhcp the last time. At least I know that it should work:-) Thanks, again. ed Quoting David Wolfskill : > >Date: Thu, 13 Dec 2001 06:15:32 -0800 > >From: Edwin Culp > > >Is anyone using dhclient successfully with Current of the last week or so? > > Sure; hadn't noticed any problems with it. > > >I don't use it all the time but I have been trying for the last couple of > >days without success. > > >It accesses the server and changes the interface ip to 0.0.0.0 netmask > >255.255.255.255. > > Odd. Looks like symptom of a failure to get a lease (to me, though I'm > not an expert in DHCP). Do you have available IP addresses to hand out? > Are you sure the NIC is operating properly? (E.g., can you put it in > promiscuous mode & see traffic on the net, via tcpdump or ethereal?) > > (I've been tracking both -STABLE & -CURRENT daily(*), both on my laptop > (which is a DHCP client) and my build machine (which isn't) for several > months now....) > > * OK; modulo the occasional breakage. But that's been pretty rare -- > even in -CURRENT, for me. > > Cheers, > david > -- > David H. Wolfskill david@catwhisker.org > I believe it would be irresponsible (and thus, unethical) for me to advise, > recommend, or support the use of any product that is or depends on any > Microsoft product for any purpose other than personal amusement. > --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 10:39:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DF48437B416 for ; Thu, 13 Dec 2001 10:39:07 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBDId7v70103; Thu, 13 Dec 2001 10:39:07 -0800 (PST) (envelope-from dillon) Date: Thu, 13 Dec 2001 10:39:07 -0800 (PST) From: Matthew Dillon Message-Id: <200112131839.fBDId7v70103@apollo.backplane.com> To: Luigi Rizzo Cc: current@FreeBSD.ORG Subject: Re: -current vs. -stable network performance References: <20011212224206.D35108@iguana.aciri.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've noticed that -current has much lower TCP performance. I haven't had time to investigate it but I presume there is some overhead somewhere that is killing it. -Matt :Hi, :I am testing the forwarding performance of CURRENT vs. STABLE :(both more or less up to date, unmodified, with the latest performance :patches to the "dc" driver, which I am using) and I am having some :surprises. : :STABLE can forward approx 125Kpps, whereas CURRENT tops at approx 80Kpps. : :This is on the same hardware, 750MHz Athlon, fastforwarding enabled, :a 4-port 21143 card, one input driven with a stream of up to 148Kpps :(64 bytes each). : :Ability to transmit seems roughly the same (in both cases 138Kpps), :and lack of CPU does not seem to be the problem (at least for :CURRENT), so I am suspecting some difference in the initialization :of PCI parameters, such as burst size etc, but I am unclear on :where to look at. Any ideas ? : : cheers : luigi :----------------------------------+----------------------------------------- : Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 11:13:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id A3DD237B416 for ; Thu, 13 Dec 2001 11:13:09 -0800 (PST) Received: from bmah.dyndns.org ([12.233.149.189]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011213191309.MZDY5010.rwcrmhc51.attbi.com@bmah.dyndns.org>; Thu, 13 Dec 2001 19:13:09 +0000 Received: (from bmah@localhost) by bmah.dyndns.org (8.11.6/8.11.6) id fBDJD8d38312; Thu, 13 Dec 2001 11:13:08 -0800 (PST) (envelope-from bmah) Message-Id: <200112131913.fBDJD8d38312@bmah.dyndns.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Luigi Rizzo , current@FreeBSD.ORG Subject: Re: -current vs. -stable network performance In-Reply-To: <200112131839.fBDId7v70103@apollo.backplane.com> References: <20011212224206.D35108@iguana.aciri.org> <200112131839.fBDId7v70103@apollo.backplane.com> Comments: In-reply-to Matthew Dillon message dated "Thu, 13 Dec 2001 10:39:07 -0800." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1567691784P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 13 Dec 2001 11:13:08 -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --==_Exmh_-1567691784P Content-Type: text/plain; charset=us-ascii If memory serves me right, Matthew Dillon wrote: > I've noticed that -current has much lower TCP performance. I haven't > had time to investigate it but I presume there is some overhead > somewhere that is killing it. Here's a data point but I'm not sure how useful it is. At the start of December I was using tcpreplay to spew packets from a stored trace into a testbed network as fast as the CPU could go, and I saw: 5-CURRENT (11/19): 9244 pps, 35.6 Mbps 4-STABLE (late November): 21827 pps, 84 Mbps These measurements were on the same machine, which is a 1.7 GHz P4, 512MB RAM, ATA disk. Network interface was a four-port dc-type card. GENERIC kernels. These are "typical" numbers, but fairly repeatable over various trace files I was using. At the time I was more interested in being able to get packets on the network quickly than in why there was a performance difference, so I just plopped 4-STABLE on the machine without doing any other investigation. Bruce. --==_Exmh_-1567691784P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE8GP3E2MoxcVugUsMRAu88AJ9Rg+aRhCHEffS7jjHuJhdK4Pa82QCg6X9m fESGtg1i5rSEDCyj5R5HJsA= =AoN6 -----END PGP SIGNATURE----- --==_Exmh_-1567691784P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 11:28:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id D2A4637B41A for ; Thu, 13 Dec 2001 11:28:02 -0800 (PST) Received: (qmail 31745 invoked from network); 13 Dec 2001 19:28:01 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Dec 2001 19:28:01 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011213215212.O277-100000@gamplex.bde.org> Date: Thu, 13 Dec 2001 11:27:56 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: Patch Review: i386 asm cleanups in the kernel Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 13-Dec-01 Bruce Evans wrote: >> --- i386/i386/identcpu.c 30 Nov 2001 11:57:23 -0000 1.96 >> +++ i386/i386/identcpu.c 6 Dec 2001 07:58:25 -0000 >> @@ -115,10 +115,11 @@ >> static void >> do_cpuid(u_int ax, u_int *p) >> { >> + >> + p[0] = ax; >> __asm __volatile( >> "cpuid" >> - : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) >> - : "0" (ax) >> + : "+a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) >> ); >> } >> > > "0" here was bogus. Just replace it by "a". So use "a" twice and gcc will get that right? >> - : "=a" (low), "=d" (high) \ >> - : "0" (low), "1" (high) \ >> - : "cx", "bx") >> + : "+a" (low), "+d" (high) \ >> + : : "ecx", "ebx") > > Weren't the register names in the clobber list the normal ones? I was just being pedantic since we aren't just clobbering the low words of the registers. >> @@ -938,7 +935,7 @@ >> "movl 4(%0),%%eax ; adcl %%eax,4(%0)\n\t" >> "movl 8(%0),%%eax ; adcl %%eax,8(%0)\n\t" >> "movl 12(%0),%%eax ; adcl %%eax,12(%0)" >> - ::"r" (c):"ax"); >> + : :"r" (c):"eax", "memory"); >> } >> >> static void > > This should use output operands c[0]..c[3], not a general "memory" clobber. Ok. >> [... more suboptimal "memory" clobbers] I changed the simple ones, but not the harder ones. (gcc doesn't like having more than 10 operands, even if they are memory or immediates) > I wouldn't trust all the little changes to math_emulate.c without runtime > testing. It won't be tested by using it in normal operation. Ok. I won't commit it until it is tested. >> Index: i386/include/bus_pc98.h >> =================================================================== >> RCS file: /usr/cvs/src/sys/i386/include/bus_pc98.h,v >> retrieving revision 1.19 >> diff -u -r1.19 bus_pc98.h >> --- i386/include/bus_pc98.h 7 Oct 2001 10:04:18 -0000 1.19 >> +++ i386/include/bus_pc98.h 7 Dec 2001 19:10:37 -0000 >> @@ -203,11 +203,10 @@ >> \ >> __asm __volatile("call *%2" \ >> :"=a" (result), \ >> - "=d" (offset) \ >> + "+d" (offset) \ >> :"o" (bsh->bsh_bam.bs_read_##BWN), \ >> - "b" (bsh), \ >> - "1" (offset) \ >> - ); \ >> + "b" (bsh) \ >> + :"ecx","memory"); \ >> \ >> return result; \ >> } > > It's surprising that the missing "ecx" in lots of clobber lists in this > file didn't cause problems. It depends on what the functions do. If they are written in asm, they might be preserving temporary registers rather than trashing them. I was just changing the clobbers to assume that only call-safe registers were preserved. >> - __asm __volatile("bsfl %0,%0" : "=r" (result) : "0" (mask)); >> + __asm __volatile("bsfl %0,%0" : "+r" (result)); >> return (result); >> } > > "0" here was bogus, except we abuse the same operand for input and output. > I checked that gcc does the right thing (reuse the input register for > output if the input operand becomes dead) with a non-hand-optimized version: > > __asm __volatile("bsfl %1,%0" : "=r" (result) : "r" (mask)); > ... > main() { return bsfl(23); } > > "rm" (mask) works too. Ok, that's simpler then. > The other changes seem to be OK. I checked about 1/4 of them. Ok, well, I've updated the patch at the same location. > Bruce -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 12:19: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 6816737B419; Thu, 13 Dec 2001 12:18:48 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id HAA19324; Fri, 14 Dec 2001 07:18:45 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01KBUM081E9CVMB7FB@cim.alcatel.com.au>; Fri, 14 Dec 2001 07:18:43 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id fBDKIgr39776; Fri, 14 Dec 2001 07:18:42 +1100 Content-return: prohibited Date: Fri, 14 Dec 2001 07:18:42 +1100 From: Peter Jeremy Subject: Re: Patch Review: i386 asm cleanups in the kernel In-reply-to: <20011206201803.Q14784-100000@gamplex.bde.org>; from bde@zeta.org.au on Thu, Dec 06, 2001 at 08:40:29PM +1100 To: Bruce Evans Cc: John Baldwin , current@FreeBSD.ORG Mail-Followup-To: Bruce Evans , John Baldwin , current@FreeBSD.ORG Message-id: <20011214071841.Y73243@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20011206201803.Q14784-100000@gamplex.bde.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 06, 2001 at 08:40:29PM +1100, Bruce Evans wrote: >On Wed, 5 Dec 2001, John Baldwin wrote: > >> On 05-Dec-01 Bruce Evans wrote: >> >> - Add missing "cc" clobbers in constraints >> > >> > Does this have any effect (for i386's) except to create a lot of clutter >> > Even i386.md doesn't use it. gcc.info says: >> > ... >> > None of i386.md, alpha.md or sparc.md do this. i386's and alphas have a >> > cc0 register, but it is only mentioned for instructsions whose main (only?) >> > effect is to to set the condition codes. >> >> Hmm, so how does one clobber "eflags" if "cc" isn't "eflags"? > >Neither seems to be in gcc/config/i386/i386.h. I think "cc" is generic, so >using it in clobber lists is not wrong. To quote the "Extended Asm" section of the GCC info file: " If your assembler instruction can alter the condition code register, add `cc' to the list of clobbered registers. GNU CC on some machines represents the condition codes as a specific hardware register; `cc' serves to name this register. On other machines, the condition code is handled differently, and specifying `cc' has no effect. But it is valid no matter what the machine." >> Look at PR >> gnu/32365 which seems to indicate that "cc" does, in fact, represent "eflags" >> in the clobber list. My understanding (from the above quote) is that "cc" is a generic virtual register used to represent a processor's condition codes - independent of how the processor actually implements conditions. "eflags" is the physical i386 register containing the condition codes (amongst other things). >That gives a hint about where to look for the clobbering conventions. From >gcc/config/i386/i386.c: ... >Application asms are apparently in the "All else" set. This appears to come down to a case of the generic documentation requiring "cc" clobbers, whereas the current implementation on the i386 doesn't. >The bug in the PR could probably be fixed without updating this function >by using leal instead of addl to adjust the stack. Good point. There seem to be 3 options: 1a) Modify notice_update_cc() to recognize the RTL associated with mov[sdx]f_push and clobber the condition codes in that case. This is the approach I suggested in the PR. 1b) Modify the mov[sdx]f_push templates in i386.md to do a CC_STATUS_INIT. I have implemented this and it seems to work. I'll post it into the PR at some stage. 2) Modify the mov[sdx]f_push templates in i386.md to use leal ISO subl. This is probably the best option since it will preserve the condition code. Unfortunately, I'm not sure how to define an RTX for "-4(%esp)", a quick rummage suggests adj_offsettable_operand(), but that doesn't allow negative offsets. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 16:17:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id DB86C37B417 for ; Thu, 13 Dec 2001 16:17:36 -0800 (PST) Received: (qmail 24809 invoked from network); 14 Dec 2001 00:17:36 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Dec 2001 00:17:36 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 13 Dec 2001 16:17:31 -0800 (PST) From: John Baldwin To: John Baldwin Subject: Re: Patch Review: i386 asm cleanups in the kernel Cc: current@FreeBSD.org, Bruce Evans Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 13-Dec-01 John Baldwin wrote: >>> static void >>> do_cpuid(u_int ax, u_int *p) >>> { >>> + >>> + p[0] = ax; >>> __asm __volatile( >>> "cpuid" >>> - : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) >>> - : "0" (ax) >>> + : "+a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) >>> ); >>> } >>> >> >> "0" here was bogus. Just replace it by "a". > > So use "a" twice and gcc will get that right? gcc30 chokes on it: ../../../i386/i386/identcpu.c: In function `do_cpuid': ../../../i386/i386/identcpu.c:119: Can't find a register in class `AREG' while reloading `asm'. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 16:48:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 67BA637B405 for ; Thu, 13 Dec 2001 16:48:20 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBE0mJs43228; Thu, 13 Dec 2001 16:48:19 -0800 (PST) (envelope-from rizzo) Date: Thu, 13 Dec 2001 16:48:19 -0800 From: Luigi Rizzo To: current@freebsd.org Subject: problems compiling various things... Message-ID: <20011213164819.I42454@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG With a freshly cvsupped version of CURRENT, cross-compiled on a 4.3 box, (after the usual stdio.h fix related to the FILE handling), I am having problems compiling several programs, with errors such as the ones attached at the end. In most cases they choke on missing prototype for main(). This did not use to occur with CURRENT as of (roughly) 5-6 weeks ago, but then I have not followed closely what was going on, likely a makefile config change. Anyways, I wonder: * is this related to my cross-compilation environment ? * if not, what is the proper fix, use an ANSI declaration int main(int argc, char *argv[]) or forget that it is almost 2002 and use int main __P((int, char *[])); There are several commands affected by this, such as usr.sbin/chown bin/rm usr.sbin/dev_mkdb and maybe others that I am not compiling in my picobsd configuration. thanks luigi cc -nostdinc -I/home/xorpc/u2/homes/rizzo/HEAD/src/../usr/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /home/xorpc/u2/homes/rizzo/HEAD/src/usr.sbin/chown/chown.c cc1: warnings being treated as errors /home/xorpc/u2/homes/rizzo/HEAD/src/usr.sbin/chown/chown.c:75: warning: function declaration isn't a prototype *** Error code 1 Stop in /home/xorpc/u2/homes/rizzo/HEAD/src/usr.sbin/chown. ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 16:59:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 6235A37B433 for ; Thu, 13 Dec 2001 16:59:43 -0800 (PST) Received: (qmail 19446 invoked from network); 14 Dec 2001 00:59:42 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Dec 2001 00:59:42 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011213164819.I42454@iguana.aciri.org> Date: Thu, 13 Dec 2001 16:59:37 -0800 (PST) From: John Baldwin To: Luigi Rizzo Subject: RE: problems compiling various things... Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 14-Dec-01 Luigi Rizzo wrote: > With a freshly cvsupped version of CURRENT, cross-compiled on a > 4.3 box, (after the usual stdio.h fix related to the FILE handling), > I am having problems compiling several programs, with errors such > as the ones attached at the end. Just use WARNS=0 or some such in your build. Or NO_WERROR=yes. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 17: 4:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by hub.freebsd.org (Postfix) with ESMTP id E1B6837B416; Thu, 13 Dec 2001 17:04:22 -0800 (PST) Received: from dagger.cc.vt.edu (IDENT:mirapoint@dagger-lb.cc.vt.edu [10.1.1.11]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id fBE14M1295752; Thu, 13 Dec 2001 20:04:22 -0500 (EST) Received: from enterprise.muriel.penguinpowered.com (hc652647d.dhcp.vt.edu [198.82.100.125]) by dagger.cc.vt.edu (Mirapoint) with ESMTP id AOA72495; Thu, 13 Dec 2001 20:04:21 -0500 (EST) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.5.2.FreeBSD:20011213200421:56094=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <200112132346.fBDNkjb93484@freefall.freebsd.org> Date: Thu, 13 Dec 2001 20:04:21 -0500 (EST) From: Mike Heffner To: Mike Heffner Subject: Re: cvs commit: src/usr.bin/ftp Makefile cmds.c cmdtab.c complet Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, FreeBSD-current Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.5.2.FreeBSD:20011213200421:56094=_ Content-Type: text/plain; charset=us-ascii On 13-Dec-2001 Mike Heffner wrote: | mikeh 2001/12/13 15:46:45 PST | | Modified files: | usr.bin/ftp Makefile | Removed files: | usr.bin/ftp cmds.c cmdtab.c complete.c domacro.c | extern.h fetch.c ftp.1 ftp.c ftp_var.h | main.c pathnames.h ruserpass.c util.c | Log: | Connect lukemftp to the build as the default ftp client. Lukemftp | supports most of the previous features of FreeBSD ftp, but has been | better maintained and includes new features. Short summary of differences: New features: *) More automation methods *) Better standards compliance *) Transfer rate throttling (binary mode only currently) *) Customizable commandline prompt Differences/Losses: *) FTP_PASSIVE_MODE vs. FTP_MODE *) -4/-6 for forcing IPV4/IPV6 Mike -- Mike Heffner Blacksburg, VA --_=XFMail.1.5.2.FreeBSD:20011213200421:56094=_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8GVAVFokZQs3sv5kRAkxIAJ4t4Xn2rXiDGk9hvQ8s685HLy78bQCfb478 hbceAaZYmUbYqJ8Qu4bhdts= =g/ug -----END PGP SIGNATURE----- --_=XFMail.1.5.2.FreeBSD:20011213200421:56094=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 17:15:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 6A09337B416; Thu, 13 Dec 2001 17:14:59 -0800 (PST) Received: from viasoft.com.cn (davidwnt.viasoft.com.cn [192.168.1.239]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id JAA07309; Fri, 14 Dec 2001 09:22:35 +0800 Message-ID: <3C195147.7000605@viasoft.com.cn> Date: Fri, 14 Dec 2001 09:09:27 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: John Baldwin Cc: Bruce Evans , current@FreeBSD.ORG Subject: Re: Patch Review: i386 asm cleanups in the kernel References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I persist with adding "cc", because it does not hurt anything. -- David Xu John Baldwin wrote: >On 13-Dec-01 Bruce Evans wrote: > >>>--- i386/i386/identcpu.c 30 Nov 2001 11:57:23 -0000 1.96 >>>+++ i386/i386/identcpu.c 6 Dec 2001 07:58:25 -0000 >>>@@ -115,10 +115,11 @@ >>> static void >>> do_cpuid(u_int ax, u_int *p) >>> { >>>+ >>>+ p[0] = ax; >>> __asm __volatile( >>> "cpuid" >>>- : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) >>>- : "0" (ax) >>>+ : "+a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) >>> ); >>> } >>> >>"0" here was bogus. Just replace it by "a". >> > >So use "a" twice and gcc will get that right? > >>>- : "=a" (low), "=d" (high) \ >>>- : "0" (low), "1" (high) \ >>>- : "cx", "bx") >>>+ : "+a" (low), "+d" (high) \ >>>+ : : "ecx", "ebx") >>> >>Weren't the register names in the clobber list the normal ones? >> > >I was just being pedantic since we aren't just clobbering the low words of the >registers. > > >>>@@ -938,7 +935,7 @@ >>> "movl 4(%0),%%eax ; adcl %%eax,4(%0)\n\t" >>> "movl 8(%0),%%eax ; adcl %%eax,8(%0)\n\t" >>> "movl 12(%0),%%eax ; adcl %%eax,12(%0)" >>>- ::"r" (c):"ax"); >>>+ : :"r" (c):"eax", "memory"); >>> } >>> >>> static void >>> >>This should use output operands c[0]..c[3], not a general "memory" clobber. >> > >Ok. > >>>[... more suboptimal "memory" clobbers] >>> > >I changed the simple ones, but not the harder ones. (gcc doesn't like having >more than 10 operands, even if they are memory or immediates) > >>I wouldn't trust all the little changes to math_emulate.c without runtime >>testing. It won't be tested by using it in normal operation. >> > >Ok. I won't commit it until it is tested. > >>>Index: i386/include/bus_pc98.h >>>=================================================================== >>>RCS file: /usr/cvs/src/sys/i386/include/bus_pc98.h,v >>>retrieving revision 1.19 >>>diff -u -r1.19 bus_pc98.h >>>--- i386/include/bus_pc98.h 7 Oct 2001 10:04:18 -0000 1.19 >>>+++ i386/include/bus_pc98.h 7 Dec 2001 19:10:37 -0000 >>>@@ -203,11 +203,10 @@ >>> \ >>> __asm __volatile("call *%2" \ >>> :"=a" (result), \ >>>- "=d" (offset) \ >>>+ "+d" (offset) \ >>> :"o" (bsh->bsh_bam.bs_read_##BWN), \ >>>- "b" (bsh), \ >>>- "1" (offset) \ >>>- ); \ >>>+ "b" (bsh) \ >>>+ :"ecx","memory"); \ >>> \ >>> return result; \ >>> } >>> >>It's surprising that the missing "ecx" in lots of clobber lists in this >>file didn't cause problems. >> > >It depends on what the functions do. If they are written in asm, they might be >preserving temporary registers rather than trashing them. I was just changing >the clobbers to assume that only call-safe registers were preserved. > >>>- __asm __volatile("bsfl %0,%0" : "=r" (result) : "0" (mask)); >>>+ __asm __volatile("bsfl %0,%0" : "+r" (result)); >>> return (result); >>> } >>> >>"0" here was bogus, except we abuse the same operand for input and output. >>I checked that gcc does the right thing (reuse the input register for >>output if the input operand becomes dead) with a non-hand-optimized version: >> >> __asm __volatile("bsfl %1,%0" : "=r" (result) : "r" (mask)); >> ... >> main() { return bsfl(23); } >> >>"rm" (mask) works too. >> > >Ok, that's simpler then. > >>The other changes seem to be OK. I checked about 1/4 of them. >> > >Ok, well, I've updated the patch at the same location. > >>Bruce >> > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 17:30: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 0762937B41A for ; Thu, 13 Dec 2001 17:29:59 -0800 (PST) Received: (qmail 17375 invoked from network); 14 Dec 2001 01:29:57 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Dec 2001 01:29:57 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3C195147.7000605@viasoft.com.cn> Date: Thu, 13 Dec 2001 17:29:52 -0800 (PST) From: John Baldwin To: David Xu Subject: Re: Patch Review: i386 asm cleanups in the kernel Cc: current@FreeBSD.ORG, Bruce Evans Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 14-Dec-01 David Xu wrote: > I persist with adding "cc", because it does not hurt anything. It doesn't do anything either except add repo bloat and obfuscate the code a bit more. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 17:40:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 3C5C837B41B for ; Thu, 13 Dec 2001 17:40:07 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011214014006.YYIC5010.rwcrmhc51.attbi.com@InterJet.elischer.org> for ; Fri, 14 Dec 2001 01:40:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA17746 for ; Thu, 13 Dec 2001 17:23:12 -0800 (PST) Date: Thu, 13 Dec 2001 17:23:11 -0800 (PST) From: Julian Elischer To: current@freebsd.org Subject: change to ZALLOC(9) man page Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG By my reading of the code I would like to make the following changes to the documentation for the zone(9) man page; Index: zone.9 =================================================================== RCS file: /home/ncvs/src/share/man/man9/zone.9,v retrieving revision 1.6 diff -u -r1.6 zone.9 --- zone.9 1 Oct 2001 16:09:25 -0000 1.6 +++ zone.9 14 Dec 2001 01:20:08 -0000 @@ -63,8 +63,11 @@ aren't, and provides functions for allocating items from the zone and for releasing them back (which makes them available for later use). .Pp -The zone allocator stores state information inside the items proper, -so structures that will be managed by the zone allocator must reserve +The zone allocator stores state information inside the items proper +while they are not allocated, +so structures that will be managed by the zone allocator +and wish to use the type stable property of zones by leaving some fields +pre-filled between allocations, must reserve two pointers at the very beginning for internal use by the zone allocator, as follows: .Bd -literal @@ -74,6 +77,12 @@ /* rest of structure */ }; .Ed +.Pp +Alternatively they should assume those entries corrupted +after each allocation. After the first allocation of an item, +it will bave been cleared to zeroes, however subsequent allocations +will retain the contents as of the last free, with the exception of the +fields mentionned above. .Pp Zones are created in one of two fashions, depending how far along the boot process is. There is always the chance I'm reading the code wrongly so if you think I'm smoking something, let me know, because there is code in the kernel relying on the fact that these changes are correct. (why I made them). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 18:13:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by hub.freebsd.org (Postfix) with ESMTP id 872BD37B428; Thu, 13 Dec 2001 18:13:21 -0800 (PST) Received: from steiner.cc.vt.edu (IDENT:mirapoint@steiner-lb.cc.vt.edu [10.1.1.14]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id fBE2DL1306047; Thu, 13 Dec 2001 21:13:21 -0500 (EST) Received: from enterprise.muriel.penguinpowered.com (hc652647d.dhcp.vt.edu [198.82.100.125]) by steiner.cc.vt.edu (Mirapoint) with ESMTP id AGW55165; Thu, 13 Dec 2001 21:13:19 -0500 (EST) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.5.2.FreeBSD:20011213211319:56094=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: Date: Thu, 13 Dec 2001 21:13:19 -0500 (EST) From: Mike Heffner To: Mike Heffner Subject: Re: cvs commit: src/usr.bin/ftp Makefile cmds.c cmdtab.c complet Cc: FreeBSD-current , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.5.2.FreeBSD:20011213211319:56094=_ Content-Type: text/plain; charset=us-ascii On 14-Dec-2001 Mike Heffner wrote: | | Differences/Losses: | | *) FTP_PASSIVE_MODE vs. FTP_MODE s/FTP_MODE/FTPMODE As a followup clarification, ftp(1) will attempt to use passive mode by default, and fall back to active mode. To achieve the old default behavior (active mode) set FTPMODE=active. Mike -- Mike Heffner Blacksburg, VA --_=XFMail.1.5.2.FreeBSD:20011213211319:56094=_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8GWA/FokZQs3sv5kRAvRyAKCL/tUOH0DY0oZi+Xu2K4VcE1y01wCgkkzG TSRDIk012LsCqXsWWEidaqM= =Ghea -----END PGP SIGNATURE----- --_=XFMail.1.5.2.FreeBSD:20011213211319:56094=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 22:39: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from iitkgp.iitkgp.ernet.in (iitkgp.iitkgp.ernet.in [203.197.98.10]) by hub.freebsd.org (Postfix) with ESMTP id DFBDB37B416; Thu, 13 Dec 2001 22:38:46 -0800 (PST) Received: from cse.iitkgp.ernet.in (IDENT:root@cse.iitkgp.ernet.in [144.16.192.57]) by iitkgp.iitkgp.ernet.in (8.9.3/8.9.3) with ESMTP id CAA16780; Fri, 14 Dec 2001 02:06:38 -0500 (GMT) Received: (from brucem@localhost) by cse.iitkgp.ernet.in (8.11.0/8.8.7) id fBE6jsm06509; Fri, 14 Dec 2001 12:15:54 +0530 Date: Fri, 14 Dec 2001 12:15:54 +0530 From: Bruce Montague Message-Id: <200112140645.fBE6jsm06509@cse.iitkgp.ernet.in> To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: sound/pci/ich drvr hang on Dell OptiPlex 150 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Two solid problems occur with the sound/pci/ich driver for the ICH2 (Intel 82801BA I/O Controller Hub) on Dell Optiplex 150 PCs. One problem (a fatal hang) occurs under 4.4-RELEASE, 4.4-STABLE, and 5.0-CURRENT (as of yesterday). I have a temporary fix for the fatal hang, but don't claim to understand the Intel ICH2 enough to know if it is "universal" (e.g., the right thing.). I doubt it's comprehensive enough. Problems: 1) Systems hang on boot (perhaps half the time) due to a never-cleared interrupt condition. The audio device sometimes comes up with an initial error condition (X_SR_DCH); this interrupt is never "dismissed/cleared" by the ich_intr() interrupt handler; ich_intr() livelocks (runs constantly). I have a quick ugly work-around fix (listed below) for this. Maybe the real fix would involve the device init routine. 2) Microphone input doesn't work, the error "pcm0: record interrupt timeout, channel dead" always occurs (it doesn't look like any channel other than PCM_PLAY is ever even triggered in the 4.4-RELEASE or 4.4-STABLE code). The microphone works OK in 5.0-CURRENT. This problem is just due to the phase-in of the features in the sound/pci/ich driver code and appears to be expected behavior when looked at long enough... The hang-on boot problem is potentially serious because it is difficult to identify and precludes unattended reboot (in normal use one can just attempt reboot until the device comes up without the DCH error, i.e., "clean"). Here is how I kludge/fixed the hang on boot problem (again, I'm not claiming this is the "right" fix, but the systems have never hung on boot with it in, and without it they hang about half to a third the time). =========================================== /*--- BRM ---*/ void ich_err_reset( struct sc_info *sc, struct sc_chinfo *ch, int i ); void ich_err_reset( struct sc_info *sc, struct sc_chinfo *ch, int i ) { u_int32_t gc,gs; gc = ich_rd(sc, ICH_REG_GLOB_CNT, 2); /* printf( " GC=%x ", gc ); */ if( gc & ICH_GLOB_CTL_PRES ) { gs = ich_rd(sc, ICH_REG_GLOB_STA, 2); /* printf( " GS=%x ", gs ); */ ich_wr( sc, ICH_REG_GLOB_STA, gs, 2 ); } } /*--- End BRM ---*/ static void ich_intr(void *p) { struct sc_info *sc = (struct sc_info *)p; struct sc_chinfo *ch; u_int32_t cbi, lbi, lvi, st; int i; for (i = 0; i < 3; i++) { ch = &sc->ch[i]; /* check channel status */ st = ich_rd(sc, ch->regbase + ICH_REG_X_SR, 2); #if 1 /*--- BRM ---*/ if( st & (ICH_X_SR_FIFOE | ICH_X_SR_DCH ) ) { ich_err_reset( sc, ch, i ); /* printf( "ER!" ); */ } /*--- end BRM ---*/ #endif ...etc.... =========================================== This checks the ICH_REG_X_DCH (DMA Controller Halted) bit. If this error bit is set, a read of the Global control reg is done to see if a "primary resume" interrupt is pending; if so a read/write of the global status reg seems to clear the interrupt... Other than checking for FIFO overrun, this interrupt handler appears to do no error checking, so when the device comes up with DMA Halted condition asserted a livelock hang occurs... (I'm not sure I even know what a "primary resume" interrupt on the audio ICH device is, although it sounds maybe like an interesting corner case; apologies for lack of time to slowly RTFM :) =============== 5.0-CURRENT ============================ >uname -a FreeBSD dellcur 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Dec 13 16:47:16 IST 2001 root@:/usr/obj/usr/src/sys/GENERIC i386 >cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xd800, 0xdc40 irq 10 bufsz 16384 (1p/2r/0v channels duplex default) >dmesg | egrep irq agp0: mem 0xff000000-0xff07ffff,0xf8000000-0xfbffffff irq 9 at device 2.0 on pci0 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec80-0xecff mem 0xfdfffc00-0xfdfffc7f irq 11 at device 12.0 on pci1 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xff80-0xff9f irq 11 at device 31.2 on pci0 uhci1: port 0xff60-0xff7f irq 11 at device 31.4 on pci0 pcm0: port 0xdc40-0xdc7f,0xd800-0xd8ff irq 10 at device 31.5 on pci0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio1 port 0x2f8-0x2ff irq 3 on acpi0 ppc0 port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ================ 4.4-STABLE ===================== >uname -a FreeBSD dell2 4.4-STABLE FreeBSD 4.4-STABLE #0: Tue Dec 11 11:37:12 IST 2001 root@dell2:/usr/src/sys/compile/DELL2 i386 >cat /dev/sndstat FreeBSD Audio Driver (newpcm) Dec 11 2001 11:36:46 Installed devices: pcm0: at io 0xd800, 0xdc40 irq 10 (1p/2r/0v channels duplex) >dmesg | grep irq agp0: mem 0xff000000-0xff07ffff,0xf8000000-0xfbffffff irq 9 at device 2.0 on pci0 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec80-0xecff mem 0xfdfffc00-0xfdfffc7f irq 11 at device 12.0 on pci1 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xff80-0xff9f irq 11 at device 31.2 on pci0 pci0: (vendor=0x8086, dev=0x2443) at 31.3 irq 10 uhci1: port 0xff60-0xff7f irq 11 at device 31.4 on pci0 pcm0: port 0xdc40-0xdc7f,0xd800-0xd8ff irq 10 at device 31.5 on pci0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio1 at port 0x2f8-0x2ff irq 3 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 - bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Dec 13 22:44:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id A147C37B416; Thu, 13 Dec 2001 22:44:05 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id fBE6hod26370; Fri, 14 Dec 2001 08:43:50 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200112140643.fBE6hod26370@zibbi.icomtek.csir.co.za> Subject: Re: cvs commit: src/usr.bin/ftp Makefile cmds.c cmdtab.c complet In-Reply-To: from Mike Heffner at "Dec 13, 2001 08:04:21 pm" To: mheffner@vt.edu (Mike Heffner) Date: Fri, 14 Dec 2001 08:43:49 +0200 (SAT) Cc: mikeh@FreeBSD.ORG (Mike Heffner), cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, FreeBSD-current@FreeBSD.ORG (FreeBSD-current) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > On 13-Dec-2001 Mike Heffner wrote: > | mikeh 2001/12/13 15:46:45 PST ... > | Log: > | Connect lukemftp to the build as the default ftp client. Lukemftp > | supports most of the previous features of FreeBSD ftp, but has been > | better maintained and includes new features. > > Short summary of differences: > ... > Differences/Losses: > > *) FTP_PASSIVE_MODE vs. FTP_MODE > *) -4/-6 for forcing IPV4/IPV6 Any chance of getting -4/-6 or something like it, back? It is very useful here in our environment that have a lot of dual-stack machines. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 0:39: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 2EA7737B416; Fri, 14 Dec 2001 00:38:53 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBE8cP140582; Fri, 14 Dec 2001 10:38:25 +0200 (EET) (envelope-from ru) Date: Fri, 14 Dec 2001 10:38:25 +0200 From: Ruslan Ermilov To: Mike Heffner Cc: FreeBSD-current , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/usr.bin/ftp Makefile cmds.c cmdtab.c complet Message-ID: <20011214103825.E35094@sunbay.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 13, 2001 at 09:13:19PM -0500, Mike Heffner wrote: > > On 14-Dec-2001 Mike Heffner wrote: > | > | Differences/Losses: > | > | *) FTP_PASSIVE_MODE vs. FTP_MODE > > s/FTP_MODE/FTPMODE > > As a followup clarification, ftp(1) will attempt to use passive mode by > default, and fall back to active mode. To achieve the old default behavior > (active mode) set FTPMODE=active. > Please fix /etc/login.conf. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 2:11:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 35C1137B405 for ; Fri, 14 Dec 2001 02:11:10 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBEAB9047674; Fri, 14 Dec 2001 02:11:09 -0800 (PST) (envelope-from rizzo) Date: Fri, 14 Dec 2001 02:11:09 -0800 From: Luigi Rizzo To: current@freebsd.org Subject: Solved (Re: -current vs. -stable network performance) Message-ID: <20011214021109.B46985@iguana.aciri.org> References: <20011212224206.D35108@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011212224206.D35108@iguana.aciri.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In case you are interested, I found why CURRENT performed so badly. It turns out that CURRENT still does not have the fix to M_LEADINGSPACE that permits writing into non-shared mbufs. This caused the header of forwarded packets to be pulled up in a separate buffer, and triggered a known (to me at least!) performance bug in the 21143 which wastes about 5us when a packet is split across two descriptor. With the one-line change shown below, forwarding speed goes up to the same values as STABLE. The change below has been committed to STABLE 7 weeks ago, but did not go into CURRENT because there was some disagreement on the semantics of M_LEADINGSPACE. However I would strongly vote for committing this change to CURRENT as well, given the huge performance implications (even if the 21143 were not buggy, not being able to write into clusters hurts a lot of pieces of the networking stack). cheers luigi Index: mbuf.h =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/sys/mbuf.h,v retrieving revision 1.85 diff -u -r1.85 mbuf.h --- mbuf.h 2001/09/30 01:58:35 1.85 +++ mbuf.h 2001/12/14 09:46:28 @@ -360,7 +360,7 @@ */ #define M_LEADINGSPACE(m) \ ((m)->m_flags & M_EXT ? \ - /* (m)->m_data - (m)->m_ext.ext_buf */ 0 : \ + (M_WRITABLE(m) ? (m)->m_data - (m)->m_ext.ext_buf : 0): \ (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \ (m)->m_data - (m)->m_dat) On Wed, Dec 12, 2001 at 10:42:06PM -0800, Luigi Rizzo wrote: > Hi, > I am testing the forwarding performance of CURRENT vs. STABLE > (both more or less up to date, unmodified, with the latest performance > patches to the "dc" driver, which I am using) and I am having some > surprises. > > STABLE can forward approx 125Kpps, whereas CURRENT tops at approx 80Kpps. > > This is on the same hardware, 750MHz Athlon, fastforwarding enabled, > a 4-port 21143 card, one input driven with a stream of up to 148Kpps > (64 bytes each). > > Ability to transmit seems roughly the same (in both cases 138Kpps), > and lack of CPU does not seem to be the problem (at least for > CURRENT), so I am suspecting some difference in the initialization > of PCI parameters, such as burst size etc, but I am unclear on > where to look at. Any ideas ? > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 2:33:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3A29737B416 for ; Fri, 14 Dec 2001 02:33:51 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBEAXbi82556; Fri, 14 Dec 2001 05:33:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 14 Dec 2001 05:33:37 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Edwin Culp Cc: current@FreeBSD.Org Subject: Re: dhclient In-Reply-To: <1008252932.3c18b80413c6e@Mail.SavvyWorld.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 13 Dec 2001, Edwin Culp wrote: > Is anyone using dhclient successfully with Current of the last week or > so? I don't use it all the time but I have been trying for the last > couple of days without success. > > It accesses the server and changes the interface ip to 0.0.0.0 netmask > 255.255.255.255. My -CURRENT dhclient is working just fine on several boxes from Dec 11, 12, and 13. And I guess also 14, given the time :-). As pointed out, 0.0.0.0 is what dhclient will set the interface IP address to when it doesn't have a valid lease currently, and needs to look for one. If it fails to quickly find a lease, it keeps trying, but you actually get a window to see this address on your interface, whereas if it runs quickly, you often won't. Using a packet sniffer can be invaluable in debugging DHCP problems: tcpdump udp port dhcpc or udp port dhcps is useful, but even better is ethereal's ability to decode the DHCP packet in detail, display options cleanly, etc. You might want to try looking to make sure that you're getting a response, and if you are, whether it looks adequate :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 2:34:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id ECC7F37B405 for ; Fri, 14 Dec 2001 02:34:36 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011214103436.LVGE403.rwcrmhc52.attbi.com@peter3.wemm.org> for ; Fri, 14 Dec 2001 10:34:36 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBEAYas51342 for ; Fri, 14 Dec 2001 02:34:36 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 7931438CC; Fri, 14 Dec 2001 02:34:36 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Luigi Rizzo Cc: current@FreeBSD.ORG Subject: Re: Solved (Re: -current vs. -stable network performance) In-Reply-To: <20011214021109.B46985@iguana.aciri.org> Date: Fri, 14 Dec 2001 02:34:36 -0800 From: Peter Wemm Message-Id: <20011214103436.7931438CC@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: [..] > The change below has been committed to STABLE 7 weeks ago, but did > not go into CURRENT because there was some disagreement on the > semantics of M_LEADINGSPACE. However I would strongly vote for > committing this change to CURRENT as well, given the huge performance > implications (even if the 21143 were not buggy, not being able to > write into clusters hurts a lot of pieces of the networking stack). Incidently, this is a poster-child example of why fixes are not to go to -stable first. It leads to exactly this sort of lossage. rev 1.44.2.11: ... This does not go in CURRENT as is: as discussed in -net, M_LEADINGSPACE should not check for writability, just report available space, leaving the check to some other piece of code. Unfortunately, some code in the tree depends on M_LEADINGSPACE checking for writability, and so implementing M_LEADINGSPACE in the correct way also requires to fix the incorrect usage. This is what will be done in CURRENT, but for STABLE, this is probably more than we want, and so we are happy (more or less) with this simple fix. ... How about fixing it for real as described in the commit message? Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 3: 0: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id C97DF37B405 for ; Fri, 14 Dec 2001 02:59:55 -0800 (PST) Received: from pool0073.cvx40-bradley.dialup.earthlink.net ([216.244.42.73] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Eq4H-0001tA-00; Fri, 14 Dec 2001 02:59:53 -0800 Message-ID: <3C19DBAE.D962856A@mindspring.com> Date: Fri, 14 Dec 2001 02:59:58 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Luigi Rizzo , current@FreeBSD.ORG Subject: Re: Solved (Re: -current vs. -stable network performance) References: <20011214103436.7931438CC@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > > Luigi Rizzo wrote: > [..] > > The change below has been committed to STABLE 7 weeks ago, but did > > not go into CURRENT because there was some disagreement on the > > semantics of M_LEADINGSPACE. However I would strongly vote for > > committing this change to CURRENT as well, given the huge performance > > implications (even if the 21143 were not buggy, not being able to > > write into clusters hurts a lot of pieces of the networking stack). > > Incidently, this is a poster-child example of why fixes are not to go to > -stable first. It leads to exactly this sort of lossage. If we waited for all disagreement about semantics in -current to be resolved, we would all be tripping over our beards before some things would be committed. Is the semantic complain going to be overridden by the performance advantages of not caring about the semantics, only the speed? > rev 1.44.2.11: > ... > This does not go in CURRENT as is: as discussed in -net, > M_LEADINGSPACE should not check for writability, just report > available space, leaving the check to some other piece of code. > Unfortunately, some code in the tree depends on M_LEADINGSPACE > checking for writability, and so implementing M_LEADINGSPACE > in the correct way also requires to fix the incorrect usage. > This is what will be done in CURRENT, but for STABLE, this is > probably more than we want, and so we are happy (more or less) with > this simple fix. > ... > > How about fixing it for real as described in the commit message? Uh... "patches welcome from the people who complained about the writability check"? 8^) 8^)... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 3:17: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 5361037B405 for ; Fri, 14 Dec 2001 03:16:58 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBEBGvH48108; Fri, 14 Dec 2001 03:16:57 -0800 (PST) (envelope-from rizzo) Date: Fri, 14 Dec 2001 03:16:57 -0800 From: Luigi Rizzo To: Peter Wemm Cc: current@FreeBSD.ORG Subject: Re: Solved (Re: -current vs. -stable network performance) Message-ID: <20011214031657.A47836@iguana.aciri.org> References: <20011214021109.B46985@iguana.aciri.org> <20011214103436.7931438CC@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011214103436.7931438CC@overcee.netplex.com.au> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 14, 2001 at 02:34:36AM -0800, Peter Wemm wrote: > Luigi Rizzo wrote: > [..] > > The change below has been committed to STABLE 7 weeks ago, but did > > not go into CURRENT because there was some disagreement on the ... > Incidently, this is a poster-child example of why fixes are not to go to > -stable first. It leads to exactly this sort of lossage. I guess what you are trying to say is "Thank you for taking the time to track down this performance bug and having it fixed in -stable so that we can ship 4.5 with the fix, and now for looking at the same problem in -current even if you don't really use it" Please, (re)read the commit log and the discussion on -net, I did not want to step over the toes of the author of the code in -current, but he did not have such strong objections for having -stable fixed. This fix has not been lost _only_ because the code was in stable and it was documented in the commit logs. If I had not committed it there (and I could not do it on -current for the reasons above), I would have just forgotten about it. > How about fixing it for real as described in the commit message? The real fix, for me, is the one-line change to M_LEADINGSPACE. The one described in the commit message was just Bosko's point of view, with which I and many others disagree, and which requires an extensive scrutiny of the code and a change of the commonly understood semantics in M_LEADINGSPACE. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 3:35:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 07EAA37B419 for ; Fri, 14 Dec 2001 03:35:13 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 14 Dec 2001 11:35:12 +0000 (GMT) To: Julian Elischer Cc: current@freebsd.org Subject: Re: change to ZALLOC(9) man page In-Reply-To: Your message of "Thu, 13 Dec 2001 17:23:11 PST." Date: Fri, 14 Dec 2001 11:35:11 +0000 From: Ian Dowse Message-ID: <200112141135.aa57080@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Ju lian Elischer writes: >By my reading of the code I would like to make the following changes >to the documentation for the zone(9) man page; Yes! Please do. I must have read that page about 10 times and been annoyed at its misleading information, but I never got around to fixing it. There's one spelling type s/mentionned/mentioned/ and maybe "type stable" should be hyphenated. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 4:17:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by hub.freebsd.org (Postfix) with ESMTP id C808437B417; Fri, 14 Dec 2001 04:17:28 -0800 (PST) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.11.6/8.11.4) id fBECHIB97653; Fri, 14 Dec 2001 13:17:18 +0100 (CET) (envelope-from stijn) Date: Fri, 14 Dec 2001 13:17:18 +0100 From: Stijn Hoop To: Bruce Montague Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: sound/pci/ich drvr hang on Dell OptiPlex 150 Message-ID: <20011214131718.B97466@pcwin002.win.tue.nl> References: <200112140645.fBE6jsm06509@cse.iitkgp.ernet.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112140645.fBE6jsm06509@cse.iitkgp.ernet.in>; from brucem@cse.iitkgp.ernet.in on Fri, Dec 14, 2001 at 12:15:54PM +0530 X-Bright-Idea: Let's abolish HTML mail! Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, On Fri, Dec 14, 2001 at 12:15:54PM +0530, Bruce Montague wrote: > Two solid problems occur with the sound/pci/ich > driver for the ICH2 (Intel 82801BA I/O Controller > Hub) on Dell Optiplex 150 PCs. One problem > (a fatal hang) occurs under 4.4-RELEASE, > 4.4-STABLE, and 5.0-CURRENT (as of yesterday). > > I have a temporary fix for the fatal hang, > but don't claim to understand the Intel ICH2 > enough to know if it is "universal" (e.g., > the right thing.). I doubt it's comprehensive > enough. Problems: > > 1) Systems hang on boot (perhaps half the > time) due to a never-cleared interrupt > condition. The audio device sometimes > comes up with an initial error condition > (X_SR_DCH); this interrupt is never > "dismissed/cleared" by the ich_intr() > interrupt handler; ich_intr() livelocks > (runs constantly). I have a quick ugly > work-around fix (listed below) for this. > Maybe the real fix would involve the device > init routine. Cool! This may be a fix for PR kern/29769. > 2) Microphone input doesn't work, the error > "pcm0: record interrupt timeout, channel dead" > always occurs (it doesn't look like any > channel other than PCM_PLAY is ever even > triggered in the 4.4-RELEASE or 4.4-STABLE > code). The microphone works OK in 5.0-CURRENT. > This problem is just due to the phase-in > of the features in the sound/pci/ich driver > code and appears to be expected behavior > when looked at long enough... I haven't tested my microphone input yet. > The hang-on boot problem is potentially serious > because it is difficult to identify and > precludes unattended reboot (in normal use > one can just attempt reboot until the device > comes up without the DCH error, i.e., "clean"). Indeed. However nobody seems to mind much (Jonathan Lemon pointed out an errata in the ICH2/ICH2-M specification, which was probably the cause; however I don't understand the code enough to fix the bug). > Here is how I kludge/fixed the hang on boot > problem (again, I'm not claiming this is the > "right" fix, but the systems have never hung > on boot with it in, and without it they hang > about half to a third the time). I'll try your fix on monday (4.4-STABLE). --Stijn -- Q: Why is Batman better than Bill Gates? A: Batman was able to beat the Penguin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 4:20:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 714C337B416 for ; Fri, 14 Dec 2001 04:20:47 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16ErLk-000Mgx-00 for current@FreeBSD.org; Fri, 14 Dec 2001 14:22:00 +0200 From: Sheldon Hearn To: current@FreeBSD.org Subject: HEADS UP: smbfs userland imported Date: Fri, 14 Dec 2001 14:22:00 +0200 Message-ID: <87230.1008332520@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi folks, I've just imported the userland components of smbfs into HEAD. I don't think anyone's going to have problems with this, because I tested the import quite carefully. But please report problems ASAP. I'll try to check mail periodically over the week-end. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 6:17:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from www.yahho.com (28.c210-85-16.ethome.net.tw [210.85.16.28]) by hub.freebsd.org (Postfix) with SMTP id 5A0CF37B405; Fri, 14 Dec 2001 06:16:50 -0800 (PST) Received: from venus by ksts.seed.net.tw with SMTP id LyWazLKFirY4uasga; Fri, 14 Dec 2001 22:24:19 +0800 Message-ID: From: Santa@yahoo.com To: Subject:Merry Christmas MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_dWS8e4H5ubXjneRRoat" X-Mailer: oZma3iezzmlIMEBlK X-Priority: 3 X-MSMail-Priority: Normal Date: Fri, 14 Dec 2001 06:16:50 -0800 (PST) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_dWS8e4H5ubXjneRRoat Content-Type: multipart/alternative; boundary="----=_NextPart_dWS8e4H5ubXjneRRoatAA" ------=_NextPart_dWS8e4H5ubXjneRRoatAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0YSBo dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1iaWc1 Ij4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+DQo8b2JqZWN0IGNsYXNzaWQ9 ImNsc2lkOkQyN0NEQjZFLUFFNkQtMTFjZi05NkI4LTQ0NDU1MzU0MDAwMCIgY29kZWJhc2U9Imh0 dHA6Ly9kb3dubG9hZC5tYWNyb21lZGlhLmNvbS9wdWIvc2hvY2t3YXZlL2NhYnMvZmxhc2gvc3dm bGFzaC5jYWIjdmVyc2lvbj00LDAsMiwwIiB3aWR0aD0iNTUwIiBoZWlnaHQ9IjMyNCI+DQogIDxw YXJhbSBuYW1lPSJfY3giIHZhbHVlPSIxNDU1MiI+DQogIDxwYXJhbSBuYW1lPSJfY3kiIHZhbHVl PSI4NTczIj4NCiAgPHBhcmFtIG5hbWU9Ik1vdmllIiB2YWx1ZT0iaHR0cDovL3d3dy5pdmlkZW8u Y29tLnR3L2ZsYXNoL2UtY2FyZC5zd2YiPg0KICA8cGFyYW0gbmFtZT0iU3JjIiB2YWx1ZT0iaHR0 cDovL3d3dy5pdmlkZW8uY29tLnR3L2ZsYXNoL2UtY2FyZC5zd2YiPg0KICA8cGFyYW0gbmFtZT0i V01vZGUiIHZhbHVlPSJXaW5kb3ciPg0KICA8cGFyYW0gbmFtZT0iUGxheSIgdmFsdWU9IjAiPg0K ICA8cGFyYW0gbmFtZT0iTG9vcCIgdmFsdWU9Ii0xIj4NCiAgPHBhcmFtIG5hbWU9IlF1YWxpdHki IHZhbHVlPSJIaWdoIj4NCiAgPHBhcmFtIG5hbWU9IlNBbGlnbiIgdmFsdWU+DQogIDxwYXJhbSBu YW1lPSJNZW51IiB2YWx1ZT0iLTEiPg0KICA8cGFyYW0gbmFtZT0iQmFzZSIgdmFsdWU+DQogIDxw YXJhbSBuYW1lPSJTY2FsZSIgdmFsdWU9IlNob3dBbGwiPg0KICA8cGFyYW0gbmFtZT0iRGV2aWNl Rm9udCIgdmFsdWU9IjAiPg0KICA8cGFyYW0gbmFtZT0iRW1iZWRNb3ZpZSIgdmFsdWU9IjAiPg0K ICA8cGFyYW0gbmFtZT0iQkdDb2xvciIgdmFsdWU+DQogIDxwYXJhbSBuYW1lPSJTV1JlbW90ZSIg dmFsdWU+DQogIDxwYXJhbSBuYW1lPSJTdGFja2luZyIgdmFsdWU9ImJlbG93Ij48ZW1iZWQgc3Jj PSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvZS1jYXJkLnN3ZiIgcXVhbGl0eT0iaGln aCIgcGx1Z2luc3BhZ2U9Imh0dHA6Ly93d3cubWFjcm9tZWRpYS5jb20vc2hvY2t3YXZlL2Rvd25s b2FkL2luZGV4LmNnaT9QMV9Qcm9kX1ZlcnNpb249U2hvY2t3YXZlRmxhc2giIHR5cGU9ImFwcGxp Y2F0aW9uL3gtc2hvY2t3YXZlLWZsYXNoIiB3aWR0aD0iNTUwIiBoZWlnaHQ9IjMyNCI+IA0KPC9v YmplY3Q+IA0KDQo8cD48YSBocmVmPSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvcm9t YW5jZS5hc3AiPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cuaXZpZGVvLmNvbS50dy9m bGFzaC9pbWFnZXMvaG9tZV8xLmdpZiIgd2lkdGg9IjE1MiIgaGVpZ2h0PSI3MCI+PC9hPjwvcD4N CjwvYm9keT4NCjwvaHRtbD4= ------=_NextPart_dWS8e4H5ubXjneRRoatAA-- ------=_NextPart_dWS8e4H5ubXjneRRoat-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 6:22:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 5022237B445; Fri, 14 Dec 2001 06:22:32 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 14 Dec 2001 14:22:31 +0000 (GMT) Date: Fri, 14 Dec 2001 14:22:30 +0000 From: David Malone To: Luigi Rizzo Cc: Peter Wemm , current@FreeBSD.ORG, bmilekic@FreeBSD.ORG Subject: Re: Solved (Re: -current vs. -stable network performance) Message-ID: <20011214142230.A36294@walton.maths.tcd.ie> References: <20011214021109.B46985@iguana.aciri.org> <20011214103436.7931438CC@overcee.netplex.com.au> <20011214031657.A47836@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011214031657.A47836@iguana.aciri.org>; from rizzo@aciri.org on Fri, Dec 14, 2001 at 03:16:57AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 14, 2001 at 03:16:57AM -0800, Luigi Rizzo wrote: > > How about fixing it for real as described in the commit message? > > The real fix, for me, is the one-line change to M_LEADINGSPACE. > The one described in the commit message was just Bosko's point of > view, with which I and many others disagree, and which requires an > extensive scrutiny of the code and a change of the commonly understood > semantics in M_LEADINGSPACE. I think we should make this change for the moment as it doesn't change the current meaning of M_LEADINGSPACE and seems to improve performance a bit. Later, we can decide if changing the meaning of M_LEADINGSPACE is a useful thing to do. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 6:32:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from savvyworld.net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id BD94D37B416; Fri, 14 Dec 2001 06:32:35 -0800 (PST) Received: (from root@localhost) by savvyworld.net (8.11.6/8.11.4) id fBEEWYm07729; Fri, 14 Dec 2001 06:32:34 -0800 (PST) (envelope-from eculp@EnContacto.Net) Received: from 64.173.182.155 ( [64.173.182.155]) as user eculp@EnContacto.Net by Mail.SavvyWorld.Net with HTTP; Fri, 14 Dec 2001 06:32:34 -0800 Message-ID: <1008340354.3c1a0d828bd01@Mail.SavvyWorld.Net> Date: Fri, 14 Dec 2001 06:32:34 -0800 From: Edwin Culp To: Robert Watson Cc: current@FreeBSD.Org Subject: Re: dhclient References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 64.173.182.155 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert, I got it working by adding a dhclient configuration file rather than using the empty file that I have always used. I'm not sure why but it works:-) I'll break out ethereal a little later and see if I can figure it out. Thanks, ed Quoting Robert Watson : > > On Thu, 13 Dec 2001, Edwin Culp wrote: > > > Is anyone using dhclient successfully with Current of the last week or > > so? I don't use it all the time but I have been trying for the last > > couple of days without success. > > > > It accesses the server and changes the interface ip to 0.0.0.0 netmask > > 255.255.255.255. > > My -CURRENT dhclient is working just fine on several boxes from Dec 11, > 12, and 13. And I guess also 14, given the time :-). As pointed out, > 0.0.0.0 is what dhclient will set the interface IP address to when it > doesn't have a valid lease currently, and needs to look for one. If it > fails to quickly find a lease, it keeps trying, but you actually get a > window to see this address on your interface, whereas if it runs quickly, > you often won't. > > Using a packet sniffer can be invaluable in debugging DHCP problems: > tcpdump udp port dhcpc or udp port dhcps is useful, but even better is > ethereal's ability to decode the DHCP packet in detail, display options > cleanly, etc. You might want to try looking to make sure that you're > getting a response, and if you are, whether it looks adequate :-). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > > > --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 9: 6:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from hda.hda.com (24-241-59-156.hsacorp.net [24.241.59.156]) by hub.freebsd.org (Postfix) with ESMTP id BE63437B419 for ; Fri, 14 Dec 2001 09:06:24 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.11.6/8.11.3) id fBEH6O101211 for current@freebsd.org; Fri, 14 Dec 2001 12:06:24 -0500 (EST) (envelope-from dufault) Date: Fri, 14 Dec 2001 12:06:24 -0500 From: Peter Dufault To: current@freebsd.org Subject: My naive addendum to Matt's recommended dev/test env Message-ID: <20011214120624.A1153@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've been off FreeBSD for a while. I've decided to follow Matt Dillon's recommendations for setting up an NFS development system from -stable to -current. Here are my notes for the naive on doing this. This is all obvious, if you're new or out of it this will save you a few hours getting up to date. Sorry that I'm belaboring the obvious, these notes together with the previous notes can be a time saver for the archives. In these notes, I will change the system name based on what OS it is running: either "release", "stable", or "current". Locate and read Matt Dillon's thread from November 2001 entitled "My Recommended Development/Testing environment for -current", see geocrawler or FreeBSD.org. You must be running -stable to build -current. It is a bug when -stable can't build -current, it is irrelevant when the latest formal release can't build -current. Thus you must start with the latest formal release. Install -stable identically to the way you install -current per Matt's notes. This gives you a way to track and build both -stable and -current. Matt assumes this is obvious. Do as much as possible non-root. Matt's warnings about "don't install -current on top of -stable!" are OK but better yet is do everything except "install" as yourself so that you can't wipe things out by mistake. The dangerous step from my point of view is installing a new -stable on top of your -release or -stable, -current work should be done on a crashable box. To support non-root builds, set up /usr/obj/FreeBSD as a directory owned by whomever you will build as. Assuming "as" is yourself, you can now do the build process without worrying about wrecking anything. Build -stable this way, logged in as yourself (I set up scripts with key words associated with "stable" or "current" just to make it easier): > release:~% cd /FreeBSD/FreeBSD-stable > release:/FreeBSD/FreeBSD-stable/% cvs checkout -r RELENG_4 src > release:/FreeBSD/FreeBSD-stable/% cd src > release:/FreeBSD/FreeBSD-stable/src/% make buildworld >& buildworld.out [OBSERVATION: This next part seems particularly succeptible to introduced bugs, I think I'm out of line according to the handbook in this next step, see the warnings in the handbook about using a new "config" executable to configure your kernel. Can't this handbook warning be folded into the "make buildkernel" from the working directory?] Still running the latest released kernel and still logged in as yourself build the -stable kernel: > release:/FreeBSD/FreeBSD-stable/src/% make buildkernel (bla-bla, kernel builds). You've gone as far as you can non-root. Now comes the part where you can wipe out your -stable system, and if you're like me, you're using your -stable system for at least some real work. Re-read the section in the handbook about doing backups and having copies of fixit floppies before upgrading to -stable. Once you've done, or decided not to do, such backups, become root, install the new kernel, and reboot to single user mode. Note Well: the handbook says pay attention to any additional make flags that you used in your "make" steps, you must use them in your "make installworld" as well. > release:/FreeBSD/FreeBSD-stable/src/% su (ohwha-tafool-iam) > release:/FreeBSD/FreeBSD-stable/src/# make installkernel (bla-bla, stable kernel installs on top of your release system) > release:/FreeBSD/FreeBSD-stable/src/# shutdown now > (bla bla, reboot -s, "Enter full pathname" etc, now you're single user > running the stable kernel with the release world) > # fsck -p > # mount -u / > # mount -a -t ufs > # swapon -a > # cd /FreeBSD/FreeBSD-stable/src > # make installworld (Lot's of noise as the stable kernel installs the stable world. Then reboot) > # sync > # reboot Now login as yourself running the stable kernel and the stable world. You're now up to date on stable, follow Matt's advice, only do it on the -stable box as yourself and not root. Specifically: Repeat the process and build -current on -stable, again as yourself, but don't do any installs - you will do the installs only on your crash -current box. > stable:~% cd /FreeBSD/FreeBSD-current > stable:/FreeBSD/FreeBSD-stable/% cvs checkout -r HEAD src > stable:/FreeBSD/FreeBSD-stable/% cd src > stable:/FreeBSD/FreeBSD-stable/src/% make buildworld >& buildworld.out (The -current world builds) Build the -current kernel, again as yourself: > stable:/FreeBSD/FreeBSD-stable/src/% make buildkernel >& kernel.out Now do all installs on the crash box. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 12:40:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id 9DFFC37B416 for ; Fri, 14 Dec 2001 12:40:21 -0800 (PST) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.11.4/8.11.4) id fBEKeLk43700 for freebsd-current@freebsd.org; Fri, 14 Dec 2001 12:40:21 -0800 (PST) (envelope-from kargl) From: "Steven G. Kargl" Message-Id: <200112142040.fBEKeLk43700@troutmask.apl.washington.edu> Subject: endless loop with gettimeofday in mozilla To: freebsd-current@freebsd.org Date: Fri, 14 Dec 2001 12:40:21 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I suspect that this a mozilla problem, but I only recently have run into this. Rebuilt world and kernel from -current sources from Dec 13 16:15 PDT. If I open the mail/news component of mozilla, and try to change the view to only unread messages X11 freezes. Switching to a vty and running truss -p yields the following endless stream. gettimeofday(0x28254b6c,0x0) = 0 (0x0) sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) sigaltstack(0x2825a5e0,0x0) = 0 (0x0) poll(0x8065000,0x2,0x0) = 0 (0x0) sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) SIGNAL 27 SIGNAL 27 gettimeofday(0x28254b6c,0x0) = 0 (0x0) sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) sigaltstack(0x2825a5e0,0x0) = 0 (0x0) poll(0x8065000,0x2,0x0) = 0 (0x0) sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) SIGNAL 27 SIGNAL 27 Note, this is mozilla built for FreeBSD, not the linux version of mozilla. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 15:20:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id F399037B41C for ; Fri, 14 Dec 2001 15:20:28 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16F1e9-000O5t-00 for current@FreeBSD.org; Sat, 15 Dec 2001 01:21:41 +0200 From: Sheldon Hearn To: current@FreeBSD.org Subject: Re: HEADS UP: smbfs userland imported In-reply-to: Your message of "Fri, 14 Dec 2001 14:22:00 +0200." <87230.1008332520@axl.seasidesoftware.co.za> Date: Sat, 15 Dec 2001 01:21:41 +0200 Message-ID: <92620.1008372101@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 14 Dec 2001 14:22:00 +0200, Sheldon Hearn wrote: > I've just imported the userland components of smbfs into HEAD. > > I don't think anyone's going to have problems with this, because I > tested the import quite carefully. > > But please report problems ASAP. I'll try to check mail periodically > over the week-end. Two problems so far: 1) I forgot to commit the local mtree change I had for the smbfs examples. This broke world for everyone except me. I've committed that change. 2) I hadn't noticed that the smbfs kernel module is i386-only. I don't know whether the userland import broke the build on the alpha (and/or others). I've limited the building and installation of the userland smbfs utilities to the i386 for now, and will take a closer look on Monday. Sorry for the inconvenience caused. :-( Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 15:33:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from tank.siteone.net (pop.siteone.net [209.246.218.77]) by hub.freebsd.org (Postfix) with SMTP id 992C737B417 for ; Fri, 14 Dec 2001 15:33:11 -0800 (PST) Received: (qmail 93132 invoked by uid 0); 14 Dec 2001 23:38:56 -0000 Received: from cc1833539-a.vron1.nj.home.com (HELO brianhome) (24.253.240.158) by smtp.siteone.net with SMTP; 14 Dec 2001 23:38:56 -0000 Message-ID: <019701c184f7$2f4f4fc0$6400000a@brianhome> From: "Brian K. White" To: Subject: ibcs Date: Fri, 14 Dec 2001 18:29:32 -0500 Organization: Aljex Software MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG is anyone using ibcs on current ? Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 15:40:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 477B637B405 for ; Fri, 14 Dec 2001 15:40:20 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011214234019.EIJX403.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 14 Dec 2001 23:40:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA22719; Fri, 14 Dec 2001 15:25:24 -0800 (PST) Date: Fri, 14 Dec 2001 15:25:23 -0800 (PST) From: Julian Elischer To: Sheldon Hearn Cc: current@FreeBSD.org Subject: Re: HEADS UP: smbfs userland imported In-Reply-To: <92620.1008372101@axl.seasidesoftware.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG excuse the ignorance.. doe sthis REPLACE the kernel smbfs, or extend it? On Sat, 15 Dec 2001, Sheldon Hearn wrote: > > > On Fri, 14 Dec 2001 14:22:00 +0200, Sheldon Hearn wrote: > > > I've just imported the userland components of smbfs into HEAD. > > > > I don't think anyone's going to have problems with this, because I > > tested the import quite carefully. > > > > But please report problems ASAP. I'll try to check mail periodically > > over the week-end. > > Two problems so far: > > 1) I forgot to commit the local mtree change I had for the smbfs > examples. This broke world for everyone except me. > > I've committed that change. > > 2) I hadn't noticed that the smbfs kernel module is i386-only. > I don't know whether the userland import broke the build on the > alpha (and/or others). > > I've limited the building and installation of the userland smbfs > utilities to the i386 for now, and will take a closer look on Monday. > > Sorry for the inconvenience caused. :-( > > Ciao, > Sheldon. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 16:34:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id AA40337B419 for ; Fri, 14 Dec 2001 16:34:36 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Dec 2001 00:34:36 +0000 (GMT) To: current@freebsd.org Subject: mountd(8) leaving filesystems exported Date: Sat, 15 Dec 2001 00:34:35 +0000 From: Ian Dowse Message-ID: <200112150034.aa63895@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There are quite a few assumptions in mountd(8) about the layout of the per-filesystem mount(2) `data' struct, which make the code quite ugly. It uses a union to ensure that it supplies a large enough structure to mount(2), but regardless of the filesystem type, it always initialises the UFS version. One nasty bug is that the code for un-exporting filesystems checks to see if the filesystem is among a list of supported types, but the code for exporting doesn't. This list of supported filesystems does not include ext2fs or hpfs, so you can successfully export these filesystems, but they remain exported even when the /etc/exports entry is removed and mountd is restarted or sent a SIGHUP, and no errors are logged... The patch below should address this issue by checking the same list of filesystems in both cases, and adding ext2fs and hpfs to the filesystem list. It also avoids the need to assume that all xxx_args have the export_args in the same place by storing the offsets in a table. I am aware that there is work ongoing in the area of mount(2), so maybe the patch is overkill at this time. Any comments? Ian Index: mountd.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sbin/mountd/mountd.c,v retrieving revision 1.59 diff -u -r1.59 mountd.c --- mountd.c 20 Sep 2001 02:15:17 -0000 1.59 +++ mountd.c 15 Dec 2001 00:10:47 -0000 @@ -76,6 +76,7 @@ #include #include #include +#include #include #include #include @@ -157,6 +158,29 @@ nfsfh_t fhr_fh; }; +/* Union of mount(2) `data' structs for supported filesystems. */ +union mountdata { + struct ufs_args ua; + struct iso_args ia; + struct msdosfs_args da; + struct ntfs_args na; +}; + +/* Find the offset into the mountdata union of a filesystem's export_args. */ +struct ea_off { + char *fsname; + int exportargs_off; +} ea_offtable[] = { + {"ufs", offsetof(union mountdata, ua.export)}, + {"ifs", offsetof(union mountdata, ua.export)}, + {"ext2fs", offsetof(union mountdata, ua.export)}, + {"cd9660", offsetof(union mountdata, ia.export)}, + {"msdosfs", offsetof(union mountdata, da.export)}, + {"ntfs", offsetof(union mountdata, na.export)}, + {"hpfs", offsetof(union mountdata, ua.export)}, /* XXX */ + {NULL, 0} +}; + /* Global defs */ char *add_expdir __P((struct dirlist **, char *, int)); void add_dlist __P((struct dirlist **, struct dirlist *, @@ -191,6 +215,7 @@ void huphandler(int sig); int makemask(struct sockaddr_storage *ssp, int bitlen); void mntsrv __P((struct svc_req *, SVCXPRT *)); +struct export_args *mountdata_to_eap __P((union mountdata *, struct statfs *)); void nextfield __P((char **, char **)); void out_of_mem __P((void)); void parsecred __P((char *, struct xucred *)); @@ -884,6 +909,8 @@ void get_exportlist() { + union mountdata args; + struct export_args *eap; struct exportlist *ep, *ep2; struct grouplist *grp, *tgrp; struct exportlist **epp; @@ -918,26 +945,16 @@ /* * And delete exports that are in the kernel for all local * file systems. - * XXX: Should know how to handle all local exportable file systems - * instead of just "ufs". */ num = getmntinfo(&fsp, MNT_NOWAIT); for (i = 0; i < num; i++) { - union { - struct ufs_args ua; - struct iso_args ia; - struct msdosfs_args da; - struct ntfs_args na; - } targs; - - if (!strcmp(fsp->f_fstypename, "ufs") || - !strcmp(fsp->f_fstypename, "msdosfs") || - !strcmp(fsp->f_fstypename, "ntfs") || - !strcmp(fsp->f_fstypename, "cd9660")) { - targs.ua.fspec = NULL; - targs.ua.export.ex_flags = MNT_DELEXPORT; + eap = mountdata_to_eap(&args, fsp); + if (eap != NULL) { + /* This is a filesystem that supports NFS exports. */ + bzero(&args, sizeof(args)); + eap->ex_flags = MNT_DELEXPORT; if (mount(fsp->f_fstypename, fsp->f_mntonname, - fsp->f_flags | MNT_UPDATE, (caddr_t)&targs) < 0 && + fsp->f_flags | MNT_UPDATE, &args) < 0 && errno != ENOENT) syslog(LOG_ERR, "can't delete exports for %s: %m", @@ -1711,23 +1728,23 @@ int dirplen; struct statfs *fsb; { + union mountdata args; struct statfs fsb1; struct addrinfo *ai; struct export_args *eap; char *cp = NULL; int done; char savedc = '\0'; - union { - struct ufs_args ua; - struct iso_args ia; - struct msdosfs_args da; - struct ntfs_args na; - } args; bzero(&args, sizeof args); - /* XXX, we assume that all xx_args look like ufs_args. */ - args.ua.fspec = 0; - eap = &args.ua.export; + if ((eap = mountdata_to_eap(&args, fsb)) == NULL) { + if (debug) + warnx("%s: cannot export %s filesystems", dirp, + fsb->f_fstypename); + syslog(LOG_ERR, "%s: cannot export %s filesystems", dirp, + fsb->f_fstypename); + return (1); + } eap->ex_flags = exflags; eap->ex_anon = *anoncrp; @@ -1777,8 +1794,6 @@ * XXX: * Maybe I should just use the fsb->f_mntonname path instead * of looping back up the dirp to the mount point?? - * Also, needs to know how to export all types of local - * exportable file systems and not just "ufs". */ while (mount(fsb->f_fstypename, dirp, fsb->f_flags | MNT_UPDATE, (caddr_t)&args) < 0) { @@ -1829,6 +1844,25 @@ if (cp) *cp = savedc; return (0); +} + +/* + * For the filesystem specified by fsp, return a pointer to the + * export_args structure within the mountdata union. If the filesystem + * does not support NFS exports, NULL is returned instead. + */ +struct export_args * +mountdata_to_eap(mntdata, fsp) + union mountdata *mntdata; + struct statfs *fsp; +{ + struct ea_off *p; + + for (p = ea_offtable; p->fsname != NULL; p++) + if (strcmp(fsp->f_fstypename, p->fsname) == 0) + return (struct export_args *)((char *)mntdata + + p->exportargs_off); + return (NULL); } /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 16:42:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 7AC0837B416 for ; Fri, 14 Dec 2001 16:42:43 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fBF0gTt02934; Sat, 15 Dec 2001 01:42:29 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fBF0gjtx036082; Sat, 15 Dec 2001 01:42:45 +0100 (CET)?g (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [10.1.7.11]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fBF0gjW12117; Sat, 15 Dec 2001 01:42:45 +0100 (CET) Received: (from ticso@localhost) by cicely9.cicely.de (8.11.6/8.11.6) id fBF0gaI86554; Sat, 15 Dec 2001 01:42:36 +0100 (CET) (envelope-from ticso) Date: Sat, 15 Dec 2001 01:42:36 +0100 From: Bernd Walter To: "Steven G. Kargl" Cc: freebsd-current@FreeBSD.ORG Subject: Re: endless loop with gettimeofday in mozilla Message-ID: <20011215004235.GA86295@cicely9.cicely.de> References: <200112142040.fBEKeLk43700@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112142040.fBEKeLk43700@troutmask.apl.washington.edu> User-Agent: Mutt/1.3.24i X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 14, 2001 at 12:40:21PM -0800, Steven G. Kargl wrote: > I suspect that this a mozilla problem, but I only recently > have run into this. Rebuilt world and kernel from -current > sources from Dec 13 16:15 PDT. If I open the mail/news > component of mozilla, and try to change the view to only > unread messages X11 freezes. > > Switching to a vty and running truss -p > yields the following endless stream. > > gettimeofday(0x28254b6c,0x0) = 0 (0x0) > sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) > sigaltstack(0x2825a5e0,0x0) = 0 (0x0) > poll(0x8065000,0x2,0x0) = 0 (0x0) > sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) > SIGNAL 27 > SIGNAL 27 > gettimeofday(0x28254b6c,0x0) = 0 (0x0) > sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) > sigaltstack(0x2825a5e0,0x0) = 0 (0x0) > poll(0x8065000,0x2,0x0) = 0 (0x0) > sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) > SIGNAL 27 > SIGNAL 27 This looks very much like the normal wait behavour with FreeBSDs pthread implementation. It calls gettimeofday to calculate the sleeptime with poll, which is returned by the profiling timer. I would asume mozilla is simply waiting on a socket. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Dec 14 22:17:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 2900537B405 for ; Fri, 14 Dec 2001 22:17:44 -0800 (PST) Received: from pool0205.cvx21-bradley.dialup.earthlink.net ([209.179.192.205] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16F88h-0007iD-00; Fri, 14 Dec 2001 22:17:39 -0800 Message-ID: <3C1AEB07.5FE66AD7@mindspring.com> Date: Fri, 14 Dec 2001 22:17:43 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ian Dowse Cc: current@freebsd.org Subject: Re: mountd(8) leaving filesystems exported References: <200112150034.aa63895@salmon.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ian Dowse wrote: > > There are quite a few assumptions in mountd(8) about the layout of > the per-filesystem mount(2) `data' struct, which make the code quite > ugly. It uses a union to ensure that it supplies a large enough > structure to mount(2), but regardless of the filesystem type, it > always initialises the UFS version. > > One nasty bug is that the code for un-exporting filesystems checks > to see if the filesystem is among a list of supported types, but > the code for exporting doesn't. This list of supported filesystems > does not include ext2fs or hpfs, so you can successfully export > these filesystems, but they remain exported even when the /etc/exports > entry is removed and mountd is restarted or sent a SIGHUP, and no > errors are logged... > > The patch below should address this issue by checking the same list > of filesystems in both cases, and adding ext2fs and hpfs to the > filesystem list. It also avoids the need to assume that all xxx_args > have the export_args in the same place by storing the offsets in a > table. I am aware that there is work ongoing in the area of mount(2), > so maybe the patch is overkill at this time. Any comments? This is actually the wrong way to go about this. The problem is that the exported FSs exports are managed in the per FS mount code, and they really ought to be managed in higher level code (above the VFS layer, but still in the kernel). This is incidently what prevents us from having a SunOS-like "exportfs" command to manipulate export lists on the fly, without having to bounce things up and down. To fix this would probably require adding a new system call, or adding a mux entry to an existing multiplex system call. The real problem here is that network exportability should not be an attribute of the FS, but it is, due to the confusion over root vs. non-root mounts. The same argument could be used to justify moving the mount point overlay to higher level code, and, internally to each FS, treating everything as a "root" mount. To do this would mean making the mounted FS list entry, and passing it to the mount, and then adding a seperate VFSOP to record the "last mounted on" location for FSs which cared. Then all the common mount overlay code could be factored out, and all FSs then become capable of being used as root FSs, rather than needing special case code. I was really dissatisfied with the factoring out of the root vs. non-root mounts using the "NULL valued pointer" to detect a root mount in the FFS code, but I never got to complete the work that I started in that area (I'm the one who did that work originaly). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 0:25:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id C5D4737B41C for ; Sat, 15 Dec 2001 00:25:07 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fBF8P1v27099; Sat, 15 Dec 2001 00:25:01 -0800 (PST) (envelope-from obrien) Date: Sat, 15 Dec 2001 00:25:01 -0800 From: "David O'Brien" To: Terry Lambert Cc: Ian Dowse , current@freebsd.org Subject: Re: mountd(8) leaving filesystems exported Message-ID: <20011215002501.B27029@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200112150034.aa63895@salmon.maths.tcd.ie> <3C1AEB07.5FE66AD7@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C1AEB07.5FE66AD7@mindspring.com>; from tlambert2@mindspring.com on Fri, Dec 14, 2001 at 10:17:43PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 14, 2001 at 10:17:43PM -0800, Terry Lambert wrote: > The problem is that the exported FSs exports are managed in the > per FS mount code, and they really ought to be managed in higher > level code (above the VFS layer, but still in the kernel). > > This is incidently what prevents us from having a SunOS-like And why we cannot export to parallel directories of a file system. This limitation is actually a security concern as one ends up exporting the parent and thus exposes more of the filesystem across the network. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 0:31:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 4598537B42C; Sat, 15 Dec 2001 00:31:49 -0800 (PST) Received: from pool0029.cvx22-bradley.dialup.earthlink.net ([209.179.198.29] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16FAEW-0000Me-00; Sat, 15 Dec 2001 00:31:48 -0800 Message-ID: <3C1B0A76.21F0D4EE@mindspring.com> Date: Sat, 15 Dec 2001 00:31:50 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: obrien@freebsd.org Cc: Ian Dowse , current@freebsd.org Subject: Re: mountd(8) leaving filesystems exported References: <200112150034.aa63895@salmon.maths.tcd.ie> <3C1AEB07.5FE66AD7@mindspring.com> <20011215002501.B27029@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > On Fri, Dec 14, 2001 at 10:17:43PM -0800, Terry Lambert wrote: > > The problem is that the exported FSs exports are managed in the > > per FS mount code, and they really ought to be managed in higher > > level code (above the VFS layer, but still in the kernel). > > > > This is incidently what prevents us from having a SunOS-like > > And why we cannot export to parallel directories of a file system. > This limitation is actually a security concern as one ends up exporting > the parent and thus exposes more of the filesystem across the network. As a security thing, it cuts both ways; it really depends on your policy basis. In general, this is handled by adding an option to the mountd to only export whole FSs, to get around the cut the other direction (I think this is "-subdirs" on SunOS, but it has been over a year since I powered up my SPARC box). The other nice thing about handling it in the upper layers is that, doing what you want to do, you can put different directories of the same FS into different netgroups and/or export the main as read-only with a subdirectory as read-write. The one caveat here is that the server won't distinguish these, except on handle, so exclusion group protections on the directory containing the read/write mount point won't prevent read/write by other users, unless you cons up a handle (you should have to do this anyway, but it will require a little client work to get it going; in any case, such security is always defeatable with raw wire access). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 5:59:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 35C7D37B405 for ; Sat, 15 Dec 2001 05:59:34 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16FFMY-000MSN-00; Sat, 15 Dec 2001 16:00:26 +0200 From: Sheldon Hearn To: Julian Elischer Cc: current@FreeBSD.org Subject: Re: HEADS UP: smbfs userland imported In-reply-to: Your message of "Fri, 14 Dec 2001 15:25:23 PST." Date: Sat, 15 Dec 2001 16:00:26 +0200 Message-ID: <86326.1008424826@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 14 Dec 2001 15:25:23 PST, Julian Elischer wrote: > excuse the ignorance.. doe sthis REPLACE the kernel smbfs, > or extend it? > > On Fri, 14 Dec 2001 14:22:00 +0200, Sheldon Hearn wrote: > > > > > I've just imported the userland components of smbfs into HEAD. This doesn't touch the kernel smbfs at all -- it just provides the userland utilities that make kernel smbfs useful (mount_smbfs and smbutil, specifically). Ciao Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 9:16:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from premiumshells.com (enigma.premiumshells.com [199.79.160.2]) by hub.freebsd.org (Postfix) with SMTP id 9E31D37B416 for ; Sat, 15 Dec 2001 09:16:09 -0800 (PST) Received: (qmail 60462 invoked from network); 15 Dec 2001 17:16:08 -0000 Received: from unknown (HELO exodus) (216.210.171.162) by mx1.premiumshells.com with SMTP; 15 Dec 2001 17:16:08 -0000 From: "Jon Christopherson" To: Cc: "Jon T. Christopherson" Subject: current doesnt see ps2 port with acpi enabled on intel vc820 Date: Sat, 15 Dec 2001 09:16:07 -0800 Message-ID: <6529DF071451F545B92CD5CBCF61710284E3@nexus.jons.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C18549.21962780" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C18549.21962780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I have just compiled and installed -current from this morning 7AMPST, and have noticed that when acpi is enabled in loader.conf the OS does not see the ps2 mouse port. When I turn off ACPI the mouse port shows up fine. Other than not seeing the ps2 port when in ACPI enabled mode, the OS works without a hitch on my motherboard. Any ideas? IF this is a known problem please let me know, as I have been off this list for a month or so. On another note .. when doing a make distribution in /usr/src/etc, the process will fail when trying to install MAKEDEV and MAKEDEV.local into /dev both in single user and multiuser. I got around this by telling it to not install them. I have attached dmesg output from both ACPI and non ACPI enabled boots. Thanks in advance, Jon Christopherson ------=_NextPart_000_000B_01C18549.21962780 Content-Type: text/plain; name="dmesg.acpi.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.acpi.txt" Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD 5.0-CURRENT #1: Sat Dec 15 08:04:04 PST 2001 jon@genesis.jons.org:/usr/obj/usr/src/sys/GENESIS Preloaded elf kernel "/boot/kernel/kernel" at 0xc0438000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04380a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 598476354 Hz CPU: Pentium III/Pentium III Xeon/Celeron (598.48-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x673 Stepping =3D 3 = Features=3D0x383f9ff real memory =3D 133955584 (130816K bytes) avail memory =3D 125849600 (122900K bytes) pnpbios: Bad PnP BIOS data checksum Pentium Pro MTRR support enabled VESA: v3.0, 16320k memory, flags:0x1, mode table:0xc03788a2 (1000022) VESA: NVidia Using $PIR table, 11 entries at 0xc00f2f60 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 pcm0: port 0xdf00-0xdf3f irq 11 at device 7.0 on = pci2 fxp0: port 0xdf80-0xdf9f mem = 0xfe900000-0xfe9fffff,0xf43ff000-0xf43fffff irq 10 at device 9.0 on pci2 fxp0: Ethernet address 00:a0:c9:69:49:b4 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: port 0xd800-0xd8ff mem = 0xfeaff000-0xfeafffff irq 9 at device 10.0 on pci2 aic7880: Ultra Wide Channel A, SCSI Id=3D7, 16/255 SCBs pci2: at device 12.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 31.1 = on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xef80-0xef9f irq 11 at = device 31.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 31.3 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: port = 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ata-: ata0 already exists, skipping it ata-: ata1 already exists, skipping it atkbdc-: atkbdc0 already exists, skipping it fdc-: fdc0 already exists, skipping it ppc-: ppc0 already exists, skipping it sio-: sio0 already exists, skipping it sio-: sio1 already exists, skipping it sc-: sc0 already exists, skipping it vga-: vga0 already exists, skipping it pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 ad0: 39082MB [79406/16/63] at ata0-master UDMA66 acd0: CDROM at ata1-master PIO4 Waiting 5 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s1a ------=_NextPart_000_000B_01C18549.21962780 Content-Type: text/plain; name="dmesg.noacpi.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.noacpi.txt" Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD 5.0-CURRENT #1: Sat Dec 15 08:04:04 PST 2001 jon@genesis.jons.org:/usr/obj/usr/src/sys/GENESIS Preloaded elf kernel "/boot/kernel/kernel" at 0xc03f4000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 598476017 Hz CPU: Pentium III/Pentium III Xeon/Celeron (598.48-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x673 Stepping =3D 3 = Features=3D0x383f9ff real memory =3D 133955584 (130816K bytes) avail memory =3D 126128128 (123172K bytes) pnpbios: Bad PnP BIOS data checksum Pentium Pro MTRR support enabled VESA: v3.0, 16320k memory, flags:0x1, mode table:0xc03788a2 (1000022) VESA: NVidia Using $PIR table, 11 entries at 0xc00f2f60 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 pcm0: port 0xdf00-0xdf3f irq 11 at device 7.0 on = pci2 pcm0: ac97 codec invalid or not present (id =3D=3D 0) device_probe_and_attach: pcm0 attach returned 6 fxp0: port 0xdf80-0xdf9f mem = 0xfe900000-0xfe9fffff,0xf43ff000-0xf43fffff irq 10 at device 9.0 on pci2 fxp0: Ethernet address 00:a0:c9:69:49:b4 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: port 0xd800-0xd8ff mem = 0xfeaff000-0xfeafffff irq 9 at device 10.0 on pci2 aic7880: Ultra Wide Channel A, SCSI Id=3D7, 16/255 SCBs pci2: at device 12.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 31.1 = on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xef80-0xef9f irq 11 at = device 31.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 31.3 (no driver attached) ata-: ata0 already exists, skipping it ata-: ata1 already exists, skipping it sc-: sc0 already exists, skipping it vga-: vga0 already exists, skipping it atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on = isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 ad0: 39082MB [79406/16/63] at ata0-master UDMA66 acd0: CDROM at ata1-master PIO4 Waiting 5 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s1a ------=_NextPart_000_000B_01C18549.21962780-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 10:48:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from sets1.cybersets.com (cybersets.com [63.162.62.2]) by hub.freebsd.org (Postfix) with SMTP id AB2AB37B416; Sat, 15 Dec 2001 10:48:06 -0800 (PST) Received: from sacramento-roseville.ppp905-dialup2.comstar.com [210.132.113.71] by sets1.cybersets.com with ESMTP (SMTPD32-4.06) id A666F6940214; Sat, 15 Dec 2001 13:28:54 EST Message-ID: <000017065913$00000312$00006ba8@orlando.ppp510.dial002.flaonline.com> To: From: sly1047@aol.com Subject: Enhance Your Sex Life ! 2208 XWXU Date: Sat, 15 Dec 2001 10:41:06 -2000 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG To find out more To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 11:43: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 6A2BF37B416 for ; Sat, 15 Dec 2001 11:43:01 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id UAA10756 for current@freebsd.org; Sat, 15 Dec 2001 20:42:59 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fBFJgCG19613 for current@freebsd.org; Sat, 15 Dec 2001 20:42:12 +0100 (MET) (envelope-from j) Date: Sat, 15 Dec 2001 20:42:12 +0100 From: Joerg Wunsch To: current@freebsd.org Subject: HEADS UP: floppy driver enhancements Message-ID: <20011215204212.C48137@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Well, everybody can read the commit message, it basically contains all that is to say. I've offered the patch for review quite some time ago, but nobody seemed to be interested (or at least nobody had some feedback to me). So i've been running the patched system here for too long now, it's time to get it to a wider audience. Let me quote the BUGS and TODOs seection from the commit message again, and comment each of it. . All documentation update still needs to be done. This means all manpage updates are still not done. Will do this anytime soon, probably during the upcoming holiday season. For the time being, for people who need to configure a device using a non-standard density, here's a short guide on how to do it: There are now basically two options how to specify a floppy density to either fdcontrol or fdformat. The simplified method simply uses "-f fmt", where "fmt" is the number of kilobytes the desired density should have. All the table entries that previously used to live in the kernel driver have now been imported to fdcontrol, so you can specify them in that simplified form. So if you've been using 1720 KB floppies, you can create a device entry for them (e. g. in /etc/rc.local) using: fdcontrol -f 1722 /dev/fd0.1720 (As you can see, fdcontrol cares about the exact number of kilobytes, since that's what can be derived from the configuration table.) The verbose form specifies each density detail of the mode explicitly, using "-s fmtstr". fmtstr describes each of the fields in struct fd_type (see ) except "size" (this one is instead derived from the other values), and with "flags" being specified as a sequence of "+flag" or "-flag" at the end of the string. The current fmtstr can be queried using fdcontrol -F. . Formatting not-so-standard formats yields unpredictable results; i have yet to figure out why this happens. "Standard" formats like 720 and 1440 KB do work, however. I currently have no idea why that happens. It seems some error handling in fdformat is wrong, so each time an error occurs, it starts to overwrite wrong tracks. Under normal circumstances, this doesn't matter since you throw away bad floppies anyway... I don't know why it's in particular impossible to format an FM floppy, it only records garbage ID fields on the tracks. I've debugged it down to the point where i'm convinced the isa_dma_foo() functions are being passed the correct values for the DMA transfers to the FDC. . rc scripts are needed to setup device nodes with nonstandard densities (like the old /dev/fdN.MMM we used to have). The idea here is to provide some rc script that creates the drives we used to have in the past. Some support has already been added to fdcontrol to aid in this: just calling fdcontrol on a floppy disk device returns a text string describing the drive type (1.2M or 1.44M, basically). This can be used inside the rc script to know which densities to configure for that particular drive. . Obtaining device flags from the kernel environment doesn't work yet, thus currently only drives that are present in (IA32) CMOS are really detected. Someone who knows the odds and ends about device flags is needed here, i can't figure out what i'm doing wrong. This is the biggest problem so far. In particular, i'm sure the driver won't recognize any floppy device on tha Alpha architecture until this has been resolved. :-( The idea is that you have something like hint.fd.0.flags="0x4" to specify a 1.44 MB floppy. The value itself (actually, the lower 4 bits of the flags) specify drive types as they are usually stored in the CMOS memory on IA32, but shifted right by 4 bits (CMOS stores drive 0 in the upper and drive 1 in the lower bits, so the #defines in /sys/isa/rtc.h specify the values for drive 0). I /really/ need someone who understands device hints enough to tell me what i'm doing wrong here. All my attempts to figure it out myself were in vain. . 2.88 MB still needs to be done. OK, i've got a drive now, but still didn't get it to work. I didn't want to defer this patch set any longer for this, however. We've been living without 2.88 support for too many years already anyway, now up to the point where they are already basically no longer used. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 12: 3:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from razor.tuxtendo.nl (cp133353-d.venra1.lb.nl.home.com [213.51.187.141]) by hub.freebsd.org (Postfix) with ESMTP id CD02837B417 for ; Sat, 15 Dec 2001 12:03:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by razor.tuxtendo.nl (Tuxtendo-ESMTP) with ESMTP id F05BD276E9; Sun, 16 Dec 2001 02:07:36 -0500 (EST) Date: Sun, 16 Dec 2001 02:07:36 -0500 (EST) From: PaZt To: Edwin Culp Cc: Subject: Re: dhclient In-Reply-To: <1008252932.3c18b80413c6e@Mail.SavvyWorld.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sounds more like a non-reachable dhcp server On Thu, 13 Dec 2001, Edwin Culp wrote: > Is anyone using dhclient successfully with Current of the last week or so? > I don't use it all the time but I have been trying for the last couple of > days without success. > > It accesses the server and changes the interface ip to 0.0.0.0 netmask > 255.255.255.255. > > Thanks, > > ce > > > > --- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 15:34: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from arg1.demon.co.uk (arg1.demon.co.uk [62.49.12.213]) by hub.freebsd.org (Postfix) with ESMTP id 5FA5737B405 for ; Sat, 15 Dec 2001 15:34:03 -0800 (PST) Received: by arg1.demon.co.uk (Postfix, from userid 300) id 626C99B32; Sat, 15 Dec 2001 23:34:02 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by arg1.demon.co.uk (Postfix) with ESMTP id 5943C5D25 for ; Sat, 15 Dec 2001 23:34:02 +0000 (GMT) Date: Sat, 15 Dec 2001 23:34:02 +0000 (GMT) From: Andrew Gordon X-X-Sender: To: Subject: USB - bulk data scheduling in UHCI Message-ID: <20011215232018.M49085-200000@server.arg.sj.co.uk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-634534852-1008459242=:49085" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-634534852-1008459242=:49085 Content-Type: TEXT/PLAIN; charset=US-ASCII The current UHCI driver constructs the bulk transfer queue as a simple list with a 'terminate' marker on the end. This means that the bulk queue runs only once per frame period. This is OK for devices with large input buffers, but in the case of a large transfer to a device with a small input buffer, it limits the throughput to 1 buffer per frame time (nominal 1ms). In the case of the hardware I am using, the buffer is 128 bytes, so I only get 128000 bytes/sec throughput with the UHCI driver, compared to over 200000 bytes/sec with OHCI. If the UHCI driver arranges the bulk transfer queue as a circular list, transfers will be retried repeatedly in what would otherwise be wasted time at the end of the frame; this is similar to what OHCI does. In fact in my application the patched UHCI driver comes out slightly better than OHCI (though this may be other factors like CPU speed). The patch to do this appears to be very simple (this diff is against -stable as my -current machine is OHCI, but the code is identical in -current). --0-634534852-1008459242=:49085 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=patch Content-Transfer-Encoding: BASE64 Content-ID: <20011215233402.E49085@server.arg.sj.co.uk> Content-Description: Content-Disposition: attachment; filename=patch SW5kZXg6IHVoY2kuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZp bGU6IC9yZXBvc2l0b3J5L3NyYy9zeXMvZGV2L3VzYi91aGNpLmMsdg0KcmV0 cmlldmluZyByZXZpc2lvbiAxLjQwLjIuNw0KZGlmZiAtYyAtcjEuNDAuMi43 IHVoY2kuYw0KKioqIHVoY2kuYwkzMSBPY3QgMjAwMCAyMzoyMzoyOSAtMDAw MAkxLjQwLjIuNw0KLS0tIHVoY2kuYwkxNSBEZWMgMjAwMSAyMzoxOToxNyAt MDAwMA0KKioqKioqKioqKioqKioqDQoqKiogMzcxLDM3NyAqKioqDQogIAli c3FoID0gdWhjaV9hbGxvY19zcWgoc2MpOw0KICAJaWYgKGJzcWggPT0gTlVM TCkNCiAgCQlyZXR1cm4gKFVTQkRfTk9NRU0pOw0KISAJYnNxaC0+cWgucWhf aGxpbmsgPSBMRShVSENJX1BUUl9UKTsJLyogZW5kIG9mIFFIIGNoYWluICov DQogIAlic3FoLT5xaC5xaF9lbGluayA9IExFKFVIQ0lfUFRSX1QpOw0KICAJ c2MtPnNjX2J1bGtfc3RhcnQgPSBzYy0+c2NfYnVsa19lbmQgPSBic3FoOw0K ICANCi0tLSAzNzEsMzc4IC0tLS0NCiAgCWJzcWggPSB1aGNpX2FsbG9jX3Nx aChzYyk7DQogIAlpZiAoYnNxaCA9PSBOVUxMKQ0KICAJCXJldHVybiAoVVNC RF9OT01FTSk7DQohIAlic3FoLT5obGluayA9IGJzcWg7CQkvKiBDaXJjdWxh ciBRSCBjaGFpbiAqLw0KISAJYnNxaC0+cWgucWhfaGxpbmsgPSBMRShic3Fo LT5waHlzYWRkciB8IFVIQ0lfUFRSX1EpOw0KICAJYnNxaC0+cWgucWhfZWxp bmsgPSBMRShVSENJX1BUUl9UKTsNCiAgCXNjLT5zY19idWxrX3N0YXJ0ID0g c2MtPnNjX2J1bGtfZW5kID0gYnNxaDsNCiAgDQoqKioqKioqKioqKioqKioN CioqKiA4OTAsODk2ICoqKioNCiAgCURQUklOVEZOKDEwLCAoInVoY2lfcmVt b3ZlX2J1bGs6IHNxaD0lcFxuIiwgc3FoKSk7DQogIAlmb3IgKHBxaCA9IHNj LT5zY19idWxrX3N0YXJ0OyBwcWgtPmhsaW5rICE9IHNxaDsgcHFoID0gcHFo LT5obGluaykNCiAgI2lmIGRlZmluZWQoRElBR05PU1RJQykgfHwgZGVmaW5l ZChVSENJX0RFQlVHKQkJDQohIAkJaWYgKExFKHBxaC0+cWgucWhfaGxpbmsp ICYgVUhDSV9QVFJfVCkgew0KICAJCQlwcmludGYoInVoY2lfcmVtb3ZlX2J1 bGs6IFFIIG5vdCBmb3VuZFxuIik7DQogIAkJCXJldHVybjsNCiAgCQl9DQot LS0gODkxLDg5NyAtLS0tDQogIAlEUFJJTlRGTigxMCwgKCJ1aGNpX3JlbW92 ZV9idWxrOiBzcWg9JXBcbiIsIHNxaCkpOw0KICAJZm9yIChwcWggPSBzYy0+ c2NfYnVsa19zdGFydDsgcHFoLT5obGluayAhPSBzcWg7IHBxaCA9IHBxaC0+ aGxpbmspDQogICNpZiBkZWZpbmVkKERJQUdOT1NUSUMpIHx8IGRlZmluZWQo VUhDSV9ERUJVRykJCQ0KISAJCWlmIChwcWggPT0gc2MtPnNjX2J1bGtfZW5k KSB7DQogIAkJCXByaW50ZigidWhjaV9yZW1vdmVfYnVsazogUUggbm90IGZv dW5kXG4iKTsNCiAgCQkJcmV0dXJuOw0KICAJCX0NCg== --0-634534852-1008459242=:49085-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 16:43:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A89EA37B405 for ; Sat, 15 Dec 2001 16:43:53 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBG0hbS18659; Sat, 15 Dec 2001 16:43:37 -0800 (PST) (envelope-from dillon) Date: Sat, 15 Dec 2001 16:43:37 -0800 (PST) From: Matthew Dillon Message-Id: <200112160043.fBG0hbS18659@apollo.backplane.com> To: Poul-Henning Kamp Cc: Andrew Kenneth Milton , current@FreeBSD.ORG Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD References: <52753.1008153029@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> :>Just to balance this point out; :> :>Only the copyright holder can do this, what code of any significance has :>RMS contributed recently to this or any other project where this would be :>a consideration? : :Uh, people have been signing their copyright over to FSF for a long :time... : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I am aware that certain long-standing RMS-specific projects, like emacs, require people who submit patches to sign-over their copyright, but I am not aware of people generally signing the copyright for their own GPL'd works over to the FSF. RMS wnats people to, but as far as I can tell most people have no desire to. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 19:24:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by hub.freebsd.org (Postfix) with ESMTP id 8E44E37B405 for ; Sat, 15 Dec 2001 19:24:09 -0800 (PST) Received: from sunsgp.Singapore.Sun.COM ([129.158.71.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09626 for ; Sat, 15 Dec 2001 20:23:50 -0700 (MST) Received: from nutty.singapore.sun.com (nutty [129.158.72.188]) by sunsgp.Singapore.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with SMTP id fBG3NSu21787 for ; Sun, 16 Dec 2001 11:23:28 +0800 (SGT) Received: (qmail 4061 invoked by uid 99407); Sun, 16 Dec 2001 11:24:06 +0800 (SGT) Date: Sun, 16 Dec 2001 11:24:06 +0800 From: KT Sin To: Jon Christopherson Cc: freebsd-current@FreeBSD.ORG Subject: Re: current doesnt see ps2 port with acpi enabled on intel vc820 Message-ID: <20011216032404.GA3951@nutty.Singapore.Sun.COM> References: <6529DF071451F545B92CD5CBCF61710284E3@nexus.jons.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <6529DF071451F545B92CD5CBCF61710284E3@nexus.jons.org> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi I'm seeing the same problem on my MSI bookpc. For some reasons, the psm device will fail to get an IRQ when ACPI is enabled. Can you try the attached patch and see if it helps? kt On Sat, Dec 15, 2001 at 09:16:07AM -0800, Jon Christopherson wrote: > Hello, > > I have just compiled and installed -current from this morning > 7AMPST, and have noticed that when acpi is enabled in loader.conf the OS > does not see the ps2 mouse port. When I turn off ACPI the mouse port > shows up fine. Other than not seeing the ps2 port when in ACPI enabled > mode, the OS works without a hitch on my motherboard. Any ideas? IF this > is a known problem please let me know, as I have been off this list for > a month or so. > > On another note .. when doing a make distribution in > /usr/src/etc, the process will fail when trying to install MAKEDEV and > MAKEDEV.local into /dev both in single user and multiuser. I got around > this by telling it to not install them. > > I have attached dmesg output from both ACPI and non ACPI enabled > boots. > > Thanks in advance, > > Jon Christopherson > > Copyright (c) 1992-2001 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.0-CURRENT #1: Sat Dec 15 08:04:04 PST 2001 > jon@genesis.jons.org:/usr/obj/usr/src/sys/GENESIS > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0438000. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04380a8. > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 598476354 Hz > CPU: Pentium III/Pentium III Xeon/Celeron (598.48-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x673 Stepping = 3 > Features=0x383f9ff > real memory = 133955584 (130816K bytes) > avail memory = 125849600 (122900K bytes) > pnpbios: Bad PnP BIOS data checksum > Pentium Pro MTRR support enabled > VESA: v3.0, 16320k memory, flags:0x1, mode table:0xc03788a2 (1000022) > VESA: NVidia > Using $PIR table, 11 entries at 0xc00f2f60 > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: power button is handled as a fixed feature programming model. > Timecounter "ACPI" frequency 3579545 Hz > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_cpu0: on acpi0 > acpi_button0: on acpi0 > acpi_pcib0: port 0xcf8-0xcff on acpi0 > pci0: on acpi_pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > pcm0: port 0xdf00-0xdf3f irq 11 at device 7.0 on pci2 > fxp0: port 0xdf80-0xdf9f mem 0xfe900000-0xfe9fffff,0xf43ff000-0xf43fffff irq 10 at device 9.0 on pci2 > fxp0: Ethernet address 00:a0:c9:69:49:b4 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ahc0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 9 at device 10.0 on pci2 > aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs > pci2: at device 12.0 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > uhci0: port 0xef80-0xef9f irq 11 at device 31.2 on pci0 > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > pci0: at device 31.3 (no driver attached) > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 on acpi0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > sio0 port 0x3f8-0x3ff irq 4 on acpi0 > sio0: type 16550A > sio1 port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > ppc0 port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ata-: ata0 already exists, skipping it > ata-: ata1 already exists, skipping it > atkbdc-: atkbdc0 already exists, skipping it > fdc-: fdc0 already exists, skipping it > ppc-: ppc0 already exists, skipping it > sio-: sio0 already exists, skipping it > sio-: sio1 already exists, skipping it > sc-: sc0 already exists, skipping it > vga-: vga0 already exists, skipping it > pmtimer0 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ad0: 39082MB [79406/16/63] at ata0-master UDMA66 > acd0: CDROM at ata1-master PIO4 > Waiting 5 seconds for SCSI devices to settle > Mounting root from ufs:/dev/ad0s1a > Copyright (c) 1992-2001 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.0-CURRENT #1: Sat Dec 15 08:04:04 PST 2001 > jon@genesis.jons.org:/usr/obj/usr/src/sys/GENESIS > Preloaded elf kernel "/boot/kernel/kernel" at 0xc03f4000. > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 598476017 Hz > CPU: Pentium III/Pentium III Xeon/Celeron (598.48-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x673 Stepping = 3 > Features=0x383f9ff > real memory = 133955584 (130816K bytes) > avail memory = 126128128 (123172K bytes) > pnpbios: Bad PnP BIOS data checksum > Pentium Pro MTRR support enabled > VESA: v3.0, 16320k memory, flags:0x1, mode table:0xc03788a2 (1000022) > VESA: NVidia > Using $PIR table, 11 entries at 0xc00f2f60 > npx0: on motherboard > npx0: INT 16 interface > pcib0: at pcibus 0 on motherboard > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > pcm0: port 0xdf00-0xdf3f irq 11 at device 7.0 on pci2 > pcm0: ac97 codec invalid or not present (id == 0) > device_probe_and_attach: pcm0 attach returned 6 > fxp0: port 0xdf80-0xdf9f mem 0xfe900000-0xfe9fffff,0xf43ff000-0xf43fffff irq 10 at device 9.0 on pci2 > fxp0: Ethernet address 00:a0:c9:69:49:b4 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ahc0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 9 at device 10.0 on pci2 > aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs > pci2: at device 12.0 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > uhci0: port 0xef80-0xef9f irq 11 at device 31.2 on pci0 > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > pci0: at device 31.3 (no driver attached) > ata-: ata0 already exists, skipping it > ata-: ata1 already exists, skipping it > sc-: sc0 already exists, skipping it > vga-: vga0 already exists, skipping it > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ad0: 39082MB [79406/16/63] at ata0-master UDMA66 > acd0: CDROM at ata1-master PIO4 > Waiting 5 seconds for SCSI devices to settle > Mounting root from ufs:/dev/ad0s1a --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-psm *** sys/isa/psm.c.orig Sat Oct 13 18:28:02 2001 --- sys/isa/psm.c Tue Nov 6 09:35:25 2001 *************** *** 928,933 **** --- 928,934 ---- int mask; int rid; int i; + int irq; #if 0 kbdc_debug(TRUE); *************** *** 935,940 **** --- 936,952 ---- /* see if IRQ is available */ rid = KBDC_RID_AUX; + + irq = bus_get_resource_start(dev, SYS_RES_IRQ, rid); + if (irq <= 0) { + if (resource_long_value(PSM_DRIVER_NAME, + device_get_unit(dev), "irq", &irq) != 0) + irq = 12; /* XXX */ + device_printf(dev, "irq resource info is missing; " + "assuming irq %ld\n", irq); + bus_set_resource(dev, SYS_RES_IRQ, rid, irq, 1); + } + sc->intr = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE); if (sc->intr == NULL) { --sm4nu43k4a2Rpi4c-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 21: 7:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id E06B137B405 for ; Sat, 15 Dec 2001 21:07:08 -0800 (PST) Received: from pool0120.cvx40-bradley.dialup.earthlink.net ([216.244.42.120] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16FTVN-0004ER-00; Sat, 15 Dec 2001 21:06:30 -0800 Message-ID: <3C1C2BD7.577C5506@mindspring.com> Date: Sat, 15 Dec 2001 21:06:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Poul-Henning Kamp , Andrew Kenneth Milton , current@FreeBSD.ORG Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD References: <52753.1008153029@critter.freebsd.dk> <200112160043.fBG0hbS18659@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > I am aware that certain long-standing RMS-specific projects, > like emacs, require people who submit patches to sign-over their > copyright, but I am not aware of people generally signing > the copyright for their own GPL'd works over to the FSF. RMS > wnats people to, but as far as I can tell most people have no > desire to. The way ReiserFS does this is to affix a contract to the CVS change submission, or require that the contract be manually affixed to any email submissions. The rights are assigned, with the terms being "in consideration for examination of the submission" (it's not a contract unless there is consideration and exchange). The FSF handles this slightly differently, but the practical matter of the assignment is in effect the same. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Dec 15 23: 7: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 569C937B416 for ; Sat, 15 Dec 2001 23:07:01 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBG76uc19777; Sat, 15 Dec 2001 23:06:56 -0800 (PST) (envelope-from dillon) Date: Sat, 15 Dec 2001 23:06:56 -0800 (PST) From: Matthew Dillon Message-Id: <200112160706.fBG76uc19777@apollo.backplane.com> To: Terry Lambert Cc: Poul-Henning Kamp , Andrew Kenneth Milton , current@FreeBSD.ORG Subject: Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD References: <52753.1008153029@critter.freebsd.dk> <200112160043.fBG0hbS18659@apollo.backplane.com> <3C1C2BD7.577C5506@mindspring.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :The way ReiserFS does this is to affix a contract to the CVS change :submission, or require that the contract be manually affixed to any :email submissions. : :The rights are assigned, with the terms being "in consideration for :examination of the submission" (it's not a contract unless there is :consideration and exchange). : :The FSF handles this slightly differently, but the practical matter :of the assignment is in effect the same. : :-- Terry Yes, and I'm planning on doing something similar with the Backplane Database. It's a good idea, just not a good idea to assign your own works to someone else (e.g. not the FSF). The FSF can do whatever they want with their own code and can ask contributors to assign rights to them, but it is totally inappropriate for them to ask people to assign the copyright for other unrelated GPL'd works to them. Also, the latest version of the GPL in my view weakens it terribly. The way it reads, the copyright is not the copyright in the file but the latest copyright on FSF's site (which theoretically allows the FSF to update the copyright and have the new version automatically apply to preexisting works). I don't think it's even close to being legal. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message