Re: -e option to umount?
On Mon, 19 Jun 2000 01:28:27 MDT, "Kenneth D. Merry" wrote:
In any case, if an error were returned, the only way you could get that
to work would be to have the media daemon continually ping the drive with
the mounted media, and then unmount it in response to the (likely) unit
attention condition.
This is how the MacOS does it, at least prior to MacOS X. If the CD-ROM
is external and powered-down after the MacOS boots, the Mac then hangs
periodically trying to ping it. Really screws up performance. :)
-- Parag Patel
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
4.0 kernel size quite a bit larger than 3.4?
Has anyone else noticed their 4.0 kernel is quite a bit larger than 3.4? I've been building 4.0 kernels before I try to upgrade pinhead from 3-CURRENT to 4. I started with GENERIC in both cases and simply turned off all the features/drivers I don't need and added the ones I do. (/kernel is 3.4): $ ll /kernel kernel; size /kernel kernel -rwxr-xr-x 1 root wheel 1877424 Feb 7 14:15 /kernel -rwxr-xr-x 1 parag bin2331259 Mar 19 11:28 kernel textdata bss dec hex filename 1451231 109080 158188 1718499 1a38e3 /kernel 1721108 234908 120376 2076392 1faee8 kernel ~280Kb of .text seems a bit excessive. I completely stripped both images and compared them but the size difference is still the same. (Both config files are attached below.) It's hard to diff the config files as so much stuff has changed and rearranged between the 3.4 and 4.0. A manual exam/compare of both didn't point out anything obvious to me but perhaps I've simply missed something big. I prefer to build everything into the kernel rather than use KLDs just to be sure I haven't forgotten to update the latter. (I searched the mail archives but didn't find anything obvious.) Thanks! -- Parag Patel # # PINHEAD config file developed from: # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.freebsd.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246 2000/03/09 16:32:55 jlemon Exp $ machine i386 #cpuI386_CPU #cpuI486_CPU cpu I586_CPU cpu I686_CPU ident PINHEAD maxusers32 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols #optionsMATH_EMULATE#Support for x87 emulation options INET#InterNETworking #optionsINET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options MFS #Memory Filesystem #optionsMD_ROOT #MD is a potential root device options NFS #Network Filesystem #optionsNFS_ROOT#NFS usable as root device, NFS required #optionsMSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem #optionsCD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=3000 #Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console #optionsUSERCONFIG #boot -c editor #optionsVISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING #optionsICMP_BANDLIM#Rate limit bad replies options DDB options INVARIANTS options INVARIANT_SUPPORT options MD5 options COMPAT_LINUX #optionsVESA options IDE_DELAY=3000 options NETATALK#Appletalk communications protocols options SOFTUPDATES #Copyrighted FFS changes # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #optionsNCPU=2 # number of CPUs #optionsNBUS=4 # number of busses #optionsNAPIC=1 # number of IO APICs #optionsNINTR=24# number of INTs device isa #device eisa device pci # Floppy drives device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 #device fd1 at fdc0 drive 1 # ATA
Re: 4.0 kernel size quite a bit larger than 3.4?
To follow-up to my own note, I found some ISA devices that I failed to turn off under 4.0. Now the sizes are closer, but still around 180Kb .text larger, ~270Kb overall: $ ll /kernel kernel -rwxr-xr-x 1 root wheel 1877424 Feb 7 14:15 /kernel # (3.4) -rwxr-xr-x 1 parag bin2230379 Mar 19 12:47 kernel $ size /kernel kernel textdata bss dec hex filename 1451231 109080 158188 1718499 1a38e3 /kernel # (3.4) 1634903 231484 120264 1986651 1e505b kernel So I created a merged list of object file sizes (appended below). It looks like a case of being nibbled to death by cats. (Julian Elischer suggested it may be due to the newbus code which affects just about everything.) No obvious place that has eaten a bunch of space - it's pretty well scattered throughout. -- Parag Patel textdata bss dec hex filename 1298 4 01302 516 93cx6.o 1298 4 01302 516 93cx6.o (3.4) 3652 20273664081908 aarp.o 3064 202736582016bc aarp.o (3.4) 2509 388 02897 b51 ac97.o 3522 520 44046 fce ad1816.o 134951164 0 146593943 ad1848.o (3.4) 99151356 8 112792c0f ahc_pci.o 82601056 493202468 ahc_pci.o (3.4) 406424372 10 45024afe0 aic7xxx.o 410054192 10 45207b097 aic7xxx.o (3.4) 4491 0 844991193 aicasm.o 4491 0 844991193 aicasm.o (3.4) 19354 0 60 194144bd6 aicasm_gram.o 19354 0 60 194144bd6 aicasm_gram.o (3.4) 11393 24 20 114372cad aicasm_scan.o 11393 24 20 114372cad aicasm_scan.o (3.4) 2234 0 42238 8be aicasm_symbol.o 2234 0 42238 8be aicasm_symbol.o (3.4) 483 8 258 749 2ed arc4random.o 3092 0 03092 c14 at_control.o 3112 0 03112 c28 at_control.o (3.4) 16 116 0 132 84 at_proto.o 16 100 0 116 74 at_proto.o (3.4) 11856 620 272 1274831cc ata-all.o 5111 200 1125423152f ata-disk.o 9276 0 09276243c ata-dma.o 6434 84 1665341986 atapi-all.o 14699 148 0 1484739ff atapi-cd.o 11238 108 64 114102c92 atapi-cd.o (3.4) 6991 0173687272217 atapi.o (3.4) 578160205892 17693451d atkbd.o 572660165888 1763044de atkbd.o (3.4) 374 108 0 482 1e2 atkbd_isa.o 139 16 4 159 9f atkbd_isa.o (3.4) 4308 8 964412113c atkbdc.o 4284 8 9643881124 atkbdc.o (3.4) 1033 280 01313 521 atkbdc_isa.o 105 16 0 121 79 atkbdc_isa.o (3.4) 220 0 0 220 dc atomic.o 220 0 0 220 dc atomic.o (3.4) 925 96 01021 3fd autoconf.o 1687 156 01843 733 autoconf.o (3.4) 291 0 0 291 123 bcd.o 291 0 0 291 123 bcd.o (3.4) 2461 44 02505 9c9 bios.o 1350 52 01402 57a bios.o (3.4) 219 8 0 227 e3 bioscall.o 47 0 0 47 2f bioscall.o (3.4) 4083 248 20435110ff bpf.o 3978 1361244535814ee bpf.o (3.4) 2393 0 02393 959 bpf_filter.o 2393 0 02393 959 bpf_filter.o (3.4) 1196 256 01452 5ac bus_if.o 660 72 0 732 2dc bus_if.o (3.4) 3024 4 803108 c24 busdma_machdep.o 2906 4 802990 bae busdma_machdep.o (3.4) 318 0 0 318 13e cam.o 318 0 0 318 13e cam.o (3.4) 375 0 0 375 177 cam_extend.o 375 0 0 375 177 cam_extend.o (3.4) 6288 0 062881890 cam_periph.o 6075 0 0607517bb cam_periph.o (3.4) 1438 0 01438 59e cam_queue.o 1438 0 01438 59e cam_queue.o (3.4) 234 0 0 234 ea cam_sim.o 234 0 0 234 ea cam_sim.o (3.4) 23494 968 72 245345fd6 cam_xpt.o 22815 992 76 238835d4b cam_xpt.o (3.4) 154 0 0 154 9a cd9660_bmap.o 154 0 0 154 9a cd9660_bmap.o (3.4) 2319 0 02319 90f cd9660_lookup.o 2319 0 02319 90f cd9660_lookup.o (3.4) 1779 0 121791 6ff cd9660_node.o 1763 0 121775 6ef cd9660_node.o (3.4) 3108 384 03492 da4 cd9660_rrip.o 3096
Re: FWIW: More questionable softupdates+vinum benchmarks
On Fri, 18 Feb 2000 08:50:06 +1030, Greg Lehey wrote: Could you change the values of VINUM_MAXACTIVE and DRIVE_MAXACTIVE (in /sys/dev/vinum/vinumvar.h) to 3 each (effectively disabling the throttling), recompile the kld and try again please? It didn't make any significant difference: find /usr/src | cpio -pdum /target (~600k blocks): /noraid (1 drive, softupdates): 901.70s real 6.32s user 135.73s system 944.64s real 6.40s user 135.49s system (*MAXACTIVE to 3) buildworld -j16: src obj on /noraid volume (1 drive, softupdates) 6053.86 real 7969.94 user 7601.81 sys 6040.56 real 7933.80 user 7643.17 sys (*MAXACTIVE to 3) (The /*raid* volumes are all on the 5 older SCSI disks, but the rest of the system is on a newer IDE disk, which is why the IDE times are better.) -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FWIW: More questionable softupdates+vinum benchmarks
Hello. I have a friend's quad PPro box temporarily sitting in my garage that I've been using to play with 4.0-CURRENT and vinum. Since the last series of bug-fixes a few weeks ago, everything works as advertised. Just for my own curiosity, I've been running some simple (probably questionable) tests involving find|cpio of the source tree and then buildworld -j16 on various vinum volumes. So I thought I'd forward the results to current, for what it's worth. The biggest (non)surprise is how big a difference softupdates makes. Nice! -- Parag Patel "Idiocy: Never underestimate the power of stupid people in large groups" -- Despair.COM # 4xPPro (256k on-chip cache) 200MHz SMP, 512Mb RAM, 5 x 2Gb (older) SCSI disks # volumes / /var /usr are on a newer IDE drive (BIOS doesn't grok SCSI) # softupdates are on for all volumes here, except for / # /tmp is on a 32Mb MFS filesystem and is mounted async # /etc/make.conf defaults to running gcc -O -pipe # vinum.conf drive d0 device /dev/da0s1e drive d1 device /dev/da1s1e drive d2 device /dev/da2s1e drive d3 device /dev/da3s1e drive d4 device /dev/da4s1e volume raid5 setupstate plex org raid5 256k sd length 768m drive d0 sd length 768m drive d1 sd length 768m drive d2 sd length 768m drive d3 sd length 768m drive d4 volume raid10 setupstate plex org striped 256k sd length 0 drive d0 sd length 0 drive d1 plex org striped 256k sd length 0 drive d2 sd length 0 drive d3 volume noraid setupstate plex org concat sd length 0 drive d4 find /usr/src | cpio -pdum /target (~600k blocks): /raid5 (5 drives, 256k, softupdates): 949.21s real 6.28s user 142.21s system /raid5 (5 drives, 256k): 2500.62s real 6.16s user 165.65s system /raid10 (4 drives, 256k stripe, softupdates): 786.46s real 5.86s user 141.50s system /raid10 (4 drives, 256k stripe): 1553.88s real 6.37s user 150.64s system /noraid (1 drive, softupdates): 901.70s real 6.32s user 135.73s system /noraid (1 drive): 1614.45s real 6.09s user 142.46s system build kernel -j16: IDE disk (softupdates) 152.97s real 430.57s user99.85s system /raid5 volume (5 drives, 256k, softupdates) 162.40s real 434.40s user99.75s system /raid5 (5 drives, 256k): 159.79s real 432.53s user99.35s system /raid10 (4 drives, 256k stripe, softupdates): 141.81s real 428.63s user 101.05s system /raid10 (4 drives, 256k stripe): 143.49s real 433.42s user99.80s system /noraid (1 drive, softupdates): 145.35s real 431.35s user96.50s system /noraid (1 drive): 148.13s real 433.23s user95.01s system buildworld -j16: src obj on IDE disk (softupdates) 5676.29 real 7701.09 user 6133.60 sys src obj on /raid5 volume (5 drives, 256k, softupdates) 6066.43 real 7929.20 user 7659.18 sys src obj on /raid5 volume (5 drives, 256k) 7098.73 real 7979.00 user 7843.46 sys src obj on /raid10 volume (4 drives, 256k stripe, softupdates) 5932.15 real 7918.44 user 7645.84 sys src obj on /raid10 volume (4 drives, 256k stripe) 6479.33 real 7964.00 user 7565.06 sys src obj on /noraid volume (1 drive, softupdates) 6053.86 real 7969.94 user 7601.81 sys src obj on /noraid volume (1 drive) 6607.68 real 7965.14 user 7377.00 sys To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FWIW: More questionable softupdates+vinum benchmarks
On Thu, 17 Feb 2000 21:14:20 +0100, Brad Knowles wrote: While we're on this subject, I recently did some benchmarking with just a single disk on a machine running 3.4-STABLE, both with and without softupdates. I haven't yet gotten a chance to test it with vinum and softupdates, but what I got did a pretty good job of impressing me. I'm impressed by both vinum and softupdates. If I didn't need to run cables from my computer-room through the kitchen and to the garage, I'd be tempted to hang on to my friend's machine (he intends to sell it). Oh well. At some point I may create my own poor-man's desktop RAID cluster with several PCI-IDE controllers and a cheap IDE master per interface (no slaves). Not quite as good as SCSI but a heck of a lot cheaper. -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Megahertz pccard
On Tue, 08 Feb 2000 14:22:25 EST, Gerald Abshez wrote:
There is only the ethernet card plugged in. After the boot probe
completes, I get:
ep0: No irq?!
I also have one of these cards, and it's working fine under 4.0-CURRENT.
Seems like the default IRQs used by pccard are being used by something
else on your laptop. The default line in /etc/pccard.conf.sample is
irq 3 5 10 11 13 15
I needed to add "-i13 -i15" to my /etc/rc.conf's pccard_flags entry as
all other IRQs on my laptop were in use. I could have also edited the
pccard.conf file.
If there's some point at bootup where you can add these flags to
pccardd or edit its default pccard.conf.sample file, it's worth a shot.
I installed 3.4-STABLE from 3.4's floppies and CDs onto my laptop,
hacked /etc/pccard.conf to create an entry for my Megahertz, then
updated it to 4.0-CURRENT via NFS. I never tried the 4.0 boot floppies
since I needed to run "make installworld" from a build on another box.
-- Parag Patel
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-CURRENT SMP crash with vinum raid-5 and softupdates
Just to let everyone know, Greg's going to be out-of-town for a little while and won't be able to continue debugging. I'm taking a crack at it again. So far, it seems to be a combination of softupdates+vinum+raid5 that triggers the bug, whatever it is. If I turn off softupdates the raid5 volume seems happy, with and without async. It seems likely to be some odd interaction between the raid5 code and softupdates, since the simpler mirror/striping seems to work fine with it. Ring any bells for anyone? -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha kernel build failure (w/patch)
On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: +#ifdef __i386__ sc-wb_btag = I386_BUS_SPACE_IO; +#endif +#ifdef __alpha__ + sc-wb_btag = ALPHA_BUS_SPACE_IO; +#endif Just curious, but is there a reason that these lines aren't simply sc-wb_btag = BUS_SPACE_IO; with this macro being set to the correct machine-specific one in some appropriate header file? I'm sure I'm missing something... Thanks! -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stable snap for smp?
On Fri, 14 May 1999 19:34:43 CDT, Anthony Kimball wrote: If anyone has applied reasonable stress to a recent MP kernel, preferrably with X, VESA, VM86, and found it stable, do please report on your last cvs update time: I, for one, would very much like to isolate a fairly stable post-newbus world. Presumably this would be helpful to other readers as well, it being so much easier to bounce between worlds which are more nearly contemporaneous. I've been running 3.1-STABLE cvsup-ed on Sat May 8 at about 3:30am or thereabouts. It always starts up xdm, and my desktop is KDE, I use exmh and Netscape daily, used doscmd a couple of days ago to burn some EPROMs, used gimp and sane to scan and edit some photos, just completed a buildworld with -j4 of 3.2-STABLE, and always run setiathome (new version 1.1 just released). The system is a dual PII/300, 256Mb RAM, and 256Mb swap across two UW-SCSI disks. The only IDE peripheral is a CD-ROM, and it's still using the old acd/ATAPI driver. Soundblaster AWE64 card works just fine with Luigi's drivers. The only thing I don't have in the kernel is VESA as the machine always fires up xdm. I have the DDB code in as well INVARIANTS turned on. Nothing is dynamically loaded - I always build a custom kernel with everything I need in it to ease debugging and to be sure no module is out-of-date. (I used to be running 4.0-CURRENT but hit the already-mentioned strange lockup with no debug, no dump, and no clue. I had to get some pay-for work done so I backed up to 3.1-STABLE and it seems to be fine since.) Hope this helps. I intend to update to 3.2-STABLE today... -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
Does gcc has a Pascal? :-) Actually, yes. It's not a part of it yet, but drops in and builds easily with gcc-2.8.1, and with very little extra work for egcs. Check out http://agnes.dida.physik.uni-essen.de/~gnu-pascal/. Unlike Modula-3 and Gnat, they wrote the front-end in C, so it's a whole lot easier to port. It drops into a p subdir much like the Fortran front-end and includes a bunch of tests. It's a pretty nice dialect too - mostly compatible with Borland's Pascal with object extensions. I personally don't need Fortran or Objective-C, but could use C, C++, gjc (the new Java compiler), and gpc. I'm used to building my own compilers and cross-compilers, so it's no big deal for me either way. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Lots of warnings in 4.0-CURRENT kernel build
I just built a new 4.0-CURRENT kernel yesterday and noticed that there seem to be more warnings generated than used to be. I rebuilt it today with the latest sources as of 3am March 6, built a new kernel from scratch (after deleting the entire old build dir), removed the cc lines, and got this set of warnings that I've appended to the end of this note. (The kernel does link successfully, and at least last night's kernel is running fine, so this isn't a really critical problem.) I do understand that some of the code is still being worked on, but I thought files such as if_fxp.c and ncr.c are relatively stable now. I'm curious if most people are building kernels without the default warnings or are just ignoring them? I'd be happy to go over all the files and get everything to compile without warnings, but as others have already discovered, the warnings may be indicating real bugs that need fixing. Perhaps the owners could take a closer look? Maybe there should be a daily kernel warnings posting to the mailing list to prompt the owners to fix the code? :-) Or a daily send-pr containing the latest kernel warnings generated? :-) Or am I just pointing out what everyone but me already knows is being worked on? -- Parag Patel kern/init_sysent.c:23: warning: cast discards `volatile' from pointer target type kern/kern_sysctl.c: In function `sysctl_register_set': kern/kern_sysctl.c:127: warning: cast discards `const' from pointer target type kern/kern_sysctl.c: In function `sysctl_unregister_set': kern/kern_sysctl.c:135: warning: cast discards `const' from pointer target type kern/sys_generic.c: In function `write': kern/sys_generic.c:251: warning: assignment discards `const' from pointer target type pci/if_fxp.c: In function `fxp_init': pci/if_fxp.c:1294: warning: passing arg 2 of `bcopy' discards `volatile' from pointer target type pci/if_fxp.c:1351: warning: passing arg 2 of `bcopy' discards `volatile' from pointer target type pci/if_fxp.c: In function `fxp_mc_setup': pci/if_fxp.c:1867: warning: passing arg 2 of `bcopy' discards `volatile' from pointer target type pci/ncr.c: In function `ncr_log_hard_error': pci/ncr.c:5333: warning: cast discards `volatile' from pointer target type pci/ncr.c: In function `ncr_exception': pci/ncr.c:5470: warning: cast discards `volatile' from pointer target type pci/ncr.c: In function `ncr_int_ma': pci/ncr.c:5773: warning: cast discards `volatile' from pointer target type pci/ncr.c:5777: warning: cast discards `volatile' from pointer target type pci/ncr.c:5801: warning: cast discards `volatile' from pointer target type pci/ncr.c:5808: warning: cast discards `volatile' from pointer target type pci/ncr.c:5816: warning: cast discards `volatile' from pointer target type pci/ncr.c:5821: warning: cast discards `volatile' from pointer target type pci/ncr.c:5831: warning: cast discards `volatile' from pointer target type pci/ncr.c:5835: warning: cast discards `volatile' from pointer target type pci/ncr.c: In function `ncr_regtest': pci/ncr.c:6803: warning: cast discards `volatile' from pointer target type pci/ncr.c:6804: warning: cast discards `volatile' from pointer target type In file included from dev/kbd/atkbd.c:336: dev/kbd/kbdtables.h:1151: warning: missing braces around initializer for `key_map.key[0]' i386/isa/ipl_funcs.c: In function `setdelayed': i386/isa/ipl_funcs.c:136: warning: cast discards `volatile' from pointer target type i386/isa/joy.c: In function `joyread': i386/isa/joy.c:169: warning: suggest parentheses around comparison in operand of i386/isa/sio.c: In function `comhardclose': i386/isa/sio.c:1338: warning: suggest parentheses around within || i386/isa/sio.c: In function `comparam': i386/isa/sio.c:2000: warning: suggest parentheses around within || i386/isa/snd/ad1848.c: In function `cs423x_attach': i386/isa/snd/ad1848.c:1587: warning: assignment from incompatible pointer type i386/isa/snd/ad1848.c: In function `opti931_attach': i386/isa/snd/ad1848.c:1690: warning: assignment from incompatible pointer type i386/isa/snd/ad1848.c: In function `opti925_attach': i386/isa/snd/ad1848.c:1755: warning: assignment from incompatible pointer type i386/isa/snd/ad1848.c: In function `guspnp_attach': i386/isa/snd/ad1848.c:1818: warning: assignment from incompatible pointer type i386/isa/snd/ad1848.c: In function `ad1816_intr': i386/isa/snd/ad1848.c:2039: warning: suggest parentheses around comparison in operand of i386/isa/snd/sbcard.h:358: warning: `sb16_recmasks_L' defined but not used i386/isa/snd/sbcard.h:376: warning: `sb16_recmasks_R' defined but not used libkern/index.c: In function `index': libkern/index.c:48: warning: cast discards `const' from pointer target type libkern/rindex.c: In function `rindex': libkern/rindex.c:52: warning: cast discards `const' from pointer target type pci/es1370.c:150: warning: initialization from incompatible pointer type i386/isa/snd/ulaw.h:40: warning: `dsp_ulaw
Re: adding DHCP client to src/contrib/
Just wanted to mention something that I haven't seen mentioned here in all the flaming and whatnot. OpenBSD ships out-of-the-box with dhcp client support available as an install option. This turned out to be very nice when I was installing it on one of my friend's Sparcs. His network is on a DSL link and has to run with DHCP - he has no static IPs available at all. OpenBSD installed and runs just fine with his network. We also tried to get Solaris7 going on one of his other Sparcs but it was a royal pain to figure out how to turn on dhcp for it. It didn't switch it on during the install nor give any hints as to how do do so. All in all, OpenBSD made a far more favorable impression on my friend than Solaris. So from a practical point-of-view, I think adding dhcp client support to FreeBSD is a good thing. Also, the argument about which dhcp server/client is better than the other, if I may suggest looking at and perhaps importing the OpenBSD code? The CHANGES file lists a bunch of security and bug fixes. I can't tell where the code is derived from. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Which DHCP client
May I suggest looking at the OpenBSD dhcp client/server? I'm not sure which one they're derived from, but the CHANGES file lists a bunch of bug and security fixes. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
My opinion is that since we have /etc/rc and /etc/rc.local, we might as well use /etc/rc.conf and /etc/rc.conf.local the same way -- that is, just as /etc/rc should not be touched by anyone, neither should /etc/rc.conf be touched by anyone. Matthew Dillon Then why bother having rc.conf in the first place? Just wire in all the defaults straight into /etc/rc and leave rc.conf strictly for overriding the defaults only, and eliminate rc.conf.* entirely. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Because rc.conf contains configuration variables, whereas rc contains commands to execute at boot time. Then I would suggest renaming rc.conf to be rc.vars or rc.config-vars or something more appropriate than rc.conf, which like all the other *.conf files is intended for local editing and maintainence. I do like the local overriding feature though. Yesterday I took out all my local rc.conf mods into rc.conf.local and copied in the default /usr/src/etc/rc.conf to /etc. The local mods are much smaller and much more obvious as to what is different from the default setup. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: msdosfs/vn trouble, doscmd nicety, fd trouble
Doscmd is really only useable with X, and running doscmd -bx with a local X server generates tons of trap 25 with interrupts disabled. I don't recall this being the case many moons ago... Yeah, me too. I was told this is a bug in doscmd and the owner needs to fix it. I don't understand the inner parts of DOS VM86 as it relates to the x86 architecture or I'd take a crack at it. Instead, I hacked as follows to silence this specific error. This is not a good thing to do in general, but it lets me use doscmd to program EPROMs. I just use cvs instead of cvsup to update my working source tree so I don't lose this (and other) local mods. Don't know about the panic though - I haven't seen anything like it. I've never used vn to access the floppy under DOS. Instead I just point it to a 1.44Mb floppy image on the filesystem and a 10Mb hard-drive image on the filesystem, and it works fine for me. -- Parag Patel === # my ~/.doscmdrc assign A: /u/parag/dos/1.44M 1440 assign B: /dev/rfd0 1440 assign C: /u/parag/dos/10M 306 4 17 assign D: /cgt/src/bin/of/ppc assign E: /u/parag/tmp #assign lpt1: direct /dev/lpt0 # map in the parallel port for the EMP-10 portmap 0x378 8 boot c: === Index: trap.c === RCS file: /src/freebsd/src/sys/i386/i386/trap.c,v retrieving revision 1.133 diff -c -r1.133 trap.c *** trap.c 1999/01/06 23:05:36 1.133 --- trap.c 1999/01/16 18:32:46 *** *** 234,240 printf( pid %ld (%s): trap %d with interrupts disabled\n, (long)curproc-p_pid, curproc-p_comm, type); ! else if (type != T_BPTFLT type != T_TRCTRAP) /* * XXX not quite right, since this may be for a * multiple fault in user mode. --- 234,240 printf( pid %ld (%s): trap %d with interrupts disabled\n, (long)curproc-p_pid, curproc-p_comm, type); ! else if (type != T_BPTFLT type != T_TRCTRAP type != T_TSSFLT) /* * XXX not quite right, since this may be for a * multiple fault in user mode. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4.0-Current, netscape halts system
Just another data point. I just updated my 2xPII/300 system to 4.0-CURRENT last night (Tues Jan 26), and I'm running Netscape 4.5 just fine - no crashes od any odd behavior at all. VM_STACK is defined, I have 256Mb RAM, and 256Mb swap (which is currently untouched since the reboot) striped across 2 disks. A make -j8 buildworld also succeeded early this morning at about 5am. Softupdates is turned on for all disks and all partitions except /tmp which is async mfs. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
