Re: Why not gzip iso images?
On Wed, Mar 15, 2000 at 12:11:48PM -0800, Darryl Okahata wrote: While you are right about the download/gunzip times, compression doesn't help that much. As has been mentioned in -hackers, the ISO images only compress by 3% or so, or around ~20MB. So, instead of a 640MB ISO image, you have a 620MB image. Is the 20MB significant? (I don't know.) No, it isn't. I missed the -hackers discussion, sorry. 20Mb isn't worth the trouble, I was hoping it would be in the ballpark of 100-150 *sigh*. Someone else mentioned gzipping it just for error-checking; that doesn't seem to make much sense, as there're MD5 checksums available. -- Anatoly Vorobey, [EMAIL PROTECTED] http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Best NIC for FBSD (was: Buffer Problems and hangs in 4.0-CURRENT..)
In [EMAIL PROTECTED], Mike Smith wrote: fxp0: The Intel driver is by far the highest preformance model, beats the 3com (second best) hands down with much lower CPU overhead. Do you actually have any numbers to quantify this? There's nothing in the driver architecture nor any of my testing that would suggest this is actually the case at this point. I appended an old posting of mine. No 3com cards, though. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ Date: Mon, 8 Feb 1999 14:53:25 +0100 From: Martin Cracauer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: 100Mbit ethernet card comparision Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i I just had three 100MBit/sec ethernet cards in reach and though I could do a little experimenting: Operating Systems: FreeBSD: FreeBSD-current from Jan, 22, 1999 (before 4.0 branch) Linux: 2.2.0-pre9, userland mostly Debian-1.3.1 Ethernet cards: de - DEC 21140 fxp - Intel 82558 rl - Realtek 8139 Machine: Celeron 300A in Asus P2B (BX) at 4.5x83.5MHz Benchmark: Send 1 GB of data over a rsh connection, using cstream (a dd replacement with accurate timing, bandwidth limiting and /dev/null built in), using 8 KB blocks. The CPU numbers are taken from top(1) with a delay of 15 seconds. OS CardMioByte/sec %user %sys%interrupt -- Linux de 10.93-10.96 3 26-28 - FreeBSD de 10.70-10.72 3 29-31 4-5 FreeBSD fxp 10.66-10.67 3 25-28 5-6 FreeBSD rl 10.55-10.56 3 28-31 14-16 Linux rl 10.85-11.14 3 28-30 - Linux fxp doesn't work The fxp module (eepro100) on Linux loads, but ifconfiging hangs the machine (reset button mode). The de (tulip) driver on Linux needs manual selection of media type, whereas none of the other test combinations did (rl on Linux worked out of the box). Of course, Linux doesn't have section 4 manpages for drivers, so I went through the linux-src/Documentation - C-source - Web site mentioned in there cicle as well. And had to specify options at module load time (as compared to anytime with ifconfig under FreeBSD) and had to calculate hex number OR combinations (where FreeBSD has cleartext options). The Intel chip got hot, the Realtek and DEC stayed cool. Well, one intersting question is: Where's that interrupt handler CPU time on Linux? In system CPU time? Hidden? To get a clearer picture, I did a benchmark that approached the question "If two processes compete, and one just consumes userland CPU and the other just tries to TCP stream over a more or less interrupt intensive device, how much CPU does the CPU-intensive process get?" I run a number of dhrystones one after another so that the time for all of them was about 1 min. Just before the first dhrystone starts, the same TCP streaming benchmark as above is being started, and immedeatly after the dhrystones end SIGHUP is sent to the cstream tool, which ends its loop then and reports the throughput. OS/card seconds r/u/s onthroughput of on CPU process network process - FreeBSD/de: 10.36/10.26/0.022.10 MioB/sec FreeBSD/de: 10.36/10.26/0.022.21 MioB/sec FreeBSD/rl: 10.41/10.24/0.020.38 MioB/sec FreeBSD/rl: 10.39/10.24/0.020.28 MioB/sec FreeBSD/rl: 10.41/10.24/0.020.24 MioB/sec Linux/rl: 27.8/14.7/0.6 8.44 MioB/sec Linux/rl: 22.9/14.4/4.4 6.50 MioB/sec Linux/rl: 26.4/14.7/5.8 7.81 MioB/sec Linux/de: 20.7/14.6/0.9 9.21 MioB/sec Linux/de: 20.5/13.8/1.0 9.14 MioB/sec Linux/de: 21.0/14.2/1.2 9.64 MioB/sec Example read: With rl Ethernet, Linux leaves half the CPU for the CPU intensive process and gets ~8 MB/sec for the networking process, while FreeBSD leaves 99% CPU for the CPU eater and gets 0.25-0.4 MB/sec out of the networking connection. Remark: Don't ask me why a dhrystone takes more CPU on Linux than on FreeBSD. Identical source, gcc-2.7.2.x, timings verified with stopwatch etc. Probably a symbol more in a shared library. It is not a typo that time(1) reports significant system CPU for the dhrystones on some (but not all) of the Linux/rl runs. Definitivly bad accounting here. Quick shot answer: this looks like the time spent in the interrupt handle is being added to unrelated userland processes. Glad I asked: The supposed ninja-macho networker's tool FreeBSD is actually a little slower, while the supposed we-have-more-drivers-and-every-idiot-can-configure-them OS runs on one out of three cards without problems, one with enough digging to drive unconviced
Re: Trouble with CVSUP to 4.0 Release, any ideas??
On Thu, 16 Mar 2000, Howard Leadmon wrote: On Wed, 15 Mar 2000, Howard Leadmon wrote: Any ideas how to fix this, or to get to 4.0 RELEASE on my other alphas do I have to do a clean reload?? ../../sys/ucontext.h:34: invalid #-line ../../alpha/alpha/genassym.c:44: #-lines for entering and leaving files don't match Can I see the contents of /usr/src/sys/ucontext.h Sure, here is it is: It does look reasonable. I'm suspicious about your compiler binaries - you might have to reinstall after all. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FDDI cards in -current
Planning a router between FDDI and Fast Ethernet I'm wondering if I'm on the safe side when using FreeBSD 4.0-current for this project rather than being more conservative and use an older version of the OS. What FDDI cards could be recommended? (There aren't many, though, I believe). -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc -Os optimisation broken (RELENG_4)
I think that 'pentium' would result in code that isn't as optimized as 'pentiumpro', but I've heard that 'pentium' has a lot less problems. What??? 'pentiumpro' code isn't going to be very optimized for a Pentium (if it even runs at all). I've heard that -mpentiumpro can be pretty buggy, and it can actually result in slower code than -mpentium for certain pentium types. Yea like the original P5 Pentiums. You should match the command line with your actual machine if you are going to use these options. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Trouble with CVSUP to 4.0 Release, any ideas??
Any ideas how to fix this, or to get to 4.0 RELEASE on my other alphas do I have to do a clean reload?? ../../sys/ucontext.h:34: invalid #-line ../../alpha/alpha/genassym.c:44: #-lines for entering and leaving files don't match Can I see the contents of /usr/src/sys/ucontext.h Sure, here is it is: It does look reasonable. I'm suspicious about your compiler binaries - you might have to reinstall after all. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd.Phone: +44 181 442 9037 The strange part is that I have done this on two different Alpha machines, neither of which were more than a month behind on the CVS tree. I tried to update both to 4.0-RELEASE (RELENG_4 tag) and both are now in that state, so now I am totally afraid to even consider upgrading the other two to the release code. So whatever happened, was very easily reproduceable as I did it two times in a row. :( Has anyone updated a mid-febuary 4.0 to the RELEASE code on Alpha via CVS and had it go smooth, and if so what steps did you use to get there?? --- Howard Leadmon - [EMAIL PROTECTED] - http://www.abs.net ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
I notice someone posted this the other day Never have not seen a response...so...this is 5.0 CURRENT make world from cvsup March 15. ys/boot/i386/libi386/biosdisk.c -o biosdisk.o/usr/src/sys/boot/i386/libi386/biosdisk.c: In function `bd_print':/usr/src/sys/boot/i386/libi386/biosdisk.c:242: syntax error before `,'/usr/src/sys/boot/i386/libi386/biosdisk.c:289: case label not within a switch statement/usr/src/sys/boot/i386/libi386/biosdisk.c:293: default label not within a switchstatement/usr/src/sys/boot/i386/libi386/biosdisk.c: At top level:/usr/src/sys/boot/i386/libi386/biosdisk.c:301: syntax error before `}'/usr/src/sys/boot/i386/libi386/biosdisk.c:103: warning: `bd_printslice' used butnever defined/usr/src/sys/boot/i386/libi386/biosdisk.c:106: warning: `bd_strategy' used but never defined/usr/src/sys/boot/i386/libi386/biosdisk.c:108: warning: `bd_open' used but neverdefined/usr/src/sys/boot/i386/libi386/biosdisk.c:109: warning: `bd_close' used but never defined/usr/src/sys/boot/i386/libi386/biosdisk.c:103: warning: `bd_printslice' used butnever defined/usr/src/sys/boot/i386/libi386/biosdisk.c:106: warning: `bd_strategy' used but never defined/usr/src/sys/boot/i386/libi386/biosdisk.c:108: warning: `bd_open' used but neverdefined/usr/src/sys/boot/i386/libi386/biosdisk.c:109: warning: `bd_close' used but never defined/usr/src/sys/boot/i386/libi386/biosdisk.c:123: warning: `bd_opendisk' used but never defined/usr/src/sys/boot/i386/libi386/biosdisk.c:124: warning: `bd_closedStop in /usr/src/sys/boot/i386.*** Error code 1Stop in /usr/src/sys/boot.*** Error code 1Stop in /usr/src/sys.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.
No Subject
I notice someone posted this the other day Never have not seen a = response...so...this is 5.0 CURRENT make world from cvsup March 15. Hi, Please check your version of /usr/src/sys/boot/i386/libi386/biosdisk.c. This was fixed yesterday. welpje:[sys/boot/i386/libi386] % grep '$FreeBSD:' biosdisk.c * $FreeBSD: src/sys/boot/i386/libi386/biosdisk.c,v 1.28 2000/03/15 16:36:55 jhb Exp $ - marcel ys/boot/i386/libi386/biosdisk.c -o biosdisk.o /usr/src/sys/boot/i386/libi386/biosdisk.c: In function `bd_print': /usr/src/sys/boot/i386/libi386/biosdisk.c:242: syntax error before `,' /usr/src/sys/boot/i386/libi386/biosdisk.c:289: case label not within a = switch st atement /usr/src/sys/boot/i386/libi386/biosdisk.c:293: default label not within = a switch statement /usr/src/sys/boot/i386/libi386/biosdisk.c: At top level: /usr/src/sys/boot/i386/libi386/biosdisk.c:301: syntax error before `}' /usr/src/sys/boot/i386/libi386/biosdisk.c:103: warning: `bd_printslice' = used but never defined /usr/src/sys/boot/i386/libi386/biosdisk.c:106: warning: `bd_strategy' = used but n ever defined /usr/src/sys/boot/i386/libi386/biosdisk.c:108: warning: `bd_open' used = but never defined /usr/src/sys/boot/i386/libi386/biosdisk.c:109: warning: `bd_close' used = but neve r defined /usr/src/sys/boot/i386/libi386/biosdisk.c:103: warning: `bd_printslice' = used but never defined /usr/src/sys/boot/i386/libi386/biosdisk.c:106: warning: `bd_strategy' = used but n ever defined /usr/src/sys/boot/i386/libi386/biosdisk.c:108: warning: `bd_open' used = but never defined /usr/src/sys/boot/i386/libi386/biosdisk.c:109: warning: `bd_close' used = but neve r defined /usr/src/sys/boot/i386/libi386/biosdisk.c:123: warning: `bd_opendisk' = used but n ever defined /usr/src/sys/boot/i386/libi386/biosdisk.c:124: warning: `bd_closed Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. =20 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cs89x0 driver update (fwd)
I sent my changes to Mike Smith [EMAIL PROTECTED] 12 Mar 2000, but still have no answer, unfortunately I have no commit privs, so somebody have to commit it for us. I thought that Mike have to, just because he commit our previous version of driver. If you can commit it I'll have no objection. We're going to add mibs support in this driver, it'll be in a few weeks. Max. On Tue, 14 Mar 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Maxim Bolotin writes: : We found that our driver doesn't work with PNP in 4.0 and : use old, shared memory softc scheme. We rewrite it for the : new scheme, now We can install it in dev/cs and remove : isa_compat.c lines. I belive we have to commit it before : 4.0 release. I suspect that it is way too late to be included in 4.0, but can be included in 4.0-stable once 4.0 is out the door. Since Jkh has put down the tags already and has started building I think that it can just goin to -current and -stable at the same time. Max, do you have commit privs? If not, then I'll shepard this into the tree. My company uses an allinone computer with the CS8900A on it and we need support for this chip. Warner [[ cc'd to current so committers there know it is being worked on ]] - Rostov State University Computer Center Rostov-on-Don, +7 (8632) 285794 or 357476 Russia, RUNNet, MAB1-RIPE [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc -Os optimisation broken (RELENG_4)
Doug Barton [EMAIL PROTECTED] wrote: Hmm... If I have a PII (Actually celeron 300A) or a PIII, which is better, 'pentium' or 'pentiumpro'? I would think the latter, but I've I have to admit that I kind of lost track of Intel's Pentium du jour offerings after the PPro, but I think PII and PIII use i686 cores or at least something closest to i686, so I'd use -mpentiumpro there. I don't pretend to have any idea what's appropriate for the various AMD/Cyrix/IDT/etc processors. The machines where I use -mpentium and -mpentiumpro, respectively, are an actual Intel Pentium and a (dual) Intel Pentium Pro. Yes, there are people out there who don't buy a new machine each quarter. Also, I have heard conflicting reports as to whether compiling the kernel/world with optimisations is a good thing. Anyone care to (re)open that can of worms? No new worms in there, I suspect. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc -Os optimisation broken (RELENG_4)
David O'Brien [EMAIL PROTECTED] wrote: What??? 'pentiumpro' code isn't going to be very optimized for a Pentium (if it even runs at all). According to the gcc(1) man page, -mpentiumpro is synonymous to -mcpu=pentiumpro, which only affects instruction scheduling but not the actual instruction set used (for that, use -march=...). So it certainly should run. If you are aware that the man page is wrong in this respect, please tell us! -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Trouble with CVSUP to 4.0 Release, any ideas??
Howard Leadmon writes: Has anyone updated a mid-febuary 4.0 to the RELEASE code on Alpha via CVS and had it go smooth, and if so what steps did you use to get there?? Yes, at least 3. But my methods are rather unconventional. On my build machine, which is running a 4.0-current box from mid January, I updated my source tree to 4.0-RELEASE via: cvs -R -d /home/ncvs up -r RELENG_4_0_0_RELEASE I then built the world on this machine via make buildworld, and nfs-exported /usr/src and /usr/obj. On each target machine, I mount buildhost:/usr /usr and buildhost:/usr/obj /usr/obj do a make installworld. I've had no problems at all. One thing to check would be: did your installworld acutally complete? At one point the installworld was falling over in h2ph when a crypto-related header file was being perl'ified. If this is your problem, try doing a 'make -i installworld' Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: 3.x - 4.0-STABLE upgrade instructions
Original Message On 3/16/00, 2:52:36 AM, Brandon Fosdick [EMAIL PROTECTED] wrote regarding Re: HEADS UP: 3.x - 4.0-STABLE upgrade instructions: Warner Losh wrote: In message [EMAIL PROTECTED] Doug Barton writes: : You can find instructions at : http://freebsd.simplenet.com/make-upgrade.html. I am planning to update : that file for 3.4 - 4.0 asap BTW. Let me know if the following doesn't work: To update from 3.x to 4.0 stable cd /usr/src make buildworld cd sbin/mknod make install follow directions to build/install a kernel follow rebuild disk /dev entries above[*] reboot in single user cd /usr/src make -DNOINFO installworld make installworld [*] You may need to switch from wd to ad ala 19991210 To build a kernel - Update config, genassym and go: cd src/usr.bin/genassym make depend all install cd ../../usr.sbin/config make depend all install cd ../../sys/i386/conf config YOUR_KERNEL_HERE cd ../../compile/YOUR_KERNEL_HERE make depend make make install To rebuild disk /dev entries MAKEDEV should be copied from src/etc/MAKEDEV to /dev before starting the following: For N in the list of disks MAKEDEV N # eg ad0 for M in the list of slices MAKEDEV NsMa# eg ad0s1a How to go about switching over from wd to ad needs to be explained a little better. After doing the MAKEDEV routine I went and changed all the wd's in my fstab to ad's. Boy was that a mistake. Now I have to find somthing I can boot with that will let me mount the root partition read/write so that I can change fstab back. On top of that my cdrom suddenly decided to non-bootable. Maybe I'm just having a bad day... -Brandon Dear Brandon Fosdick, the (almost complete) updating procedure lies before you [was: Nature ;-)]. I am afraid the difficulties do NOT consist in making the devices nodes and the related slice entries. The following questions arise spontaneously. Q0) Have you been reading the -CURRENT mailing list archives for a while? In particular, have you read the letters posted in the last few weeks ? Q1) Did you exactly do as described in the procedure ? That is, if your disk is ,say, wd0, did you make an ad0 device node ? Did you make the *slice* entries, in our example ad0s1a (which makes ados1a through ad0s1h), as indicated there ? Did you update your /etc/fstab accordingly ? Did you substitute ad* for wd* in all your configuration files ? Q2) Have you read the very recent letters on the updating procedure (as of yesterday and today) ? Q3) Have you appropriately used the -k (ie force) option when making installworld ? Mind you, I missed the "cleaning" issue (you should not use the clean target in genassym etc. when making your first 4.0 kernel.) However, I succeeded in upgrading (though not all components were actually built). I did not care. Rather, I made the world again and checked my install logs (and they looked ok): now my 4.0-CURRENT (or should I say 4-STABLE ;-) seems to work like charm. At least, so far ... Good luck Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Jumped across a month and left dc behind.
I've been using the dc driver without a hitch but when I updated to current two days ago dc stopped working. Symptoms are no link light on the hub and ifconfig reports no-carrier. Lights are on on the NIC though. Enumerating the varieties of media/mediaopt has no effect. Fortunately, there is the de driver, geriatric it may be, but it works. Not one thing was changed but the update of a just pre-ipv6 system to current. (Fully expecting to get the full gin-joint treatment here shortly :-) Russell Here's two snippets from messages, 1st with dc configured and then de: Here's the probe for dc, which doesn't work (but used to): Mar 16 07:46:21 chomsky /kernel: CPU: AMD-K7(tm) Processor (503.53-MHz 686-class CPU) Mar 16 07:46:21 chomsky /kernel: Origin = "AuthenticAMD" Id = 0x612 Stepping = 2 Mar 16 07:46:21 chomsky /kernel: Features=0x81f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,M CE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX Mar 16 07:46:21 chomsky /kernel: AMD Features=0xc040AMIE,DSP,3DNow! Mar 16 07:46:21 chomsky /kernel: real memory = 268435456 (262144K bytes) Mar 16 07:46:21 chomsky /kernel: avail memory = 257286144 (251256K bytes) Mar 16 07:46:21 chomsky /kernel: Preloaded elf kernel "kernel" at 0xc02eb000. Mar 16 07:46:21 chomsky /kernel: Pentium Pro MTRR support enabled Mar 16 07:46:21 chomsky /kernel: npx0: math processor on motherboard Mar 16 07:46:21 chomsky /kernel: npx0: INT 16 interface Mar 16 07:46:21 chomsky /kernel: pcib0: AMD-751 host to PCI bridge on motherboard Mar 16 07:46:21 chomsky /kernel: pci0: PCI bus on pcib0 Mar 16 07:46:21 chomsky /kernel: pcib1: AMD-751 PCI-PCI (AGP) bridge at device 1.0 on pci0 Mar 16 07:46:21 chomsky /kernel: pci1: PCI bus on pcib1 Mar 16 07:46:21 chomsky /kernel: isab0: VIA 82C686 PCI-ISA bridge at device 4.0 on pci0 Mar 16 07:46:21 chomsky /kernel: isa0: ISA bus on isab0 Mar 16 07:46:21 chomsky /kernel: atapci0: VIA 82C686 ATA66 controller port 0xffa0-0xffaf at device 4.1 on pci0 Mar 16 07:46:21 chomsky /kernel: ata0: at 0x1f0 irq 14 on atapci0 Mar 16 07:46:21 chomsky /kernel: ata1: at 0x170 irq 15 on atapci0 Mar 16 07:46:21 chomsky /kernel: pci0: VIA 83C572 USB controller at 4.2 irq 11 Mar 16 07:46:21 chomsky /kernel: pci0: VIA 83C572 USB controller at 4.3 irq 11 Mar 16 07:46:21 chomsky /kernel: chip1: VIA 82C686 ACPI interface at device 4.4 on pci0 Mar 16 07:46:21 chomsky /kernel: chip2: VIA 82C686 AC97 Audio port 0xc800-0xc803,0xcc00-0xcc03,0xd000-0xd0ff irq 10 at device 4.5 on pci0 Mar 16 07:46:21 chomsky /kernel: dc0: Intel 21143 10/100BaseTX port 0xbc00-0xbc7f mem 0xeeffef80-0xeeffefff irq 12 at device 13.0 on pci0 Mar 16 07:46:21 chomsky /kernel: dc0: Ethernet address: 00:80:c8:63:47:84 Mar 16 07:46:21 chomsky /kernel: miibus0: MII bus on dc0 Mar 16 07:46:21 chomsky /kernel: dcphy0: Intel 21143 NWAY media interface on miibus0 Mar 16 07:46:21 chomsky /kernel: dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto And here is the probe for de, which works: Mar 16 07:56:58 chomsky /kernel: de0: Digital 21143 Fast Ethernet port 0xbc00-0xbc7f mem 0xeeffef80-0xeeffefff irq 12 at device 13.0 on pci0 Mar 16 07:56:58 chomsky /kernel: de0: 21143 [10-100Mb/s] pass 3.0 Mar 16 07:56:58 chomsky /kernel: de0: address 00:80:c8:63:47:84 Mar 16 07:56:58 chomsky /kernel: de0: driver is using old-style compatability shims To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: B_WRITE cleanup patch, please test!
Poul-Henning Kamp wrote: http://phk.freebsd.dk/misc/b_iocmd.patch I concur that these patches represent effectlively a mechanical edit of the sources to produce effectively the same functionality as before. I have a couple of points which I would like to discuss. These are not complaints, just discussion points 1/ I think the removal of IPSEC from LINT is by mistake in this patch 2/ The change of separating buffer management from IO management is long overdue and the introduction of b_iocmd is a good first step for this. The selection of values is in my mind arguable either way. As the field is an 'op-code' I would have chosen the values to be: #define BIO_NOP 0 #define BIO_READ 1 #define BIO_WRITE 2 #define BIO_DELETE 3 #define BIO_OP 0x03 /* The bit mask for the basic operation*/ I notice that you Strategy macro checks for illegal values, but wonder whether it might be better to make illegal values 'impossible'. This is a pure style/scope question. 3/ The removal of B_CALL, and the use of the non-null value of the vector is an editing change only and not really controversial. It does simplify the question of whether the field belongs in the IO control part of the buffer control part. 4/ does this produce compatibility problems with any 3rd party code? Over all this edit is a functional not and a move in the right direction from a scope point of view. Unless someone else can think of reasons, I have nothing against it. People I'd like to see as having looked at it however, include Matt and Kirk. B_WRITE is bogusly defined as zero, which is a perfect candidate for coding and logic mistakes, we saw the most recent victim of this bogosity as recently as a few days ago. This patch moves the "io-command" aspect of the b_flags into a new struct buf field called b_iocmd. This patch is the first step towards the stackable BIO system as sketched out on http://www.freebsd.org/~phk/Geom/ Please test review. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: B_WRITE cleanup patch, please test!
In message [EMAIL PROTECTED], Julian Elischer writes: 1/ I think the removal of IPSEC from LINT is by mistake in this patch yes, that is a mistake. 2/ The change of separating buffer management from IO management is long overdue and the introduction of b_iocmd is a good first step for this. The selection of values is in my mind arguable either way. As the field is an 'op-code' I would have chosen the values to be: #define BIO_NOP 0 #define BIO_READ 1 #define BIO_WRITE 2 #define BIO_DELETE 3 I decided to use binary values, because there is a simple arithmetic test for "exactly one bit set" (See BUF_STRATEGY). I wanted to catch as many bogus cases of B_WRITE zeroness being abused as possible, ie, people initializing b_flags = 0 knowing that would give them a write. 4/ does this produce compatibility problems with any 3rd party code? This is 5.0-CURRENT, they will have to adopt to much worse things before it becomes 5.0-RELEASE. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FDDI cards in -current
If memory serves me right, Christoph Kukulies wrote: Planning a router between FDDI and Fast Ethernet I'm wondering if I'm on the safe side when using FreeBSD 4.0-current for this project rather than being more conservative and use an older version of the OS. You mean 4.0-stable, right? :-) My really touchy-feely opinion is that either way is probably going to be fine, but my machines are research platforms, not production routers. What FDDI cards could be recommended? (There aren't many, though, I believe). Here's what's supported: fpa(4), fea(4) - Device Drivers for DEC FDDI Controllers fpa is a PCI card, fea is EISA. Bruce. PGP signature
Re: FDDI cards in -current
On Thu, 16 Mar 2000, Christoph Kukulies wrote: Planning a router between FDDI and Fast Ethernet I'm wondering if I'm on the safe side when using FreeBSD 4.0-current for this project rather than being more conservative and use an older version of the OS. fpa0: Digital DEFPA PCI FDDI Controller port 0xe400-0xe47f mem 0xfafd-0xfafd,0xfafee000-0xfafee07f irq 4 at device 6.0 on pci0 fpa0: DEC DEFPA PCI FDDI SAS Controller fpa0: FDDI address 00:00:f8:40:e4:a8, FW=2.46, HW=0, SMT V7.2 fpa0: FDDI Port = S (PMD = Unshielded Twisted Pair) Seems to work fine for me. What FDDI cards could be recommended? (There aren't many, though, I believe). Well, you've got 1 card family to pick from with several different models (bus type and media). I'm guessing that you're not gonna be getting any EISA boards so you'll want to get a 'DEFPA-??' where ?? indicates the media. I keep meaning to spend some time to resync our drivers with NetBSD's and to convert over the PCI bus front end stuff but haven't gotten around to it; this is the reason for this message: fpa0: driver is using old-style compatability shims which doesn't affect the operation of the board. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FDDI cards in -current
On Thu, 16 Mar 2000 07:56:33 -0800, [EMAIL PROTECTED] (Bruce A. Mah) said: Here's what's supported: fpa(4), fea(4) - Device Drivers for DEC FDDI Controllers fpa is a PCI card, fea is EISA. Note that finding any FDDI hardware these days is getting to be quite expensive. The manufacturers of FDDI silicon announced late last year that they were no longer accepting new orders for the chips, so once the current inventory is used up, there will be no more FDDI products available on the original-sale market (i.e., new). There appear to be a couple of DEFEA's available for sale on eBay, and one lot of two DEFPA's. The original poster is probably better off getting a used FDDI-Fast Ethernet bridge, and running his router Ethernet-only. ObCurrent: I'd be more willing to trust a good, maintained Fast Ethernet driver, like dc(4) or fxp(4), than a rusty FDDI driver. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cs89x0 driver update (fwd)
On Thu, 16 Mar 2000, Maxim Bolotin wrote: I sent my changes to Mike Smith [EMAIL PROTECTED] 12 Mar 2000, but still have no answer, unfortunately I have no commit privs, so somebody have to commit it for us. I thought that Mike have to, just because he commit our previous version of driver. If you can commit it I'll have no objection. We're going to add mibs support in this driver, it'll be in a few weeks. I've asked for the current driver to be repo-copied to sys/dev/cs/ so that the update won't lose CVS history. I'll shoot off a message to core about commit privs so you can maintain it yourself. If you don't mind the wait then you can commit the updates yourself in a week or so. :) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [sound] PCI ESS support
Darryl Okahata wrote: [EMAIL PROTECTED] (Munehiro Matsuda) wrote: No, I don't have real ESS docs. Thanks, anyway. I have 1)the usual DSMaestro2E 3-02-98.pdf datasheet, 2)some small stuff I grabbed off ftp.esstech.com.tw (nolonger exists on the site?) and I have just got this doc. is anyone going to work on this? My dell seems to have one of these things in it. There are hidden files on ftp.esstech.com.tw. Just go to: ftp://ftp.esstech.com.tw/PCIAudio/Maestro2E/ "PCIAudio" is an hidden directory. great! 3)source code for Maestro 2E Board Test (BTM2E.EXE) program which I downloaded from ftp://ftp.alsa-project.org/pub/manuals/ess/maestro.tar.gz. I'll check there in a minute :-) Thanks for the pointer. I'll check it out. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cs89x0 driver update (fwd)
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Thu, 16 Mar 2000, Maxim Bolotin wrote: : I sent my changes to Mike Smith [EMAIL PROTECTED] 12 Mar 2000, but : still have no answer, unfortunately I have no commit privs, so : somebody have to commit it for us. I thought that Mike have to, : just because he commit our previous version of driver. If you can commit : it I'll have no objection. : : We're going to add mibs support in this driver, it'll be in a few : weeks. : : I've asked for the current driver to be repo-copied to sys/dev/cs/ so that : the update won't lose CVS history. I'll shoot off a message to core about : commit privs so you can maintain it yourself. If you don't mind the wait : then you can commit the updates yourself in a week or so. :) I have a slot in my day today to test and commit this driver. As luck would have it, we need 4.0 on one of our embedded boards that has this exact chip. I don't see why core would turn down a request like this for commit privs, but I'd be happy to test/commit any improvements to the driver. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re[2]: gcc -Os optimisation broken (RELENG_4)
-Original Message- From: Dan Nelson [EMAIL PROTECTED] To: "David O'Brien" [EMAIL PROTECTED] Date: Wed, 15 Mar 2000 15:57:27 -0600 Subject: Re: gcc -Os optimisation broken (RELENG_4) In the last episode (Mar 15), David O'Brien said: On Wed, Mar 15, 2000 at 10:51:55AM -0600, Dan Nelson wrote: I get it with -O2 (-Os implies -O2, so it's probably the same problem). Not quite. -0s == all the -O2 optimizations that do not increase code size. -Os can also perform other optimizations not part of -O2 that decrease code size. The -Os == -O2 only tells you how "risky" in optimizing -Os is willing to be. Too risky, apparently :) Maxim: It looks like you've done quite a big of debugging already; can you get this bug to appear in a small piece of code? I'm sure the gcc developers would be able to fix the problem pretty quickly if it's easily reproducable. I'll try to. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [sound] PCI ESS support
Julian Elischer [EMAIL PROTECTED] wrote: I have 1)the usual DSMaestro2E 3-02-98.pdf datasheet, 2)some small stuff I grabbed off ftp.esstech.com.tw (nolonger exists on the site?) and I have just got this doc. is anyone going to work on this? Well, I was going to take Ville-Pertti Keinonen's ([EMAIL PROTECTED]) ESS2 mixer code and turn it into an LKM, which I'd then try to add sound output using the Linux code. However, I'm not familiar with how one accesses interrupts and DMA under FreeBSD, and so it would take me a while. If anyone else would like to do it, that's fine with me. My dell seems to have one of these things in it. As does mine. ;-( I really want sound output on my 7500. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cs89x0 driver update (fwd)
On Thu, 16 Mar 2000, Warner Losh wrote: In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Thu, 16 Mar 2000, Maxim Bolotin wrote: : I sent my changes to Mike Smith [EMAIL PROTECTED] 12 Mar 2000, but : still have no answer, unfortunately I have no commit privs, so : somebody have to commit it for us. I thought that Mike have to, : just because he commit our previous version of driver. If you can commit : it I'll have no objection. : : We're going to add mibs support in this driver, it'll be in a few : weeks. : : I've asked for the current driver to be repo-copied to sys/dev/cs/ so that : the update won't lose CVS history. I'll shoot off a message to core about : commit privs so you can maintain it yourself. If you don't mind the wait : then you can commit the updates yourself in a week or so. :) I have a slot in my day today to test and commit this driver. As luck would have it, we need 4.0 on one of our embedded boards that has this exact chip. I don't see why core would turn down a request like this for commit privs, but I'd be happy to test/commit any improvements to the driver. Anyway, I would be happy to have commit privs for this driver. We have more than 70 cards. I'm going to maintain it by myself. I agree with Matthew that we have to save the history in CVS. Max. - Rostov State University Computer Center Rostov-on-Don, +7 (8632) 285794 or 357476 Russia, RUNNet, MAB1-RIPE [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible simple install-info fix
Ruslan Ermilov wrote: I was looking into fixing the install-info problem, and wondered if the solution is really as easy as it seems: Hmmm I had been thinking all along that the problem with install-info was that the system couldn't use the new binary. Are you saying here that installworld is trying to use the old version of install-info that is installed in the system? Please say it isn't so... Yes, it is using the old binary. There were plans (Marcel?) to commit an installation tools support into src/Makefile.inc1, but it was postponed until 4.0-RELEASE is done. This is now happened, and I expect Marcel committing his staff soon. All that needs to be done is build install-info by the bootstrap-tools stage. It will then be used throughout the build and install stages (after applying the patch :-). This of course assumes that the new install-info is backward compatible with the previous version. The bootstrap-tools stage is designed to solve incompatibilities caused by versions of tools installed on the system and the requirements (for newer ones) by the source-tree. If install-info is needed to do installworld, shouldn't it be considered a build tool, with all of the build platform/install platform gymnastics that implies? install-info is already built as part of build-tools stage, but there are two problems. This is a bug. If install-info is installed, then it isn't a build tool. Build tools are programs/scripts that are needed to build the sources only. They are not installed. Since install-info is installed, it can't be a build tool. this means that we either use the installed version or use a freshly built version made during the bootstrap stage. First, it is not currently used at the installworld stage, which Marcel's patch fixes. Correct. Installworld is using installed binaries (even though newer ones have been made by the bootstrap stage) *and* it is using binaries it has installed already and which may not even be runnable by the current kernel. Second, less important (IMHO), is a cross building issue. Consider the case, when you want to build 4.0 alpha world on 3.x i386 system, and then install it (world) on alpha running 3.x. It was discussed about month ago on -current... I don't consider this less important. Having the ability to do cross builds helps maintaining FreeBSD on multiple platforms and also helps in porting to new platforms. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rpc.lockd and XDR 64bit
Now that the code freeze is over, can the 64Bit XDR changes be made? This is the only thing preventing the next release of the rpc.lockd code at this point. -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not gzip iso images?
At 11:09 PM 3/15/00 +0100, Oliver Fromme wrote: That's true. Most of the files in the ISO images are already compressed, so trying to gzip it saves only a few percent. Also take into account that many people are downloading and recoding the images on Windows boxes, which don't have gzip by default. And then they can xfer it over to their FBSD system, etc.. Jordan kindly provides MD5 checksums of the ISO images, which are much more reliable than gzip's checksums. Shows how infrequently I look where the ISO's are. That would just make things more complicated, and there's no reason for that. That's what the "reget" command is good for -- no reason to start over at all. Agreed. Breaking them apart would be a hassle. Frankly I just tossed out a few things for cannon fodder. Those familiar with the CDs should know they won't compress much and should choose an alternative to DL'ing the ISO. FTP install or subscription. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not gzip iso images?
On Thu, Mar 16, 2000 at 01:12:39PM -0600, Jeffrey J. Mountin wrote: Also take into account that many people are downloading and recoding the images on Windows boxes, which don't have gzip by default. And then they can xfer it over to their FBSD system, etc.. You're suggesting that folks who burn CDs in order to install FreeBSD should have a FreeBSD machine handy? (Blah, anyway. This is a silly discussion. Why are people who are bandwidth-starved downloading ISOs in the first place?) -- Matthew Hunt [EMAIL PROTECTED] * Stay close to the Vorlon. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc -Os optimisation broken (RELENG_4)
At 01:42 PM 3/16/00 +0100, Christian Weisgerber wrote: David O'Brien [EMAIL PROTECTED] wrote: What??? 'pentiumpro' code isn't going to be very optimized for a Pentium (if it even runs at all). According to the gcc(1) man page, -mpentiumpro is synonymous to -mcpu=pentiumpro, which only affects instruction scheduling but not the actual instruction set used (for that, use -march=...). So it certainly should run. If you are aware that the man page is wrong in this respect, please tell us! Wondering why one would use -mcpu and not -march. If the code runs only on Celerons, PII's, and PIII's why would one *not* use -march. I'm curious about (possible) breakages with -mcpu or -march compared to -Ox settings which seem to break things more often than -O. Only ask, since -Ox and individual flags (rather than the mulititude added going from -O to -O2) are used far more often. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata + vinum problems
On Wednesday, 15 March 2000 at 16:29:03 -0500, Mathew Kanner wrote: On Mar 15, Mathew Kanner wrote: On Mar 15, Soren Schmidt wrote: Btw are you running the latest 4.0 or -current code ? there was a time when we had problems with the HPT and Promise controllers ? The kernel in question was cvsup'ed right at the change. I'm going to try 4.0 today. Replying to myself. By now this is probably the wrong list. I'm not sure what to do anymore. I've tried to set the bios settings back to what I've had when it worked it it doesn't seem to want to go. I've set the drives for ata/66 and ata/33. I've moved IRQ's around and even tried forcing them. Here are sets of dmesg and backtraces. This also happens with a kernel and modules compiled on sunday. The part that really bothers me is that I have a nearly identical machine, except for an extra drive in it that originally had the same problems but when I disabled the extra periphs, the problem went away. I'm a bit behind in my mail, and I don't have time to give this proper attention yet, but I do see that your problem relates to soft updates. It's not clear that the soft updates themselves are a cause of the problem, or just a facilitator, but it would be interesting to see what happens if you turn them off. Note also that there are some bogons in your config, to judge by the vinum startup messages. I'll analyse this in a day or two when I (hopefully) have more time. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not gzip iso images?
Speaking of ISOs, where is the 4.0-RELEASE ISO, I need it to do up this machine which I wanna format and install 4.0 clean =/ Matt -- Matt Heckaman [[EMAIL PROTECTED]|[EMAIL PROTECTED]] [Please do not send me] !Powered by FreeBSD/x86! [http://www.freebsd.org] [any SPAM (UCE) e-mail] On Thu, 16 Mar 2000, Matthew Hunt wrote: : Date: Thu, 16 Mar 2000 14:24:42 -0500 : From: Matthew Hunt [EMAIL PROTECTED] : To: Jeffrey J. Mountin [EMAIL PROTECTED] : Cc: [EMAIL PROTECTED] : Subject: Re: Why not gzip iso images? : : On Thu, Mar 16, 2000 at 01:12:39PM -0600, Jeffrey J. Mountin wrote: : : Also take into account that many people are downloading and : recoding the images on Windows boxes, which don't have gzip : by default. : : And then they can xfer it over to their FBSD system, etc.. : : You're suggesting that folks who burn CDs in order to install : FreeBSD should have a FreeBSD machine handy? : : (Blah, anyway. This is a silly discussion. Why are people who : are bandwidth-starved downloading ISOs in the first place?) : : -- : Matthew Hunt [EMAIL PROTECTED] * Stay close to the Vorlon. : http://www.pobox.com/~mph/ * : : : To Unsubscribe: send mail to [EMAIL PROTECTED] : with "unsubscribe freebsd-current" in the body of the message : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic during make depend
At 11:01 PM 3/15/00 -0500, Donn Miller wrote: Sounds like one of those nasty gcc optimization bugs. I generally build my kernel and world with -mpentium -O3 -pipe, and I haven't seen any bugs at all. I build everything with these flags without problems. The only problems I've see, as mentioned previously, was in building Qt. I've gotten an "Internal compiler error" with those flags, but reverting to what Troll put in qt/configs solved the problems. Apparently, there's both compile-time and run-time bugs with gcc's opt. code. It might be, but I'm backing off from -02 to -O for a dozen builds or so and see. Less if panics keep coming, then the -march will be dropped. All good then back to -02 and try -mcpu. I think there are some bugs with the pentium-specific flags in gcc, excluding the generic-pentium flag of -mpentium. I would try using -mpentium -O3 -pipe --- I'm pretty confident that will solve your problems, and you can still get generic pentium optimization levels. Why use -O3, which adds -finline-functions. AFAICR, that one isn't very liked by those more with more knowledge and experience. Of course, I don't really know if there's anything to be gained by using these flags over the stock -O -pipe -- but I do it anyways for the psychological reassurance (placebo effect). I definitely think building XFree86 with pentium opt. is a great idea. But with buildworld and buildkernel, my advice would be to just use -mpentium, as it's probably the "happiest medium" between pentium opt. and stability. From what I've heard, compiling mission critical stuff with -mpentiumpro is a bad idea. Hmmm... didn't -mpentiumpro come from pgcc? I think the best place to use -mpentiumpro is in compiling multimedia type stuff, where stability isn't important but speed is. Don't think your reasoning is all that sound as a "reassurance," but ensuring that code is optimized for the CPU, and in my case architecture, is good. Originally thought that using -march would speed up compiling for one and another to have more specific code for the system running it. Been a while since I had a running 486, 8+ years since even seeing a 386, and only have 2 pentiums in operation, so why should the code have instructions for running on any of these platforms? As an example I've seen many posts with -mno-486 used. The man page is clear as mud on what that does. From the wording it should optimize the code for a 386 then: -mno-486 Control whether or not code is optimized for a 486 instead of an 386. Code generated for a 486 will run on a 386 and vice versa. Perhaps the man pages need updating. Basically, gcc is a very good compiler. But, it isn't exactly the best compiler to use for optimization. Someone told me that Sun's and DEC's compilers, for example, blow away gcc in terms of speed. But, they aren't portable. The DEC compiler might be good for some FBSD users. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Trouble with CVSUP to 4.0 Release, any ideas??
On Thu, 16 Mar 2000, Andrew Gallatin wrote: One thing to check would be: did your installworld acutally complete? At one point the installworld was falling over in h2ph when a crypto-related header file was being perl'ified. If this is your problem, try doing a 'make -i installworld' Yep; the problem can be fixed by doing 'make includes; make installworld' - it's caused by a dangling link (des.h) having nothing to point to at the time the perlification runs. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RealPlayer 7
Anyone get this beast to work on -current? The audio works, but the video doesn't work at all. I have COMPAT_LINUX in my kernel, and RealPlayer 5.0 works pretty well. $ printenv LD_LIBRARY_PATH /usr/local/qt/lib:/usr/local/lib/rvplayer5.0:/usr/local/RealPlayer7/Common:/usr/local/RealPlayer7/Codecs:/usr/local/RealPlayer7/Plugins:/usr/local/RealPlayer7 - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealPlayer 7
On Thu, Mar 16, 2000 at 05:35:43PM -0500, Donn Miller wrote: Anyone get this beast to work on -current? The audio works, but the video doesn't work at all. I have COMPAT_LINUX in my kernel, and RealPlayer 5.0 works pretty well. I've had it working perfectly with the latest linux_base-6.1 and no LD_LIBRARY_PATH setting. Hasn't crashed once so far, which is rather unusual for products from RealNetworks! - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealPlayer 7
Mark Newton wrote: On Thu, Mar 16, 2000 at 05:35:43PM -0500, Donn Miller wrote: Anyone get this beast to work on -current? The audio works, but the video doesn't work at all. I have COMPAT_LINUX in my kernel, and RealPlayer 5.0 works pretty well. I've had it working perfectly with the latest linux_base-6.1 and no LD_LIBRARY_PATH setting. Hasn't crashed once so far, which is rather unusual for products from RealNetworks! Hmm. Do you get video, though? Also, which plugins did you install? - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealPlayer 7
On Thu, Mar 16, 2000 at 06:01:57PM -0500, Donn Miller wrote: I've had it working perfectly with the latest linux_base-6.1 and no LD_LIBRARY_PATH setting. Hasn't crashed once so far, which is rather unusual for products from RealNetworks! Hmm. Do you get video, though? Also, which plugins did you install? Yup, I get video; like I said, it's working perfectly. I just took it through the stock standard installation (click next - next - finish, with no other options). - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealPlayer 7
On Fri, 17 Mar 2000, Mark Newton wrote: On Thu, Mar 16, 2000 at 06:01:57PM -0500, Donn Miller wrote: Hmm. Do you get video, though? Also, which plugins did you install? Yup, I get video; like I said, it's working perfectly. I just took it through the stock standard installation (click next - next - finish, with no other options). Ok, fair enough. One last question, though -- are you running XFree86 4.0? Maybe it's something I'm lacking in my kernel config. I noticed that I didn't have options _KPOSIX_VERSION=199309L in there. I've got all the other posix functions, though. Are you using Linuxthreads? Or, maybe it's my ESS 1868 sound card. (I don't see how that is the problem, because sound works perfectly. But, you never know.) - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealPlayer 7
On Thu, Mar 16, 2000 at 06:29:58PM -0500, Donn Miller wrote: On Fri, 17 Mar 2000, Mark Newton wrote: On Thu, Mar 16, 2000 at 06:01:57PM -0500, Donn Miller wrote: Hmm. Do you get video, though? Also, which plugins did you install? Yup, I get video; like I said, it's working perfectly. I just took it through the stock standard installation (click next - next - finish, with no other options). Ok, fair enough. One last question, though -- are you running XFree86 4.0? Nope, not yet. I haven't upgraded X in quite a while; I'm running 3.3.3. Maybe it's something I'm lacking in my kernel config. I noticed that I didn't have options _KPOSIX_VERSION=199309L I do. I also have _KPOSIX_PRIORITY_SCHEDULING. in there. I've got all the other posix functions, though. Are you using Linuxthreads? Everyone is using Linuxthreads now; it's the default. - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealPlayer 7
On Thu, Mar 16, 2000 at 03:37:22PM -0800, Kris Kennaway wrote: On Fri, 17 Mar 2000, Mark Newton wrote: in there. I've got all the other posix functions, though. Are you using Linuxthreads? Everyone is using Linuxthreads now; it's the default. I didn't think so - it's still a port. We *support* linuxthreads out of the box, but don't install it. I think we're talking about different things. There's a linuxthreads port, yes, but that's something which provides FreeBSD's compile-time environment with libraries which duplicate the Linux threading APIs. There's also the capability for Linux executables to use threads under emulation. That's there "out of the box" by default. The linuxthreads port is only necessary if you want to use "The Linux Way" of doing threads in a piece of software you're building for FreeBSD; It doesn't make much difference to emulation. [ at least, I think that's how it works -- Marcel can ping me if I'm lying :-) ] - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: port/XFree86-4 make install fail.
i have the same problem, either building from ports or from scratch, so i make -k install'd it, and while X works, im missing some extensions so its a bit broken. anybody got a fix for this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Duplicate inodes, filesystem weirdness
I have recently "upgraded" to current (5.0) and am finding that with the new ATAPI/IDE driver I am getting filesystem inconsistencies regularly :( This manifests itself with fsck complaining profusely after a crash. The machine has hung _hard_ a couple of times, and upon reboot fsck complains generally about DUP/BAD inodes (lots of them) as well as bad hard link/directory entries.This is cause for concern - with the wd driver none of these problems existed. I have now mounted / and /usr sync to see whether that makes any difference ; my gut feel however is that the new driver may have some bugs that we still need to find. I have attached the output of dmesg (verbose boot) for anyone that is interested. I will try and get a kernel debug dump with any future crashes. Cheers Tim. -- Tim Liddelow * Firewalls / Security OneGuard Technical Lead**Electronic Commerce eSec Pty Ltd * Phone: +61 3 8341 2463 C++/UNIX/WIN32/OOP/OOD mailto:[EMAIL PROTECTED] * http://www.oneguard.com/ = Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #4: Thu Mar 16 11:26:53 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/FELINE Calibrating clock(s) ... TSC clock: 350808053 Hz, i8254 clock: 1193225 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: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 128M bytes Write Allocate 15-16M bytes: Enable real memory = 134152192 (131008K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00344000 - 0x07fe7fff, 130695168 bytes (31908 pages) avail memory = 126734336 (123764K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fb030 bios32: Entry = 0xfb4b0 (c00fb4b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xb4e0 pnpbios: Found PnP BIOS data at 0xc00fc110 pnpbios: Entry = f:c138 Rev = 1.0 Other BIOS signatures found: ACPI: 000f81e0 Preloaded elf kernel "kernel" at 0xc032b000. md0: Malloc disk Creating DISK md0 pci_open(1):mode 1 addr port (0x0cf8) is 0x80003840 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=05971106) npx0: math processor on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 768639508 bytes/sec bzero() bandwidth = 205549845 bytes/sec pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=05971106) pcib0: Host to PCI bridge on motherboard found- vendor=0x1106, dev=0x0597, revid=0x04 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base e000, size 26 found- vendor=0x1106, dev=0x8598, revid=0x00 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found- vendor=0x1106, dev=0x0586, revid=0x47 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x1106, dev=0x0571, revid=0x06 class=01-01-8a, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base e400, size 4 found- vendor=0x1106, dev=0x3040, revid=0x10 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x5333, dev=0x8901, revid=0x16 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base e400, size 26 found- vendor=0x10b8, dev=0x0005, revid=0x06 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base e800, size 8 map[14]: type 1, range 32, base ea00, size 12 found- vendor=0x1274, dev=0x5000, revid=0x00 class=04-01-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=5 map[10]: type 1, range 32, base ec00, size 6 pci0: PCI bus on pcib0 pcib1: VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge at
Re: port/XFree86-4 make install fail.
On Thu, 16 Mar 2000, Jean-Marc Zucconi wrote: Idea Receiver writes: "make all" success without any problem. There was an error but "make all" always complete. however, make install fail ;( What are your CFLAGS in /etc/make.conf ? default only. CFLAG= -O -pipe I have no problem of installing XFree-4.0 binary. Just not from ports/x11/XFree-4 :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealPlayer 7
Donn Miller wrote: Anyone get this beast to work on -current? The audio works, but the video doesn't work at all. I have COMPAT_LINUX in my kernel, and RealPlayer 5.0 works pretty well. I got disgusted with RP 5 because all of my favorite programs updated to G2 format, so I nuked it. Today I installed the latest linux-base port, downloaded the binary (non-rpm) version of linux RP 7 and it worked great. video and all. This is on an up-to-the-minute 5.0-Current. I tried the rpm version, but it complained about not finding "/etc/madb" or something like that. Since the binary install worked, I didn't pursue it. HTH, Doug -- "While the future's there for anyone to change, still you know it seems, it would be easier sometimes to change the past" - Jackson Browne, "Fountain of Sorrow" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealPlayer 7
Doug Barton wrote: I got disgusted with RP 5 because all of my favorite programs updated to G2 format, so I nuked it. Today I installed the latest linux-base port, downloaded the binary (non-rpm) version of linux RP 7 and it worked great. video and all. This is on an up-to-the-minute 5.0-Current. I think I found the problem -- it had "disable custom sampling rates" checked in the preferences section. I unchecked that, and at least the audio is working better. I still have to try the video, though... Maybe there's a conflict with running it with XFree86 4.0 and 16 bpp. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc -Os optimisation broken (RELENG_4)
Donn Miller wrote: Doug Barton wrote: Hmm... If I have a PII (Actually celeron 300A) or a PIII, which is better, 'pentium' or 'pentiumpro'? I would think the latter, but I've learned not to assume where gcc is concerned. I think that 'pentium' would result in code that isn't as optimized as 'pentiumpro', but I've heard that 'pentium' has a lot less problems. Also, I have heard conflicting reports as to whether compiling the kernel/world with optimisations is a good thing. Anyone care to (re)open that can of worms? I compile my kernel/world with -mpentium -O3 -pipe. The only problem I've seen so far were spurious random reboots that would occur about 2-3 times a month. But, that was last summer, and hasn't happened since. Something else must have been the culprit. (Maybe -current wasn't as stable last summer.) With the aforementioned CFLAGS, I have a pretty reliable and stable system. I've heard that -mpentiumpro can be pretty buggy, and it can actually result in slower code than -mpentium for certain pentium types. I trust plain -mpentium, as it has been very reliable for me, except for some compile-time errors caused by the optimization (Qt). In the interests of providing another datapoint, I tried my old, boring P5 machine, and with -Os -march=pentium buildworld bombed trying to compile cc1plus in the build tools phase. Backing off to -O worked. The kernel was ok with -Os -march=pentium. Hope someone is finding this useful, Doug -- "While the future's there for anyone to change, still you know it seems, it would be easier sometimes to change the past" - Jackson Browne, "Fountain of Sorrow" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [sound] PCI ESS support
Darryl Okahata [EMAIL PROTECTED] writes: Well, I was going to take Ville-Pertti Keinonen's ([EMAIL PROTECTED]) ESS2 mixer code and turn it into an LKM, which I'd then try to add sound output using the Linux code. However, I'm not familiar with how one accesses interrupts and DMA under FreeBSD, and so it would take me a while. If anyone else would like to do it, that's fine with me. Another (perhaps simpler) alternative might be to try to get it to work in SB emulation mode. I've managed to get it to probe as a SoundBlaster (just by adding pci_write_config(dev, 0x41, 0x10, 1) to the probe code in my mixer driver): sbc0: Soundblaster Pro at port 0x220-0x22f irq 5 drq 1 on isa0 However, it doesn't work (the interfaces seem to work, but the mixer settings don't affect anything and playback doesn't get anywhere) and I still haven't had time to look at it properly (and don't expect to any time soon). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [sound] PCI ESS support
Ville-Pertti Keinonen wrote: Darryl Okahata [EMAIL PROTECTED] writes: Well, I was going to take Ville-Pertti Keinonen's ([EMAIL PROTECTED]) ESS2 mixer code and turn it into an LKM, which I'd then try to add sound output using the Linux code. However, I'm not familiar with how one accesses interrupts and DMA under FreeBSD, and so it would take me a while. If anyone else would like to do it, that's fine with me. Another (perhaps simpler) alternative might be to try to get it to work in SB emulation mode. I've managed to get it to probe as a SoundBlaster (just by adding pci_write_config(dev, 0x41, 0x10, 1) to the probe code in my mixer driver): That was going to be my first try :-) sbc0: Soundblaster Pro at port 0x220-0x22f irq 5 drq 1 on isa0 However, it doesn't work (the interfaces seem to work, but the mixer settings don't affect anything and playback doesn't get anywhere) and I still haven't had time to look at it properly (and don't expect to any time soon). -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [sound] PCI ESS support
From: Ville-Pertti Keinonen [EMAIL PROTECTED] Date: 17 Mar 2000 08:24:51 +0200 ::Another (perhaps simpler) alternative might be to try to get it to ::work in SB emulation mode. :: ::I've managed to get it to probe as a SoundBlaster (just by adding ::pci_write_config(dev, 0x41, 0x10, 1) to the probe code in my mixer ::driver): :: ::sbc0: Soundblaster Pro at port 0x220-0x22f irq 5 drq 1 on isa0 :: ::However, it doesn't work (the interfaces seem to work, but the mixer ::settings don't affect anything and playback doesn't get anywhere) and ::I still haven't had time to look at it properly (and don't expect to ::any time soon). Well, it's not that simple. When I tried to write driver for it last year, I found that: 1) You also need to setup ASSP (Application Specific Signal Processor) in the chip and GPIO properly. Source code for BTM2E.EXE should be a help here. (I didn't have that source, when I was tryng to write the driver.) 2) For DMA to work, you need to support DDMA in FreeBSD. I have small patch for 3-stable, but will not work with -current due to newbus changes. 3) When Maestro2E acts as Soundblaster Pro emulation, DSP_CMD_GETVER returns 0x302 (or may be it was 0x303?), that are not supported in newpcm and luigi's pcm drivers. May be the current support for ver=0x301 work? I have no clue here. If I get the time, I could try to write from scratch, again. Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Office of Business Planning Development, Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103, Japan Tel: +81-3-3245-3318 Fax: +81-3-32454-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealPlayer 7
Around Today, "Donn Miller" wrote : DM I got disgusted with RP 5 because all of my favorite programs updated DM to G2 format, so I nuked it. Today I installed the latest linux-base DM port, downloaded the binary (non-rpm) version of linux RP 7 and it DM worked great. video and all. This is on an up-to-the-minute 5.0-Current. DM DM I think I found the problem -- it had "disable custom sampling rates" DM checked in the preferences section. I unchecked that, and at least I had it checked, and it wasn't an issue (on my SB Vibra 16). Oh well. The only issue is that the RealAudio plugin doesn't work with Netscape :-( Khetan Gajjar. --- [EMAIL PROTECTED] * [EMAIL PROTECTED]* PGP Key, contact UUNET South Africa * FreeBSD enthusiast * details and other http://www.uunet.co.za * http://www.freebsd.org * information at System Administration * http://office.os.org.za * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc -Os optimisation broken (RELENG_4)
On Thu, 16 Mar 2000, Jeffrey J. Mountin wrote: Wondering why one would use -mcpu and not -march. If the code runs only on Celerons, PII's, and PIII's why would one *not* use -march. I'm curious about (possible) breakages with -mcpu or -march compared to -Ox settings which seem to break things more often than -O. Only ask, since -Ox and individual flags (rather than the mulititude added going from -O to -O2) are used far more often. Eager to fire my new-found gun in the direction of my feet I built world and kernel last night with -0s -march=pentium. So far so good (although I haven't given it a real workout yet). Now that I now 'pentiumpro' should be a better choice, I'll give that a whirl tonight. After reading the man page I had to agree with your point that -march seemed like a better option, and I don't have cross-platform issues to deal with here. Doug -- "While the future's there for anyone to change, still you know it seems, it would be easier sometimes to change the past" - Jackson Browne, "Fountain of Sorrow" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible simple install-info fix
On Thu, Mar 16, 2000 at 09:57:22AM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: I was looking into fixing the install-info problem, and wondered if the solution is really as easy as it seems: Hmmm I had been thinking all along that the problem with install-info was that the system couldn't use the new binary. Are you saying here that installworld is trying to use the old version of install-info that is installed in the system? Please say it isn't so... Yes, it is using the old binary. There were plans (Marcel?) to commit an installation tools support into src/Makefile.inc1, but it was postponed until 4.0-RELEASE is done. This is now happened, and I expect Marcel committing his staff soon. All that needs to be done is build install-info by the bootstrap-tools stage. It will then be used throughout the build and install stages (after applying the patch :-). This of course assumes that the new install-info is backward compatible with the previous version. It is (install-info) already there (in bootstrap-tools), and just awaiting your patch to be committed :-) Then we could remove that `make -DNOFINO installworld, make installworld' bogosity from src/UPDATING. The bootstrap-tools stage is designed to solve incompatibilities caused by versions of tools installed on the system and the requirements (for newer ones) by the source-tree. If install-info is needed to do installworld, shouldn't it be considered a build tool, with all of the build platform/install platform gymnastics that implies? install-info is already built as part of build-tools stage, but there are two problems. This is a bug. If install-info is installed, then it isn't a build tool. Build tools are programs/scripts that are needed to build the sources only. They are not installed. Since install-info is installed, it can't be a build tool. this means that we either use the installed version or use a freshly built version made during the bootstrap stage. Silly me, I meant bootstrap-tools. There are so many *-tools stages, that one is easy to get lost :-) First, it is not currently used at the installworld stage, which Marcel's patch fixes. Correct. Installworld is using installed binaries (even though newer ones have been made by the bootstrap stage) *and* it is using binaries it has installed already and which may not even be runnable by the current kernel. Second, less important (IMHO), is a cross building issue. Consider the case, when you want to build 4.0 alpha world on 3.x i386 system, and then install it (world) on alpha running 3.x. It was discussed about month ago on -current... I don't consider this less important. Having the ability to do cross builds helps maintaining FreeBSD on multiple platforms and also helps in porting to new platforms. Umm, I was unclean. It seems to be of less priority. -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: port/XFree86-4 make install fail.
Idea Receiver writes: "make all" success without any problem. There was an error but "make all" always complete. however, make install fail ;( What are your CFLAGS in /etc/make.conf ? Jean-Marc -- Jean-Marc ZucconiPGP Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible simple install-info fix
Ruslan Ermilov wrote: This is a bug. If install-info is installed, then it isn't a build tool. Build tools are programs/scripts that are needed to build the sources only. They are not installed. Since install-info is installed, it can't be a build tool. this means that we either use the installed version or use a freshly built version made during the bootstrap stage. Silly me, I meant bootstrap-tools. There are so many *-tools stages, that one is easy to get lost :-) Yeah. I thought about adding another one just for the unadultery heck of it, but changed my mind :-) Second, less important (IMHO), is a cross building issue. Consider the case, when you want to build 4.0 alpha world on 3.x i386 system, and then install it (world) on alpha running 3.x. It was discussed about month ago on -current... I don't consider this less important. Having the ability to do cross builds helps maintaining FreeBSD on multiple platforms and also helps in porting to new platforms. Umm, I was unclean. It seems to be of less priority. Ah, ok. I misunderstood what you ment here. To be a bit more concrete (rather than being chatty): I hope to find the time soon to update the patch to match the current source tree (this requires some testing time/resources) after which we can all review it again before I commit it. To speed things up, you are of course welcome to be pro-active (damn, my work environment already gets to me :-) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
