Re: Are the ethernet drivers time dependent?
Well serial ports come free on all new computers ;) You mean like the PC 2000 that _only_ comes with USB and for which you will have to buy a USB-serial converter that might not handle the signalling you had in mind? :-) Nick http://www.etla.net/~n_hibma/usb/usb.pl -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Propose mdoc fix regarding ERRORS section
Category: docs Synopsis: src/lib/libc/sys/*.2 misc patch pack - first column in most ERROR lists is too narrow. Normalize their width. Right now we have a problem with our on-line man pages. Most were written when the length of errno's were only 6 - 8 characters long. Now we have errno's that can be up to 15 characters long. Many of our man pages have the following mdoc instruction (or something similar) to ensure that the field width for the errno is appropriate: .Bl -tag -width EBADFXXX As things have progressed, sometimes the errno names have become wider than the name specified in the .Bl macro. Man pages can also specify: .Bl -tag -width Er Which will reserve enough space for the errno name based on what width the Er macro specifies. Right now it doesn't allocate enough width to contain our largest errno's. I propose that we fix mdoc to allocate enough width when the second form is specified, and then change all of the man pages to use that format in the ERRORS section. Suggestions/comments/etc welcome. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Cheap link (was: Are the ethernet drivers time dependent?)
On Saturday, 28 August 1999 at 2:52:12 -0500, Kris Kirby wrote: Daniel O'Connor wrote: On 28-Aug-99 Kris Kirby wrote: RS232? RS485? VERY cheap and the later is at least moderatly resistant to noise Noise shouldn't be an issue. It's going to be handling "clean" data. By cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like cutting into. I'm going to be bearing the financial end of this project of mine, so I'm going to save where I can. :-) Well serial ports come free on all new computers ;) You're right, I should have clarifed. I'm looking to break 128K. I don't have any serial ports that I can jumper up to 460 or 230 kbps. Additionally, 256K is a nice round number :-). So what's wrong with PLIP? Last time I used it, I was getting about 50 kB/s out of it. I'm not looking to invest in new hardware, and I can save on a bit of hardware by letting the NIC worry about the link. The NIC also greatly simplies the system. At worst, I'd need a machine with a 3C503 and a NE2000. And then I'll probably use dummynet for bandwidth limiting over the link so it doesn't get flooded. I'm going to be building at least three of these units, assuming I get the technical issues out of the way. So I'm looking at a cheap (hardware and software) way of getting data in and out of a PC with IP support and such. It just makes sense in my POV to use a NIC. It's capable of 10 Mbps and has most of the circuitry for preparing data for transmission on it. If you will, it's a ready to use data pump. I think the technical issues will be your problem. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Cheap link (was: Are the ethernet drivers time dependent?)
On 28-Aug-99 Greg Lehey wrote: So what's wrong with PLIP? Last time I used it, I was getting about 50 kB/s out of it. PLIP has a terrible CPU/speed ratio.. You have to busy wait while bashing the parallel port which is just yech :( --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: Cheap link (was: Are the ethernet drivers time dependent?)
Greg Lehey wrote: I'm going to be building at least three of these units, assuming I get the technical issues out of the way. So I'm looking at a cheap (hardware and software) way of getting data in and out of a PC with IP support and such. It just makes sense in my POV to use a NIC. It's capable of 10 Mbps and has most of the circuitry for preparing data for transmission on it. If you will, it's a ready to use data pump. I think the technical issues will be your problem. Well, yeah. :-) High speed FHSS equipment is rather complicated and requires come pretty accurate (TXCO?) signal sources. There are going to be problems. If I can't use a ethernet card, I've got a MCU in mind to do the job. -- Kris Kirby [EMAIL PROTECTED] --- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Are the ethernet drivers time dependent?
Daniel O'Connor wrote: On 28-Aug-99 Kris Kirby wrote: I'm going to be building at least three of these units, assuming I get the technical issues out of the way. So I'm looking at a cheap (hardware and software) way of getting data in and out of a PC with IP support and such. It just makes sense in my POV to use a NIC. It's capable of 10 Mbps and has most of the circuitry for preparing data for transmission on it. If you will, it's a ready to use data pump. Ahh I see.. So you're basically making a ethernet-radio type of thing? Or actually mangling the card itself? Both. The problem is that you can't cram a signal moving at 10 Mbps through a radio interface designed for 256K, even if it is bandwidth limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow it down by yanking it's 20. MHz crystal oscillator and feeding it a lower speed signal. I'm going to walk them down to see just how far I can go. After all, 2 Mbps isn't bad, it just requires a little more work. -- Kris Kirby [EMAIL PROTECTED] --- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Are the ethernet drivers time dependent?
On 28-Aug-99 Kris Kirby wrote: Both. The problem is that you can't cram a signal moving at 10 Mbps through a radio interface designed for 256K, even if it is bandwidth limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow it down by yanking it's 20. MHz crystal oscillator and feeding it a lower speed signal. I'm going to walk them down to see just how far I can go. After all, 2 Mbps isn't bad, it just requires a little more work. Ahh eeww :) I hope you have a lot of spare time ;) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: Are the ethernet drivers time dependent?
Both. The problem is that you can't cram a signal moving at 10 Mbps through a radio interface designed for 256K, even if it is bandwidth limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow it down by yanking it's 20. MHz crystal oscillator and feeding it a lower speed signal. I'm going to walk them down to see just how far I can go. After all, 2 Mbps isn't bad, it just requires a little more work. The 8390 should be functional down to 1MHz or so, and I don't think that signal is used for any other chip functions. You can take the i82586 a lot slower; I recall several S/HDLC-like cards that used them as USRTs in the hundreds of kilobits per second range. Bearing in mind that both the 8390 and the 82586 were designed back when 10MBps was "fast" ethernet. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Fri, Aug 27, 1999 at 11:23:06AM -0700, Doug wrote: On Fri, 27 Aug 1999, Nate Williams wrote: Sentences are supposed to have two spaces before you start the next sentence. Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. I did this change over on the FDP in the Handbook, thinking it didn't make any difference either. Then I got deluged with e-mail from people telling me that lots of editors use the double space as part of their heuristic to determine where sentences start and end. And I turned it back :-) N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Fri, Aug 27, 1999, Doug wrote: -# this file, but rather in /etc/defaults/rc.conf. Please check this file +# this file, but rather in /etc/defaults/rc.conf. Please check that file Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. I've never heard of that. I've always found that two spaces after end-of-sentence punctuation makes things easier to read! (Don't think I don't appreciate this, I just love to nitpick. :) -- |Chris Costello [EMAIL PROTECTED] |To iterate is human; to recurse, divine. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Fri, Aug 27, 1999, Doug wrote: -# this file, but rather in /etc/defaults/rc.conf. Please check this file +# this file, but rather in /etc/defaults/rc.conf. Please check that file Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. I've never heard of that. I've always found that two spaces after end-of-sentence punctuation makes things easier to read! (Don't think I don't appreciate this, I just love to nitpick. :) I vote for two spaces after the period before the start of a new sentence. Even in the digital age, I've always found that the two spaces make for better reading of text. I think that most of our formatting tools do this too (please don't flame me if I'm wrong :-). -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help with exit status in shell script
Roger Hardiman wrote in list.freebsd-hackers:
There is a bug in the PicoBSD build shell script in and I have no idea
how to fix it. As a result, build errors are not caught.
It is all to do with Exit Status of programs called from a shell script.
Please help.
The code fragment from /usr/src/release/picobsd/build/build is
./stage1 21 | tee stage1.out
if [ "X$?" != "X0" ] ; then
echo "^G"
echo "- ERROR in \"${i}\" script. Aborting the build process."
exit 10
fi
Build calls Stage1. Stage1 will return with an error code in some cases
and we want to trap this and halt the Build script.
./stage1 21 | tee stage1.out
if [ "X$?" != "X0" ] ; then
Normally, $? will return the Exit Status of the last executed program.
However, due to the pipe through Tee, the Exit Status I get is the
exit status of Tee and not the exit status of the Stage1 script.
I still want to output the stage1 script to screen and a log file.
How can I do this and preserve the exit status for the Build script.
There are several solutions, but all of them are somewhat
ugly...
One approach would be to use a named pipe, run stage1 in the
background and then wait for it, grabbing its exit status:
FIFO=/tmp/`basename $0`.$$.fifo
trap "rm -f $FIFO" 1 2 15
mkfifo $FIFO
./stage1 $FIFO 21
STAGE1PID=$!
tee $FIFO stage1.out
wait $STAGE1PID
if [ $? != 0 ]; then
...
rm -f $FIFO
Maybe it's possible to open a new shell descriptor (e.g. 3)
instead of a named pipe, but I haven't tried this.
Another way would be to put the exit code into a temporary
file, like this:
trap "rm -f stage1.result" 1 2 15
(
./stage1 21
echo $? stage1.result
) | tee stage1.out
if [ `cat stage1.result` != 0 ]; then
...
rm -f stage1.result
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
WaveLan IEE problem
Hello, I wanted to bring everyone up to date on the problems I have been having with the WaveLAN Turbo PC cards. To date I am still reciving the following error after a day or so of use on only the near side of a point to point link. wi0: init failed wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: failed to allocate 1594 bytes on NIC wi0: mgmt. buffer allocation failed wi0: xmit failed wi0: device timeout (hot swaping the card restores its ability to work) The far side of the lynk has only experianced this problem (or any problems) one time in the month or so I have been using it. I have left that side alone which is running on a laptop with a hacked version of PAO. This is what I have done to date in order to try and solve the problem on the near side. 1) I have applied a patch provided by Bill Paul to the PAO version as well as the lastest version of if_wi.c 2) Jim Flowers infromed me that he was having great success running FreeBSD-Stable, I upgraded to STABLE and this got hot swaping working but still hasn't seemed to solve the problem. (at this point I am no longer running the patch from Bill Paul) 3) I started from scratch. I am using a differant computer (old pent-90 which has run a wl0 card for years), I bought a new WaveLAN Turbo card, A new ISA/PCMCIA adaptor, and did a fresh install of FreeBSD-STABLE on a new hard dirve. On the new hard drive I have only modified the following files, /etc/pccard.conf /etc/rc.conf and the kernel config. Below please find a copy of each. Well thats it in a nut shell. Thaks to everyone for helping so far!! Sincerly, RIchard Puga [EMAIL PROTECTED] ---Kernel config--- # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # 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. # # $Id: GENERIC,v 1.143.2.18 1999/08/18 21:35:37 obrien Exp $ machine "i386" cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" cpu "I686_CPU" ident GENERIC maxusers 32 #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options "CD9660_ROOT" #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on wd0 # 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): #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs controller isa0 controller pnp0 #controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 options "CMD640" # work around CMD640 chip deficiency controller wdc0 at isa? port "IO_WD1" bio irq 14 disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? port "IO_WD2" bio irq 15 disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device acd0 #IDE CD-ROM device wfd0 #IDE Floppy (e.g. LS-120) # A single entry for any of these controllers (ncr, ahb, ahc) is # sufficient for any number of installed devices. controller ncr0 controller ahb0 controller ahc0 controller isp0 # This controller offers a number of configuration options, too many to # document here - see the LINT file in this directory and look up the # dpt0 entry there for much fuller documentation on this. controller dpt0 controller adv0 at isa? port ? cam irq ? controller adw0 controller bt0 at isa? port ? cam irq ? controller aha0 at isa? port ? cam irq ? controller scbus0 device da0 device sa0 device pass0 device cd0 #Only need one of
Re: WaveLan IEE problem
To date I am still reciving the following error after a day or so of use on only the near side of a point to point link. wi0: init failed wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: failed to allocate 1594 bytes on NIC wi0: mgmt. buffer allocation failed wi0: xmit failed wi0: device timeout day? for me and a bunch of others it happens immediately. we have never been able to get wlp or wi going since 3.x. randy, running -release+pao To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Propose mdoc fix regarding ERRORS section
* Mike Pritchard ([EMAIL PROTECTED]) [990828 11:44]: Category: docs Synopsis: src/lib/libc/sys/*.2 misc patch pack - first column in most ERROR lists is too narrow. Normalize their width. Right now we have a problem with our on-line man pages. Most were written when the length of errno's were only 6 - 8 characters long. Now we have errno's that can be up to 15 characters long. Many of our man pages have the following mdoc instruction (or something similar) to ensure that the field width for the errno is appropriate: .Bl -tag -width EBADFXXX Most lists do actually. But you already know =) .Bl -tag -width Er Which will reserve enough space for the errno name based on what width the Er macro specifies. Right now it doesn't allocate enough width to contain our largest errno's. I propose that we fix mdoc to allocate enough width when the second form is specified, and then change all of the man pages to use that format in the ERRORS section. I think using -width Er and setting the Er constant to a higher value might be the best thing. Offcourse we need to check all of the manpages in order whether they use -width EBLAHBLAH or -width Er. If you need help, please yell. -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Fame is the perfume of heroic deeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Panic in pmap_remove_pages on 4.0-current
Anybody seen this before? I was building gtk12 in /usr/ports which
died with a sig 11. I restarted it and it panic'd sometime later.
Crash and kernel file available on anonymous ftp at
ftp://chaos.stdio.com/pub/crash.
anarchy# gdb -k /var/crash/kernel.0 -c /var/crash/vmcore.0
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 3018752
initial pcb at 271c20
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc15d7ff0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc020ff38
stack pointer = 0x10:0xc8d95ef0
frame pointer = 0x10:0xc8d95f00
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 31445 (sh)
interrupt mask = net bio cam
trap number = 12
panic: page fault
syncing disks... 11 done
dumping to dev (13,196609), offset 0
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112
111 110 109 1
08 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87
86 85 84 83
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58
57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30
29 28 27 26 2
5 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:291
291 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:291
#1 0xc0144331 in panic (fmt=0xc02472cf "page fault")
at ../../kern/kern_shutdown.c:515
#2 0xc021227a in trap_fatal (frame=0xc8d95eb0, eva=3244130288)
at ../../i386/i386/trap.c:907
#3 0xc0211f2d in trap_pfault (frame=0xc8d95eb0, usermode=0,
eva=3244130288)
at ../../i386/i386/trap.c:800
#4 0xc0211b6f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi
= 0,
tf_esi = -1066564500, tf_ebp = -925278464, tf_isp = -925278500,
tf_ebx = -1066592668, tf_edx = -943206164, tf_ecx = -1050837008,
tf_eax = -1066564500, tf_trapno = 12, tf_err = 2, tf_eip =
-1071579336,
tf_cs = 8, tf_eflags = 66182, tf_esp = -943206272, tf_ss = 0})
at ../../i386/i386/trap.c:426
#5 0xc020ff38 in pmap_remove_pages (pmap=0xc7c7d0e4, sva=0,
eva=3217022976)
at ../../i386/i386/pmap.c:2981
#6 0xc013dcdf in exit1 (p=0xc8d89ba0, rv=0) at ../../kern/kern_exit.c:219
#7 0xc013daf0 in exit1 (p=0xc8d89ba0, rv=17) at
../../kern/kern_exit.c:106
#8 0xc02124be in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 1, tf_esi = -1077945183, tf_ebp = -1077948100,
tf_isp = -925278252, tf_ebx = 1, tf_edx = 0, tf_ecx = 135127040,
tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 134653456, tf_cs =
31,
tf_eflags = 642, tf_esp = -1077948180, tf_ss = 47})
at ../../i386/i386/trap.c:1056
#9 0xc02041a6 in Xint0x80_syscall ()
Cannot access memory at address 0xbfbfd13c.
(kgdb)
Larry Lile
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Help with exit status in shell script
Hi, There is a bug in the PicoBSD build shell script in and I have no idea how to fix it. As a result, build errors are not caught. It is all to do with Exit Status of programs called from a shell script. Please help. The code fragment from /usr/src/release/picobsd/build/build is ./stage1 21 | tee stage1.out given that there is, in the same script, a "fail" procedure to handle such cases, i believe you could do something like (./stage1 21 || fail $? stage1_failed ) | tee stage1.out (where the $? has nothing special, just that the "fail" procedre expects the errcode as first argument). If it turns out to be problematic, for 3.3R you could as well remove the "tee", after all it was just there for debugging. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should cam_imask be part of bio_imask ?
Isn't all the work in CAM done at splsoftcam? (or am I thinking of old code) It starts off an ISR similar to the netisr doesn't it? On Sat, 28 Aug 1999, Matthew Dillon wrote: I'm trying to track down some VFS/BIO corruption on an NFS server being tested under heavy loads and noticed that my SCSI interrupts do not appear to be blocked by splbio(). (The adaptec's are on irq 5 and irq 12) (kgdb) print bio_imask $1 = 0x40080040 (kgdb) print cam_imask $2 = 0x400c1020 (kgdb) This doesn't sound right to me. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
:I've never heard of that. I've always found that two spaces : after end-of-sentence punctuation makes things easier to read! : :I vote for two spaces after the period before the start of a new sentence. :Even in the digital age, I've always found that the two spaces make :for better reading of text. I think that most of our formatting :tools do this too (please don't flame me if I'm wrong :-). : :-Mike :-- :Mike Pritchard :[EMAIL PROTECTED] or [EMAIL PROTECTED] I guess they don't teach manual typewriting classes any more :-) It *had* to be two spaces or you got seriously marked down! Two spaces has been burned into my brain since high school! (I wonder if I can sue?) GRIN. For proof, just look at all the postings I've ever made to these lists. I'm not nitpicking... I couldn't care less what other people do. But I think it's an amusing generational effect. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should cam_imask be part of bio_imask ?
: Isn't all the work in CAM done at splsoftcam? : :Not all. There's completions done at splcam. I've had some worries and :concerns about this, but (wince) I really have to admit that the ins and :outs of the cam code often escape me, and they're documented only in the :DNA of certain human subspecies that reside in Colorado. Hmm, ok. Shoot. This is what I'm getting. If I have an NFS server and client running CURRENT, and (from the client) I copy the CVS repository from the server to the client, and then diff them, I get little discrepancies. An example is included below. *** /FreeBSD/FreeBSD-CVS/src/sys/pci/ncr.c,vFri Aug 27 17:51:03 1999 --- /home/ncvs/src/sys/pci/ncr.c,v Fri Aug 27 17:51:03 1999 *** *** 12211,12217 d55 1 d1345 1 a1345 1 ! "\nhis product 1.112 1997/11/07 09:20:56 phk Exp $\n"; @ --- 12211,12217 d55 1 d1345 1 a1345 1 ! "\n$Id: ncr.c,v 1.112 1997/11/07 09:20:56 phk Exp $\n"; @ I'm still experimenting trying to focus in on where the problem is. It is a very weird problem. Sometimes the errors are small, sometimes who pages are wrong. The scary part is that they are wrong in the server's cache! If I catch the error quickly enough and cat the file on the server, the error shows up on the server! If I then, on the server, eat up memory to flush the caches and then cat the file again, the error is gone again. I'm going to try changing it over from an NFSv3 to an NFSv2 mount to see if that does anything. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should cam_imask be part of bio_imask ?
I strongly doubt that this is a CAM isr problem- the error pattern isn't
entirely clear from what you said, but it looks more like a FIFO or CACHE
LINE sized type of problem- it looks to be 16 bytes, but not a short
count. Because this isn't one of the wacky systems I spent most of my
career on at Sun where the first and usual suspect was a system memory
cache line because IO wasn't cache coherent on Suns between the Sun
3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a
FIFO somewhere in the I/O movement path.
Justin- any changes lately where flushing a FIFO in the Adaptec at the end
of tranfer might have been spoodged?
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Should cam_imask be part of bio_imask ?
:I strongly doubt that this is a CAM isr problem- the error pattern isn't
:entirely clear from what you said, but it looks more like a FIFO or CACHE
:LINE sized type of problem- it looks to be 16 bytes, but not a short
:count. Because this isn't one of the wacky systems I spent most of my
:career on at Sun where the first and usual suspect was a system memory
:cache line because IO wasn't cache coherent on Suns between the Sun
:3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a
:FIFO somewhere in the I/O movement path.
:
:Justin- any changes lately where flushing a FIFO in the Adaptec at the end
:of tranfer might have been spoodged?
:
:-matt
The problem is definitely aligned in some way. Here's a diff of
a hexdump of one error. Sometimes I lose a whole page, sometimes two
pages, sometimes 16 bytes, but the error is always page aligned.
1536c1536
0005ff0 2033 3434 3434 7c20 207c 3030 3030
---
0005ff0 7365 3d20 3120 093b 2309 6720 6f6c 6162
A cache-line problem would fit the symptoms. I know it isn't the
hardware... this 1xCPU PPro/200 system has been with me for several
years and this test didn't fail like this a month ago. When I updated
the machine last (unfortunately w/ about a month's worth of changes),
my buildworlds started failing with odd errors.
I then switched away from the failing buildworlds (which take an hour)
and started doing cp -r's and then diff -r's (takes only 20 min), and as
you can see I'm still seeing the problem.
Maybe this is DMA related. Perhaps the cache is not getting cleared?
Maybe an MMU optimization someone threw in recently?
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Should cam_imask be part of bio_imask ?
:I strongly doubt that this is a CAM isr problem- the error pattern isn't
:entirely clear from what you said, but it looks more like a FIFO or CACHE
:LINE sized type of problem- it looks to be 16 bytes, but not a short
:count. Because this isn't one of the wacky systems I spent most of my
:career on at Sun where the first and usual suspect was a system memory
:cache line because IO wasn't cache coherent on Suns between the Sun
:3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a
:FIFO somewhere in the I/O movement path.
:
:Justin- any changes lately where flushing a FIFO in the Adaptec at the end
:of tranfer might have been spoodged?
:
:-matt
The problem is definitely aligned in some way. Here's a diff of
a hexdump of one error. Sometimes I lose a whole page, sometimes two
pages, sometimes 16 bytes, but the error is always page aligned.
1536c1536
0005ff0 2033 3434 3434 7c20 207c 3030 3030
---
0005ff0 7365 3d20 3120 093b 2309 6720 6f6c 6162
A cache-line problem would fit the symptoms. I know it isn't the
hardware... this 1xCPU PPro/200 system has been with me for several
years and this test didn't fail like this a month ago. When I updated
the machine last (unfortunately w/ about a month's worth of changes),
my buildworlds started failing with odd errors.
I then switched away from the failing buildworlds (which take an hour)
and started doing cp -r's and then diff -r's (takes only 20 min), and as
you can see I'm still seeing the problem.
Maybe this is DMA related. Perhaps the cache is not getting cleared?
Maybe an MMU optimization someone threw in recently?
That's possible too- I'll admit I'm a bit hazy on i386 specifics- it's
always been a "just works wrt I/O" so for all I know there's a required
i/o flush command when you switch mappings. Gawd I hate these kind of
problems.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Its about that time of year again. (FreeBSD MCA)
On Sat, 28 Aug 1999, Andy Farkas wrote: I have a truckload of MCA cards - scsi controllers (ibm, adaptec, buslogic, pro-comm), ethernet (ne2000, 3com), memory boards (ibm, other), serial controllers, XGA-2 I'll try and give 'em all a go... If you've got an adaptec 1640, please try http://www.jurai.net/~winter/mca/aha_mca.c Set your DMA channel to something under 7 though as I've not quite figured out a good way to intercept the resource manager calls for channels above 7. -- | 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-hackers" in the body of the message
Re: locking revisited
As a result, I argue that we should implement locking. The questions are: how? I'd suggest three methods which can be individually enabled via sysctls: - System V style. We need this for compatibility with System V. The choice of mandatory or advisory locking depends on the file permissions. - Only mandatory locking. fcntl works as before, but locks are always mandatory, not advisory. I'm sure that this won't be popular, at least initially, but if you don't like it, you don't have to use it.y - Via separate calls to fcntl. fcntl currently has the following command values: #define F_DUPFD 0 /* duplicate file descriptor */ #define F_GETFD 1 /* get file descriptor flags */ #define F_SETFD 2 /* set file descriptor flags */ #define F_GETFL 3 /* get file status flags */ #define F_SETFL 4 /* set file status flags */ #define F_GETOWN5 /* get SIGIO/SIGURG proc/pgrp */ #defineF_SETOWN 6 /* set SIGIO/SIGURG proc/pgrp */ #define F_GETLK 7 /* get record locking information */ #define F_SETLK 8 /* set record locking information */ #define F_SETLKW9 /* F_SETLK; wait if blocked */ We could add a F_SETMANDLOCK or some such. Any thoughts? (I'm following up only on -hackers because I personally hate discussions in -commit.) Yes - 1. Isn't vinum a device? Isn't this file-level locking irrelevant? Shouldn't all locking for maintenance be done at the device level? 2. I'll bet there are some standards, at least in development. Have you done a few searches? I have other opinions, some that I hold strongly, but since they have to do with lack of definition of boundary conditions then I won't bring them up until (2.) is answered. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should cam_imask be part of bio_imask ?
Oh, Tor didn't Cc hackers. Tor suggested adding the CACHETHEN bit back in the adaptec controller, undoing part of Justin's commit on the 15th (see the commitlogs for sys and search for 'CACHETHEN'). This fixed the problem! Ah, sunshine here I come! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Panic in pmap_remove_pages on 4.0-current
This exact problem came up last month. pmap_remove_pages is tripping over a corrupted page table entry (pte). Unfortunately, by the time the panic occurs, pmap_remove_pages has overwritten the corrupted pte with zero. Earlier this month, I added a KASSERT to detect this problem (and panic) before the corrupted pte is overwritten. This KASSERT seems to be missing from your kernel. Could you turn on assertion checking in your kernel configuration and/or update to a newer kernel. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Nik Clayton wrote: On Fri, Aug 27, 1999 at 11:23:06AM -0700, Doug wrote: On Fri, 27 Aug 1999, Nate Williams wrote: Sentences are supposed to have two spaces before you start the next sentence. Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. I did this change over on the FDP in the Handbook, thinking it didn't make any difference either. Then I got deluged with e-mail from people telling me that lots of editors use the double space as part of their heuristic to determine where sentences start and end. And I turned it back :-) Okey dokey, I can take a hint. :) Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Are the ethernet drivers time dependent?
On Sat, 28 Aug 1999, Kris Kirby wrote: Both. The problem is that you can't cram a signal moving at 10 Mbps through a radio interface designed for 256K, even if it is bandwidth limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow it down by yanking it's 20. MHz crystal oscillator and feeding it a lower speed signal. I'm going to walk them down to see just how far I can go. After all, 2 Mbps isn't bad, it just requires a little more work. What about ARCnet? -- | 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-hackers" in the body of the message
Re: Please review: rc file changes
Matthew Dillon wrote: I guess they don't teach manual typewriting classes any more :-) Actually I took that class in Jr. High School, way back in '77. It was the only good advice my Jr. High guidance counselor gave me. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Today Doug wrote: Matthew Dillon wrote: I guess they don't teach manual typewriting classes any more :-) Actually I took that class in Jr. High School, way back in '77. It was the only good advice my Jr. High guidance counselor gave me. Doug When I was in 8th grade (1964-65) you passed typing or you didn't go on to 9th grade, it was part of the district's required curriculum. I had a friend that ended up in summer school just to take typing. A single space after a period counted as two or three "incorrect characters" as I recall. -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Cleaned up this post a little for the final (?) version of rc.diff. Back
by popular demand, double spaces after the periods! Well, partly by popular
demand and partly because I think it bouys my argument for a space after
the case options. :) Note the changed URL for the real file. Without
further comment this is the final verion of the rc file diff, but I will
submit it along with the rest when I'm done.
Greetings,
As previously discussed, here is a first draft of the rc* script
mods. I
consider the first step in this process to be Jordan's cleanup of the
variable syntax. This is step 2, which most notably converts test's dealing
with variables to case wherever possible. It also does the following.
1. -f - -r wherever it makes sense
2. value ) instead of value) for case statements
3. All cases of [, test, ; then, etc. converted to:
if [ blah ]; then
4. Made
# Comment
#
commands
more consistent
5. Stripped whitespace off the end of a few lines
6. Tuned up a few of the comments in the file, as well as error output. I
also was more rigorous about making whitespace consisten on this pass.
Removing double spaces, converting spaces to tabs, etc.
The attached diff is to rc, and was generated with -u. You can view
the actual file at http://gorean.org/rcfiles/rc. I would appreciate y'all
reviewing these changes for style, substance, or anything else relevant to
the matter at hand. My hope is that any modifications can be discussed
prior to my doing the rest of the work, which I plan to tackle this
weekend. There are
also a few questions sprinkled into the file, comments or suggestions on
those
are welcome.
This version of the file is tested lightly, which is to say that I
booted with it after my upgrade to the most recent sources on -current
tonight.
Obviously more rigorous testing will be necessary before this gets
committed, although the changes are extremely straightforward.
Questions:
1. Under what circumstances would $early_nfs_mounts be set? The only
mention of this variable that I could find is in /etc/rc, and I can't see
where it would be set.
2. Does the following constitute a security hole?
# Make a bounds file for msgs(1) if there isn't one already
# "Delete important files with symlink" security hole?
#
if [ ! -f /var/msgs/bounds ]; then
echo 0 /var/msgs/bounds
fi
3. Do we want to move to 'logger' instead of echo for the various little
statements in the rc* files during boot? I for one would highly recommend
this change, since it makes remote administration TONS easier. However the
last time it came up I seem to remember it being one of those "religious"
issues... I see this as step 3. of the project, and will go ahead with it
after step 2. is done if there is no objection.
3. Anything else I should be looking at in this phase of the game?
Doug
--- /usr/src/etc/rc Sat Aug 28 13:51:10 1999
+++ rc Sat Aug 28 14:08:25 1999
@@ -8,24 +8,25 @@
# and the console is the controlling terminal.
# Note that almost all the user-configurable behavior is no longer in
-# this file, but rather in /etc/defaults/rc.conf. Please check this file
+# this file, but rather in /etc/defaults/rc.conf. Please check that file
# first before contemplating any changes here.
stty status '^T'
# Set shell to ignore SIGINT (2), but not children;
# shell catches SIGQUIT (3) and returns to single user after fsck.
+#
trap : 2
trap : 3 # shouldn't be needed
-HOME=/; export HOME
+HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
-export PATH
+export HOME PATH
# BOOTP diskless boot. We have to run the rc file early in order to
# retarget various config files.
#
-if [ -f /etc/rc.diskless1 ]; then
+if [ -r /etc/rc.diskless1 ]; then
dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2 /dev/null`
if [ ${dlv:=0} != 0 ]; then
. /etc/rc.diskless1
@@ -34,59 +35,68 @@
# If there is a global system configuration file, suck it in.
#
-if [ -f /etc/defaults/rc.conf ]; then
+if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
+elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
# Configure ccd devices.
-if [ -f /etc/ccd.conf ]; then
+#
+if [ -r /etc/ccd.conf ]; then
ccdconfig -C
fi
-if [ "${start_vinum}" = "YES" ]; then
+case ${start_vinum} in
+[Yy][Ee][Ss] )
vinum start
-elif [ -n "${vinum_drives}" ]; then
- vinum read ${vinum_drives}
-fi
+ ;;
+* )
+ if [ -n "${vinum_drives}" ]; then
+ vinum read ${vinum_drives}
+ fi
+ ;;
+esac
swapon -a
-if [ "$1" = "autoboot" ]; then
+case $1 in
+autoboot )
echo Automatic reboot in progress...
fsck -p
case $? in
- 0)
+ 0 )
;;
- 2)
+ 2 )
exit 1
;;
- 4)
+ 4 )
reboot
echo "reboot failed... help!"
exit 1
Re: Please review: rc file changes
On Sat, Aug 28, 1999, Tim Vanderhoek wrote: A sentence ends .Ar here . But this new one has a single space preceeding it. Does adding a space after the `.' at the end of your line help? Please, no trailing white space :-)! Seriously, I think that all of the current mdoc macros that allow puncuation characters to be specified screw this up and only add one space. Mdoc should be fixed to add two spaces in this case, and then if the man page author really does only want one space, they can do it with the existing Ns macro (no space). -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Doug wrote: Okey dokey, I can take a hint. :) Can you take another one, regarding the unnecessary spaces after the values in your "case"s? i.e., that they should be taken out and shot? :-) -- Ben Smithurst| PGP: 0x99392F7D [EMAIL PROTECTED] | key available from keyservers and | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Doug wrote in list.freebsd-hackers: 2. value ) instead of value) for case statements Maybe I missed it, but what exactly is the reason for that change? I do not like it, it makes the case lines look strange. And I think there was a policy that style should not be changed if there's no good reason. Apart from that -- Good work! :) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
Ben Smithurst wrote: Doug wrote: Okey dokey, I can take a hint. :) Can you take another one, regarding the unnecessary spaces after the values in your "case"s? i.e., that they should be taken out and shot? :-) *sigh* I am constantly flabbergasted by what people think of as "important" around here. However, yes, I really can take the hint, and having seen no words of support on this I will revert the change. Hoping I'm running out of nits, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
/usr/src/etc files without $FreeBSD tags
While we're at it: 24$ grep -RL '\$FreeBSD' /usr/src/etc/* /usr/src/etc/amd.map /usr/src/etc/fbtab /usr/src/etc/isdn/isdnd.rates.UK.BT /usr/src/etc/kerberosIV/krb.conf /usr/src/etc/kerberosIV/krb.realms /usr/src/etc/locale.alias /usr/src/etc/master.passwd /usr/src/etc/minfree /usr/src/etc/motd /usr/src/etc/namedb/named.root /usr/src/etc/rc.diskless1 /usr/src/etc/rc.diskless2 /usr/src/etc/sendmail/freebsd.mc /usr/src/etc/termcap.small Having the tags in the files helps mergemaster, if nothing else. :) Thanks, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD???
On Fri, 27 Aug 1999, Thomas David Rivers wrote: First - let me point out that FreeBSD already runs on the Alpha, so there's some 64-bit experience. Very good point, which ought to be brought out more than once, it's good for the rep. And - let me add - Intel has been down this path before (the i860) - and didn't see the success it wanted (although the i860 is popping up in some interesting places now...) I am going to say something controversial here, but I'm interested in the reply When I was in the computer architecture classes, I did a lot of modeling of various kinds of things that could be done to speed up a processor (the least of which is cache memory, but it stands as a good "for instance" thing here). One thing that impressed me, when doing modelling of multiple different things like speculative execution and the IA64's rumored ability to speculatively execute several different paths of loop, was the extreme difficulty to adequately model how all the different parts work (and mis-work) together. You end up having to really inspect many megabytes of output in detail, just to figure out if one feature worked right in one particular scenario, and I was only doing a relatively basic piece of modelling. Trying to model the IA64 would have been a Manhattan Project sized task. Honestly, I am wondering about Intel and HP's ability to really produce a reliable chip that had as many difficult-to-model features as the IA64 is supposed to have. I think that's the real reason that it's not actually being sampled. Your point on the 860 is very correct, but if they *could* have brought the IA64 out today with the features that they have been promising (at the speed they promised) it would have made the PowerPC and the Alpha look ill, and I *do* think it would have been quite a masterstroke by Intel, merely because the monstrous resources needed for a competitor to do the same would have guaranteed Intel at least a very good running start on the market. This makes me believe, more than ever, that everything that Intel has put out on the IA64 (and, at least in academic circles, that's a whole lot) has been vaporware and FUD. I can't respect them for that. I suppose what this "rant" is all about is that I'm not convinced Merced is the "chip of the future" that we all need to be worried about. I'm taking a "wait-and-see" attitude. [Also, since Microsoft has been working closely with Intel regarding Merced for several years now, and has yet to do anything `serious' - I believe they are taking the same "wait-and-see" approach. Likely while telling Intel otherwise.] That doesn't mean I think we shouldn't have a FreeBSD port; I would considering buying a Merced box if there was one (although, I don't have an Alpha box, so maybe it would never get past "consider".) - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message ---+--- Chuck Robey| Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770| picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---+--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: locking revisited
On Saturday, 28 August 1999 at 15:16:28 -0400, Peter Dufault wrote: As a result, I argue that we should implement locking. The questions are: how? I'd suggest three methods which can be individually enabled via sysctls: - System V style. We need this for compatibility with System V. The choice of mandatory or advisory locking depends on the file permissions. - Only mandatory locking. fcntl works as before, but locks are always mandatory, not advisory. I'm sure that this won't be popular, at least initially, but if you don't like it, you don't have to use it.y - Via separate calls to fcntl. fcntl currently has the following command values: #define F_DUPFD 0 /* duplicate file descriptor */ #define F_GETFD 1 /* get file descriptor flags */ #define F_SETFD 2 /* set file descriptor flags */ #define F_GETFL 3 /* get file status flags */ #define F_SETFL 4 /* set file status flags */ #define F_GETOWN5 /* get SIGIO/SIGURG proc/pgrp */ #defineF_SETOWN 6 /* set SIGIO/SIGURG proc/pgrp */ #define F_GETLK 7 /* get record locking information */ #define F_SETLK 8 /* set record locking information */ #define F_SETLKW9 /* F_SETLK; wait if blocked */ We could add a F_SETMANDLOCK or some such. Any thoughts? (I'm following up only on -hackers because I personally hate discussions in -commit.) I'm copying -commit because that's where we're supposed to discuss these things. I made the mistake of excluding them once before, and the results were painful. 1. Isn't vinum a device? Yes. Isn't this file-level locking irrelevant? To Vinum, yes. Shouldn't all locking for maintenance be done at the device level? Maybe. Depends on what kind of maintenance you're doing. What happens if you want to dd one plex to another? You've missed another message of mine, where I said that this issue has no relevance to Vinum. 2. I'll bet there are some standards, at least in development. Have you done a few searches? Sure. The important one was in the attachment: System V has a standard. I have other opinions, some that I hold strongly, but since they have to do with lack of definition of boundary conditions then I won't bring them up until (2.) is answered. Go for it. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NIS client (ypbind) feature on FreeBSD 3.2-STABLE
Hi, This is long but I wanted to provide as much information as possible. There appears to be an interesting "feature" with NIS client support under FreeBSD 3.2-STABLE (as at Tuesday 24 August). This was a new installation onto a Dell Precision 410-MT (single 400MHz CPU, single SCSI disk, on-board fast ethernet) into an existing environment (the first FreeBSD host in this environment which has mainly Suns, a few Alpha and SGIs and an increasing number of Linux boxes). The machine is part of a group that does telecommunications and networking research - they already have Suns and Linux boxes. Essentially the install went smoothly direct from the 3.2 CDs, and subsequent post-installation configuration involved making a custom kernel, setting up NIS client support, configuring AMD, installing some key packages (e.g. "ssh") and installing and configuring an Efficient ATM card (using HARP included in the release). No real problems with any of this. NIS client support uses "ypbind" in broadcast mode - the NIS master server is a SunOS 4.1.3_U1B machine and three other NIS slave servers are all running Solaris 2.6. This environment has served the site well for a number of years and is VERY stable. We make extensive use of various NIS maps including the automounter for home directories. What appears to happen with the FreeBSD host is that after a reboot, it correctly binds to one of the NIS servers BUT whenever, for whatever reason, it is forced to re-bind it ends up never re-binding, creates something like 600kbit/s of broadcast traffic across our LAN and forces the "rpcbind/portmap" and "ypserv" process on the NIS servers to become CPU bound - it appears to also cause problems for some other broadcast-type applications such as DHCP. Interestingly, the broadcast traffic slowly decreases but probably only by say 100kbit/s in a period of more that 12 hours. Some info: FreeBSD host: % ypwhich ypwhich: can't yp_bind: reason: Domain not bound USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 147 44.7 1.5 1288 924 ?? Rs Tue08PM 394:11.05 ypbind root 132 1.6 0.9 820 576 ?? Ss Tue08PM 23:43.76 syslogd daemon 143 1.1 1.0 836 600 ?? Ss Tue08PM 22:50.86 /usr/sbin/portmap NIS master (SunOS 4.1.3_U1B): USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND root60 34.0 0.3 68 236 ? R20:27 280:09 portmap root65 33.6 0.4 172 388 ? R20:27 280:06 ypserv NIS slave (Solaris 2.6): ~~~ USER PID %CPU %MEM SZ RSS TT SSTART TIME COMMAND root 221 17.6 0.3 2264 1216 ?R Jul 29 386:43 rpcbind root 234 4.4 0.3 2368 1400 ?S Jul 29 474:11 ypserv In addition, from "syslog" on the FreeBSD host (the broadcast problem started at around 16:41 so the earlier messages may not be significant): Aug 26 05:19:24 rational xntpd[139]: time reset (step) 0.370413 s Aug 26 14:25:03 rational portmap[3024]: connect from 130.155.194.226 to callit(ypserv): request not forwarded Aug 26 14:25:03 rational portmap[3025]: connect from 130.155.194.226 to callit(ypserv): request not forwarded ... Aug 26 16:41:15 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp .csiro.au" not responding Aug 26 16:41:21 rational last message repeated 2684 times Aug 26 16:41:21 rational /kernel: xl0: command never completed! Aug 26 16:41:21 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp.csiro.au" not responding Aug 26 16:41:21 rational last message repeated 68 times Aug 26 16:41:21 rational /kernel: xl0: command never completed! Aug 26 16:41:21 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp.csiro.au" not responding Aug 26 16:41:21 rational /kernel: xl0: command never completed! Aug 26 16:41:21 rational last message repeated 3 times Aug 26 16:41:21 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp.csiro.au" not responding Aug 26 16:41:52 rational last message repeated 13943 times I thought it was interesting to see the messages from the "xl0" driver - this machine has an on-board 3Com ethernet (as do most newish Dell's) and is connected to a 10mbit/s hub: xl0: 3Com 3c905B-TX Fast Etherlink XL rev 0x00 int a irq 14 on pci0.17.0 xl0: Ethernet address: 00:c0:4f:68:e1:6a xl0: autoneg complete, link status good (half-duplex, 10Mbps) The problem is repeatable and as a test I tried to force the host to bind to particular servers using the "-S" option. It works after a reboot but no subsequently with similar problems on the NIS servers. I didn't see the "xl0" messages in this case though: Aug 28 13:08:48 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp.csiro.au" not responding Aug 28 13:09:19 rational last message repeated 14143 times Aug 28 13:11:20 rational last message repeated 55641 times Aug 28 13:21:21
Re: HEADS UP Reviewers. VFS changes to be committed.
On Fri, 27 Aug 1999, Poul-Henning Kamp wrote: Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? I can't really tell if you are commenting on the diffs I provided or if you are commmenting on the comments I have recieved, or both. Either way, could you elaborate a bit? I was hoping for your input on this issue. thank you, -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] Poul-Henning In message [EMAIL PROTECTED], Erez Zadok write s: In message [EMAIL PROTECTED], Matthew Dillon writes: [...] I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. Moreover, I would strongly recommend xplicitly documenting the following: - which function args are in-args and which are out-args? - does the function takes any allocated memory that it is expected to free? - is the function expected to allocate any memory objects that have to be freed elsewhere? - does the function increase or decrease any reference counts of any objects? Is it expected to? These and other requirements are essentially the "interface" between the VFS and lower-level file systems. Figuring out this stuff on every OS and OS revision (esp. when the VFS changes so often---linux) was the longest most frustrating task I faced when writing my Wrapfs stackable f/s module for solaris, freebsd, and linux. I wish documentation had been in place. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Sat, 28 Aug 1999, Doug wrote:
Ben Smithurst wrote:
Doug wrote:
Okey dokey, I can take a hint. :)
Can you take another one, regarding the unnecessary spaces after the
values in your "case"s? i.e., that they should be taken out and shot?
:-)
*sigh* I am constantly flabbergasted by what people think of as
"important" around here. However, yes, I really can take the hint, and
having seen no words of support on this I will revert the change.
Hoping I'm running out of nits,
Heh. This thread is as good as the 'Jordan got bitten by Radius' one :)
Doug
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
readdir() broken?
Hello Doug, hello Matthew, hello list members,
there are some hints that readdir() in -STABLE has problems when
used on NFSv3 (UDP; and TCP probably, too) mounted file systems.
The reason may be the recovery code for stale READDIR cookies.
The problem occurs when using GNU rm (fileutils-4.0) on our
systems (NFS servers and clients -STABLE) for deleting large
directory trees (e.g. egcs source tree). rm failed to delete
some directories:
rm: cannot remove directory `egcs-1.1.2/gcc': Directory not empty
I've roughly looked through the sources and found a workaround
for a readdir() bug on SunOS 4.1.4. The SunOS readdir() sometimes
returned NULL although there were still entries to be read when
a directory with more than 254 entries was previously modified.
The workaround rewound the directory stream and read it again.
Interestingly this workaround also works for FreeBSD although
our readdir() passes the autoconfig tests that trigger the
workaround without a hinch.
Attached is a patch for GNU fileutils-4.0 that will make rm
yield when the workaround code catches a bad readdir().
Björn Fischer
PS: Please don't ask me why I'm using GNU fileutils.
--- remove.c1999/08/29 02:57:38 1.1
+++ remove.c1999/08/29 03:07:42
@@ -526,6 +526,8 @@
{
/* empty */
}
+ if (dp != NULL)
+ fputs("*** readdir() returned NULL and shouldn't.\n", stderr);
}
#endif
--
-BEGIN GEEK CODE BLOCK-
GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L+++(--) !E W- N+ o+
K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+
--END GEEK CODE BLOCK--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD???
The trade rags here insist it has already happened: M$ stopped 64 bit Alpha NT. Beats me if it is true or not. Here's the confusing part: they say M$ stopped making 64 bit Alpha NT, but some say they are actually developing Win2000 64 bit for Alpha's. Since 2000 is NT based, you'd think that support was dropped for it too, but then I heard a couple rumors about Win2000 64 bit for Alpha... I don't know. I think I will wait until marketing clears up at least a little bit, until you know what OS's your hardware can run before buying anything new... - We are now the Knights who say... Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Are the ethernet drivers time dependent?
Matthew N. Dodd wrote: On Fri, 27 Aug 1999, Kris Kirby wrote: It's not a bandwidth issue; it's a speed issue. I'm trying to find an extremely cheap way to get data in and out of a PC. How about an I2C bus? (Or is that -too- slow?) I'll have to admit I'm totally ignorant of what this is. -- Kris Kirby k...@airnet.net --- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Are the ethernet drivers time dependent?
Julian Elischer wrote: plip? Ideally, no. The ethernet card makes the data rather easy to handle into other means (like a radio modem). It's already serialized, packetized, has a MAC address for a link address, and it's easy to get seperate RX and TX lines out of the card, even if it is 10Base-2 (BNC). The idea is to eliminate other hardware in order to drop cost and complication. -- Kris Kirby k...@airnet.net --- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Are the ethernet drivers time dependent?
Daniel O'Connor wrote: On 28-Aug-99 Kris Kirby wrote: It's not a bandwidth issue; it's a speed issue. I'm trying to find an extremely cheap way to get data in and out of a PC. I've got the National Semiconductor application sheets for the 8392(?) and plan on using one cut in half: Half duplex, but split into seperate TX and RX lines. I'm also looking at a scaleable way to go up or down in speed, without dealing with async... A layer two device if you will. RS232? RS485? VERY cheap and the later is at least moderatly resistant to noise :) Noise shouldn't be an issue. It's going to be handling clean data. By cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like cutting into. I'm going to be bearing the financial end of this project of mine, so I'm going to save where I can. :-) -- Kris Kirby k...@airnet.net --- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Are the ethernet drivers time dependent?
On 28-Aug-99 Kris Kirby wrote: RS232? RS485? VERY cheap and the later is at least moderatly resistant to noise Noise shouldn't be an issue. It's going to be handling clean data. By cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like cutting into. I'm going to be bearing the financial end of this project of mine, so I'm going to save where I can. :-) Well serial ports come free on all new computers ;) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgpo36oVrfpsb.pgp Description: PGP signature
Re: Are the ethernet drivers time dependent?
USB? http://www.activewire.com/ has a nice board that does I2C as well. With a bit of plumbing you should be able to stream out 100kb a second. Nick On Fri, 27 Aug 1999, Julian Elischer wrote: plip? On Fri, 27 Aug 1999, Matthew N. Dodd wrote: On Fri, 27 Aug 1999, Kris Kirby wrote: It's not a bandwidth issue; it's a speed issue. I'm trying to find an extremely cheap way to get data in and out of a PC. How about an I2C bus? (Or is that -too- slow?) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Its about that time of year again. (FreeBSD MCA)
On Fri, 27 Aug 1999, Matthew N. Dodd wrote:
I will ask another question; Anyone want to see what I've got so far?
http://www.jurai.net/~winter/mca/
README.mca
mca.diff
mca.tar.gz
MicroChannel Architecture System detected.
...
mca0: MCA bus on motherboard
Excellent! Although you've now forced me to put off all other weekend
'projects' (lawn-mowing, car-washing, etc) :-)
I'd really like a few other people to try booting a kernel with this code
on any of the MCA systems they happen to have laying around just to make
sure that my changes do indeed work on other hardware than my Model 77.
I have a truckload of MCA cards - scsi controllers (ibm, adaptec,
buslogic, pro-comm), ethernet (ne2000, 3com), memory boards (ibm, other),
serial controllers, XGA-2 I'll try and give 'em all a go...
If someone has a ABIOS block device driver code hiding on their hard disk
I'd really like to look at it (I already know about the Mach3 stuff).
I have the OS/2 device driver development kit. There may be something in
there. I'll check.
Thanks!
Thank you!
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |
--
:{ an...@speednet.com.au
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Are the ethernet drivers time dependent?
Daniel O'Connor wrote: On 28-Aug-99 Kris Kirby wrote: RS232? RS485? VERY cheap and the later is at least moderatly resistant to noise Noise shouldn't be an issue. It's going to be handling clean data. By cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like cutting into. I'm going to be bearing the financial end of this project of mine, so I'm going to save where I can. :-) Well serial ports come free on all new computers ;) You're right, I should have clarifed. I'm looking to break 128K. I don't have any serial ports that I can jumper up to 460 or 230 kbps. Additionally, 256K is a nice round number :-). I'm not looking to invest in new hardware, and I can save on a bit of hardware by letting the NIC worry about the link. The NIC also greatly simplies the system. At worst, I'd need a machine with a 3C503 and a NE2000. And then I'll probably use dummynet for bandwidth limiting over the link so it doesn't get flooded. I'm going to be building at least three of these units, assuming I get the technical issues out of the way. So I'm looking at a cheap (hardware and software) way of getting data in and out of a PC with IP support and such. It just makes sense in my POV to use a NIC. It's capable of 10 Mbps and has most of the circuitry for preparing data for transmission on it. If you will, it's a ready to use data pump. -- Kris Kirby k...@airnet.net --- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Are the ethernet drivers time dependent?
Well serial ports come free on all new computers ;) You mean like the PC 2000 that _only_ comes with USB and for which you will have to buy a USB-serial converter that might not handle the signalling you had in mind? :-) Nick http://www.etla.net/~n_hibma/usb/usb.pl -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Propose mdoc fix regarding ERRORS section
Category: docs Synopsis: src/lib/libc/sys/*.2 misc patch pack - first column in most ERROR lists is too narrow. Normalize their width. Right now we have a problem with our on-line man pages. Most were written when the length of errno's were only 6 - 8 characters long. Now we have errno's that can be up to 15 characters long. Many of our man pages have the following mdoc instruction (or something similar) to ensure that the field width for the errno is appropriate: .Bl -tag -width EBADFXXX As things have progressed, sometimes the errno names have become wider than the name specified in the .Bl macro. Man pages can also specify: .Bl -tag -width Er Which will reserve enough space for the errno name based on what width the Er macro specifies. Right now it doesn't allocate enough width to contain our largest errno's. I propose that we fix mdoc to allocate enough width when the second form is specified, and then change all of the man pages to use that format in the ERRORS section. Suggestions/comments/etc welcome. -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Help with exit status in shell script
Hi,
There is a bug in the PicoBSD build shell script in and I have no idea
how to fix it. As a result, build errors are not caught.
It is all to do with Exit Status of programs called from a shell script.
Please help.
The code fragment from /usr/src/release/picobsd/build/build is
./stage1 21 | tee stage1.out
if [ X$? != X0 ] ; then
echo ^G
echo - ERROR in \${i}\ script. Aborting the build process.
exit 10
fi
Build calls Stage1. Stage1 will return with an error code in some cases
and we want to trap this and halt the Build script.
./stage1 21 | tee stage1.out
if [ X$? != X0 ] ; then
Normally, $? will return the Exit Status of the last executed program.
However, due to the pipe through Tee, the Exit Status I get is the
exit status of Tee and not the exit status of the Stage1 script.
I still want to output the stage1 script to screen and a log file.
How can I do this and preserve the exit status for the Build script.
Thanks
Roger
--
Roger Hardiman
ro...@freebsd.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Cheap link (was: Are the ethernet drivers time dependent?)
On Saturday, 28 August 1999 at 2:52:12 -0500, Kris Kirby wrote: Daniel O'Connor wrote: On 28-Aug-99 Kris Kirby wrote: RS232? RS485? VERY cheap and the later is at least moderatly resistant to noise Noise shouldn't be an issue. It's going to be handling clean data. By cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like cutting into. I'm going to be bearing the financial end of this project of mine, so I'm going to save where I can. :-) Well serial ports come free on all new computers ;) You're right, I should have clarifed. I'm looking to break 128K. I don't have any serial ports that I can jumper up to 460 or 230 kbps. Additionally, 256K is a nice round number :-). So what's wrong with PLIP? Last time I used it, I was getting about 50 kB/s out of it. I'm not looking to invest in new hardware, and I can save on a bit of hardware by letting the NIC worry about the link. The NIC also greatly simplies the system. At worst, I'd need a machine with a 3C503 and a NE2000. And then I'll probably use dummynet for bandwidth limiting over the link so it doesn't get flooded. I'm going to be building at least three of these units, assuming I get the technical issues out of the way. So I'm looking at a cheap (hardware and software) way of getting data in and out of a PC with IP support and such. It just makes sense in my POV to use a NIC. It's capable of 10 Mbps and has most of the circuitry for preparing data for transmission on it. If you will, it's a ready to use data pump. I think the technical issues will be your problem. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: Cheap link (was: Are the ethernet drivers time dependent?)
On 28-Aug-99 Greg Lehey wrote: So what's wrong with PLIP? Last time I used it, I was getting about 50 kB/s out of it. PLIP has a terrible CPU/speed ratio.. You have to busy wait while bashing the parallel port which is just yech :( --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgpgYrcq723gK.pgp Description: PGP signature
CVSWEB not happy with $FreeBSD$ change (was $Id$)
Hi, I've just done a commit following peters $Id$ to $FreeBSD$ changes. But CVSWEB is getting things totally wrong. Take a look at this URL, which points to the picoBSD 'build' script http://www.freebsd.org/cgi/cvsweb.cgi/src/release/picobsd/build/build?rev=1.18 The file is version 1.18, comitted by me (roger), but the web page gives the entry for 1.17, committed by Peter A cvs checkout on freefall gives the correct version and correct ID string. But the cvsweb pages is all messed up. Any ideas? Roger To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Cheap link (was: Are the ethernet drivers time dependent?)
Greg Lehey wrote: I'm going to be building at least three of these units, assuming I get the technical issues out of the way. So I'm looking at a cheap (hardware and software) way of getting data in and out of a PC with IP support and such. It just makes sense in my POV to use a NIC. It's capable of 10 Mbps and has most of the circuitry for preparing data for transmission on it. If you will, it's a ready to use data pump. I think the technical issues will be your problem. Well, yeah. :-) High speed FHSS equipment is rather complicated and requires come pretty accurate (TXCO?) signal sources. There are going to be problems. If I can't use a ethernet card, I've got a MCU in mind to do the job. -- Kris Kirby k...@airnet.net --- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Are the ethernet drivers time dependent?
Daniel O'Connor wrote: On 28-Aug-99 Kris Kirby wrote: I'm going to be building at least three of these units, assuming I get the technical issues out of the way. So I'm looking at a cheap (hardware and software) way of getting data in and out of a PC with IP support and such. It just makes sense in my POV to use a NIC. It's capable of 10 Mbps and has most of the circuitry for preparing data for transmission on it. If you will, it's a ready to use data pump. Ahh I see.. So you're basically making a ethernet-radio type of thing? Or actually mangling the card itself? Both. The problem is that you can't cram a signal moving at 10 Mbps through a radio interface designed for 256K, even if it is bandwidth limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow it down by yanking it's 20. MHz crystal oscillator and feeding it a lower speed signal. I'm going to walk them down to see just how far I can go. After all, 2 Mbps isn't bad, it just requires a little more work. -- Kris Kirby k...@airnet.net --- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Are the ethernet drivers time dependent?
On 28-Aug-99 Kris Kirby wrote: Both. The problem is that you can't cram a signal moving at 10 Mbps through a radio interface designed for 256K, even if it is bandwidth limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow it down by yanking it's 20. MHz crystal oscillator and feeding it a lower speed signal. I'm going to walk them down to see just how far I can go. After all, 2 Mbps isn't bad, it just requires a little more work. Ahh eeww :) I hope you have a lot of spare time ;) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgpR88YTe9T4t.pgp Description: PGP signature
Re: Are the ethernet drivers time dependent?
Both. The problem is that you can't cram a signal moving at 10 Mbps through a radio interface designed for 256K, even if it is bandwidth limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow it down by yanking it's 20. MHz crystal oscillator and feeding it a lower speed signal. I'm going to walk them down to see just how far I can go. After all, 2 Mbps isn't bad, it just requires a little more work. The 8390 should be functional down to 1MHz or so, and I don't think that signal is used for any other chip functions. You can take the i82586 a lot slower; I recall several S/HDLC-like cards that used them as USRTs in the hundreds of kilobits per second range. Bearing in mind that both the 8390 and the 82586 were designed back when 10MBps was fast ethernet. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [EuroHaCk] re + init + securelevel-nonsense
~ ~ if anyone ever played with shells, maybe you'd like to have a look on ~ restricted shell, I did for a couple of hours. the only thing I haven't ~ So break out via 'exec bash' ;-) eh?;-) sh on OpenBSD (at least) has quite nice feature to disable exec'ing any stuff which has path specified if shell name matches *r*sh pattern(i.g. it would run passwd but not /usr/bin/passwd etc) so by setting up safe path variable (which is done in my shell) and copying only user-safe proggies into the place would be safe enuff. ~ figured, is how, when spawned process is suspended, I should make shell ~ fell like it received SIGCONT signal.. oh, well, I need to get to my unice ~ bible back again.. :) ~ APUE? ;-) yep. :) ~ Some1 an idea why FreeBSD 3.1. fails to set seclevel back to 0 ~ when sending init signal 15 to get to singleuser-mode? ~ might be bug in code. What would freebsd-hackers say?;-) ~ In openBSD it works fine, but OpenBSD sets seclevel to 1 while boot. ~ On F*BSD i set it by hand. ~ Ahhh...sending 25 times a SIGSYS to init gives kernel-panic. No wonder... eh.. heh :-) ~ + delete /usr/src/sys ~ + disable LKM's ~ + disable bpf ~ + set seclevel to 3 ~ + set up proper fw ~ + disable all accounts and run only httpd or what you need ~ ~ }|-) :-) okay. now that's gotta be beginning of BSD security howto.. ;-) ~ It would be absolutely no fun to go to this machine. securelevel 2: Highly secure mode - same as secure mode, plus disks are always read-only whether mounted or not and the settimeofday(2) system call can only advance the time. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. Because the clock cannot be set back in time, malicious users who have gained root privi- leges are unable to change a file's ctime. uhum.. sounds good ;-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
On Fri, Aug 27, 1999 at 11:23:06AM -0700, Doug wrote: On Fri, 27 Aug 1999, Nate Williams wrote: Sentences are supposed to have two spaces before you start the next sentence. Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. I did this change over on the FDP in the Handbook, thinking it didn't make any difference either. Then I got deluged with e-mail from people telling me that lots of editors use the double space as part of their heuristic to determine where sentences start and end. And I turned it back :-) N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
On Fri, Aug 27, 1999, Doug wrote: -# this file, but rather in /etc/defaults/rc.conf. Please check this file +# this file, but rather in /etc/defaults/rc.conf. Please check that file Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. I've never heard of that. I've always found that two spaces after end-of-sentence punctuation makes things easier to read! (Don't think I don't appreciate this, I just love to nitpick. :) -- |Chris Costello ch...@calldei.com |To iterate is human; to recurse, divine. ` To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
On Fri, Aug 27, 1999, Doug wrote: -# this file, but rather in /etc/defaults/rc.conf. Please check this file +# this file, but rather in /etc/defaults/rc.conf. Please check that file Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. I've never heard of that. I've always found that two spaces after end-of-sentence punctuation makes things easier to read! (Don't think I don't appreciate this, I just love to nitpick. :) I vote for two spaces after the period before the start of a new sentence. Even in the digital age, I've always found that the two spaces make for better reading of text. I think that most of our formatting tools do this too (please don't flame me if I'm wrong :-). -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Help with exit status in shell script
Roger Hardiman wrote in list.freebsd-hackers:
There is a bug in the PicoBSD build shell script in and I have no idea
how to fix it. As a result, build errors are not caught.
It is all to do with Exit Status of programs called from a shell script.
Please help.
The code fragment from /usr/src/release/picobsd/build/build is
./stage1 21 | tee stage1.out
if [ X$? != X0 ] ; then
echo ^G
echo - ERROR in \${i}\ script. Aborting the build process.
exit 10
fi
Build calls Stage1. Stage1 will return with an error code in some cases
and we want to trap this and halt the Build script.
./stage1 21 | tee stage1.out
if [ X$? != X0 ] ; then
Normally, $? will return the Exit Status of the last executed program.
However, due to the pipe through Tee, the Exit Status I get is the
exit status of Tee and not the exit status of the Stage1 script.
I still want to output the stage1 script to screen and a log file.
How can I do this and preserve the exit status for the Build script.
There are several solutions, but all of them are somewhat
ugly...
One approach would be to use a named pipe, run stage1 in the
background and then wait for it, grabbing its exit status:
FIFO=/tmp/`basename $0`.$$.fifo
trap rm -f $FIFO 1 2 15
mkfifo $FIFO
./stage1 $FIFO 21
STAGE1PID=$!
tee $FIFO stage1.out
wait $STAGE1PID
if [ $? != 0 ]; then
...
rm -f $FIFO
Maybe it's possible to open a new shell descriptor (e.g. 3)
instead of a named pipe, but I haven't tried this.
Another way would be to put the exit code into a temporary
file, like this:
trap rm -f stage1.result 1 2 15
(
./stage1 21
echo $? stage1.result
) | tee stage1.out
if [ `cat stage1.result` != 0 ]; then
...
rm -f stage1.result
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:o...@dorifer.heim3.tu-clausthal.de)
In jedem Stück Kohle wartet ein Diamant auf seine Geburt
(Terry Pratchett)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
WaveLan IEE problem
Hello, I wanted to bring everyone up to date on the problems I have been having with the WaveLAN Turbo PC cards. To date I am still reciving the following error after a day or so of use on only the near side of a point to point link. wi0: init failed wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: failed to allocate 1594 bytes on NIC wi0: mgmt. buffer allocation failed wi0: xmit failed wi0: device timeout (hot swaping the card restores its ability to work) The far side of the lynk has only experianced this problem (or any problems) one time in the month or so I have been using it. I have left that side alone which is running on a laptop with a hacked version of PAO. This is what I have done to date in order to try and solve the problem on the near side. 1) I have applied a patch provided by Bill Paul to the PAO version as well as the lastest version of if_wi.c 2) Jim Flowers infromed me that he was having great success running FreeBSD-Stable, I upgraded to STABLE and this got hot swaping working but still hasn't seemed to solve the problem. (at this point I am no longer running the patch from Bill Paul) 3) I started from scratch. I am using a differant computer (old pent-90 which has run a wl0 card for years), I bought a new WaveLAN Turbo card, A new ISA/PCMCIA adaptor, and did a fresh install of FreeBSD-STABLE on a new hard dirve. On the new hard drive I have only modified the following files, /etc/pccard.conf /etc/rc.conf and the kernel config. Below please find a copy of each. Well thats it in a nut shell. Thaks to everyone for helping so far!! Sincerly, RIchard Puga p...@maui.com ---Kernel config--- # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # 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. # # $Id: GENERIC,v 1.143.2.18 1999/08/18 21:35:37 obrien Exp $ machine i386 cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GENERIC maxusers 32 #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, MFS req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS req'ed options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root. CD9660 req'ed options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on wd0 # 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): #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs controller isa0 controller pnp0 #controller eisa0 controller pci0 controller fdc0 at isa? port IO_FD1 bio irq 6 drq 2 disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 options CMD640 # work around CMD640 chip deficiency controller wdc0 at isa? port IO_WD1 bio irq 14 disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? port IO_WD2 bio irq 15 disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device acd0 #IDE CD-ROM device wfd0 #IDE Floppy (e.g. LS-120) # A single entry for any of these controllers (ncr, ahb, ahc) is # sufficient for any number of installed devices. controller ncr0 controller ahb0 controller ahc0 controller isp0 # This controller offers a number of configuration options, too many to # document here - see the LINT file in this directory and look up the # dpt0 entry there for much fuller documentation on this. controller dpt0 controller adv0 at isa? port ? cam irq ? controller adw0 controller bt0 at isa? port ? cam irq ? controller aha0 at isa? port ? cam irq ? controller scbus0 device da0 device sa0 device pass0 device cd0 #Only need one of these, the code dynamically grows
Re: WaveLan IEE problem
To date I am still reciving the following error after a day or so of use on only the near side of a point to point link. wi0: init failed wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: failed to allocate 1594 bytes on NIC wi0: mgmt. buffer allocation failed wi0: xmit failed wi0: device timeout day? for me and a bunch of others it happens immediately. we have never been able to get wlp or wi going since 3.x. randy, running -release+pao To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
On Sat, Aug 28, 1999 at 05:45:05AM -0500, Mike Pritchard wrote: I vote for two spaces after the period before the start of a new sentence. Even in the digital age, I've always found that the two spaces make for better reading of text. I think that most of our formatting tools do this too (please don't flame me if I'm wrong :-). The manpages screw it up sometimes. [It's probably fair to assume you know when they do, but anyways... -- A sentence ends .Ar here . But this new one has a single space preceeding it. -- -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Help with exit status in shell script
Roger Hardiman wrote: Build calls Stage1. Stage1 will return with an error code in some cases and we want to trap this and halt the Build script. ./stage1 21 | tee stage1.out if [ X$? != X0 ] ; then Normally, $? will return the Exit Status of the last executed program. However, due to the pipe through Tee, the Exit Status I get is the exit status of Tee and not the exit status of the Stage1 script. I still want to output the stage1 script to screen and a log file. How can I do this and preserve the exit status for the Build script. There's a bit about this in the Csh Programming Considered Harmful document, showing how easy it is in the Bourne shel: Consider the pipeline: A | B | C You want to know the status of C, well, that's easy: it's in $?, or $status in csh. But if you want it from A, you're out of luck -- if you're in the csh, that is. In the Bourne shell, you can get it, although doing so is a bit tricky. Here's something I had to do where I ran dd's stderr into a grep -v pipe to get rid of the records in/out noise, but had to return the dd's exit status, not the grep's: device=/dev/rmt8 dd_noise='^[0-9]+\+[0-9]+ records (in|out)$' exec 31 status=`((dd if=$device ibs=64k 21 13 3- 4-; echo $? 4) | egrep -v $dd_noise 12 3- 4-) 41` exit $status; See http://www-uxsup.csx.cam.ac.uk/csh.html for the rest. so exec 31 exit_code=`((./stage1 21 13 3- 4-; echo $? 4) | tee stage1.out 12 3- 4-) 41` exec 3- or something, should get it for you. I used `exit_code' rather than `status' because `$status' is read-only in zsh, but that shouldn't be a problem for plain old sh. You'd better add some comments explaining just what it does :-) -- Ben Smithurst| PGP: 0x99392F7D b...@scientia.demon.co.uk | key available from keyservers and | ben+...@scientia.demon.co.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: Re: cvs commit: doc/en/handbook/ports chapter.sgml]
Nik Clayton wrote: +/* Please update doc/en/handbook/ports/chapter.sgml when changing */ #undef __FreeBSD_version #define __FreeBSD_version 48 /* Master, propagated to newvers */ Hang on a second, I spoke too soon. I've just had a look at that file, and I can see no trace of that comment in there. I can't see handbook in /home/ncvs/src/sys/sys/param.h,v either. Or was the point that this coment *should* be added to that file, but hasn't been yet? I was under the impression the comment *had* been committed... It would seem I was wrong. Most of the thread was spent on discussing whether ports was the appropriate place for the documentation or not, and where it should be mentioned if not in ports. You know how people can get sidetracked easily. :-) For that matter, if chapter.sgml still has a log of why the version changed, then I think it would be a good thing to insert the above comment in param.h. I don't recall seeing any objections, though I can imagine some people might think it's not appropriate for the source to refer to an outside documentation such as the handbook. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
On Sat, Aug 28, 1999, Tim Vanderhoek wrote: A sentence ends .Ar here . But this new one has a single space preceeding it. Does adding a space after the `.' at the end of your line help? -- |Chris Costello ch...@calldei.com |**FLASH** Energizer Bunny arrested, charged with battery. `-- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel Merced FreeBSD???
Mark Ovens wrote:
On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote:
A funny thing is that Microsoft is porting essentially a
32-bit version of Windows to Merced. All the programs for
Windows that want to use 64-bit support will have to be
modified because the MS compiler defines both int and long
as 32-bit. On the other hand the Unix compilers (at least
UnixWare and as far as I understood that's the common Unix
convention) provide a mode with 64-bit longs that gives
certain degree of 64-bit awareness just by recompiling.
marder-1:/usr/marko{57}% cat size.c
#include stdio.h
int main (void)
{
printf(short == %d\n, sizeof(short));
printf(int == %d\n, sizeof(int));
printf(long == %d\n, sizeof(long));
printf(long long == %d\n, sizeof(long long));
return(0);
}
^D
marder-1:/usr/marko{57}% cc !$
marder-1:/usr/marko{57}% ./a.out
short == 2
int == 4
long == 4
long long == 8
marder-1:/usr/marko{57}%
And the same is true on SunOS 4.1.x as well (although not 100% sure
about long long).
I was talking about compilers for the 64-bit machines. As far
as I understood to make porting easier the major Unix vendors
have agreed on 2 64-bit modes in addition to the compatibility
32-bit mode:
- 32-bit int, 32-bit long, 64-bit long long, 64-bit pointers
- 32-bit int, 64-bit long, 64-bit long long, 64-bit pointers
While the 64-bit Windows NT has 32-bit int, 32-bit long,
64-bit long long, 32-bit pointers, 64-bit some special
kind of pointers.
Although I may be confusing something.
-SB
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Propose mdoc fix regarding ERRORS section
* Mike Pritchard (m...@mpp.pro-ns.net) [990828 11:44]: Category: docs Synopsis: src/lib/libc/sys/*.2 misc patch pack - first column in most ERROR lists is too narrow. Normalize their width. Right now we have a problem with our on-line man pages. Most were written when the length of errno's were only 6 - 8 characters long. Now we have errno's that can be up to 15 characters long. Many of our man pages have the following mdoc instruction (or something similar) to ensure that the field width for the errno is appropriate: .Bl -tag -width EBADFXXX Most lists do actually. But you already know =) .Bl -tag -width Er Which will reserve enough space for the errno name based on what width the Er macro specifies. Right now it doesn't allocate enough width to contain our largest errno's. I propose that we fix mdoc to allocate enough width when the second form is specified, and then change all of the man pages to use that format in the ERRORS section. I think using -width Er and setting the Er constant to a higher value might be the best thing. Offcourse we need to check all of the manpages in order whether they use -width EBLAHBLAH or -width Er. If you need help, please yell. -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Fame is the perfume of heroic deeds. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Panic in pmap_remove_pages on 4.0-current
Anybody seen this before? I was building gtk12 in /usr/ports which
died with a sig 11. I restarted it and it panic'd sometime later.
Crash and kernel file available on anonymous ftp at
ftp://chaos.stdio.com/pub/crash.
anarchy# gdb -k /var/crash/kernel.0 -c /var/crash/vmcore.0
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-unknown-freebsd...
IdlePTD 3018752
initial pcb at 271c20
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc15d7ff0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc020ff38
stack pointer = 0x10:0xc8d95ef0
frame pointer = 0x10:0xc8d95f00
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 31445 (sh)
interrupt mask = net bio cam
trap number = 12
panic: page fault
syncing disks... 11 done
dumping to dev (13,196609), offset 0
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112
111 110 109 1
08 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87
86 85 84 83
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58
57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30
29 28 27 26 2
5 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:291
291 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:291
#1 0xc0144331 in panic (fmt=0xc02472cf page fault)
at ../../kern/kern_shutdown.c:515
#2 0xc021227a in trap_fatal (frame=0xc8d95eb0, eva=3244130288)
at ../../i386/i386/trap.c:907
#3 0xc0211f2d in trap_pfault (frame=0xc8d95eb0, usermode=0,
eva=3244130288)
at ../../i386/i386/trap.c:800
#4 0xc0211b6f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi
= 0,
tf_esi = -1066564500, tf_ebp = -925278464, tf_isp = -925278500,
tf_ebx = -1066592668, tf_edx = -943206164, tf_ecx = -1050837008,
tf_eax = -1066564500, tf_trapno = 12, tf_err = 2, tf_eip =
-1071579336,
tf_cs = 8, tf_eflags = 66182, tf_esp = -943206272, tf_ss = 0})
at ../../i386/i386/trap.c:426
#5 0xc020ff38 in pmap_remove_pages (pmap=0xc7c7d0e4, sva=0,
eva=3217022976)
at ../../i386/i386/pmap.c:2981
#6 0xc013dcdf in exit1 (p=0xc8d89ba0, rv=0) at ../../kern/kern_exit.c:219
#7 0xc013daf0 in exit1 (p=0xc8d89ba0, rv=17) at
../../kern/kern_exit.c:106
#8 0xc02124be in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 1, tf_esi = -1077945183, tf_ebp = -1077948100,
tf_isp = -925278252, tf_ebx = 1, tf_edx = 0, tf_ecx = 135127040,
tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 134653456, tf_cs =
31,
tf_eflags = 642, tf_esp = -1077948180, tf_ss = 47})
at ../../i386/i386/trap.c:1056
#9 0xc02041a6 in Xint0x80_syscall ()
Cannot access memory at address 0xbfbfd13c.
(kgdb)
Larry Lile
l...@stdio.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Help with exit status in shell script
Hi, There is a bug in the PicoBSD build shell script in and I have no idea how to fix it. As a result, build errors are not caught. It is all to do with Exit Status of programs called from a shell script. Please help. The code fragment from /usr/src/release/picobsd/build/build is ./stage1 21 | tee stage1.out given that there is, in the same script, a fail procedure to handle such cases, i believe you could do something like (./stage1 21 || fail $? stage1_failed ) | tee stage1.out (where the $? has nothing special, just that the fail procedre expects the errcode as first argument). If it turns out to be problematic, for 3.3R you could as well remove the tee, after all it was just there for debugging. cheers luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Should cam_imask be part of bio_imask ?
I'm trying to track down some VFS/BIO corruption on an NFS server being tested under heavy loads and noticed that my SCSI interrupts do not appear to be blocked by splbio(). (The adaptec's are on irq 5 and irq 12) (kgdb) print bio_imask $1 = 0x40080040 (kgdb) print cam_imask $2 = 0x400c1020 (kgdb) This doesn't sound right to me. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Should cam_imask be part of bio_imask ?
Isn't all the work in CAM done at splsoftcam? (or am I thinking of old code) It starts off an ISR similar to the netisr doesn't it? On Sat, 28 Aug 1999, Matthew Dillon wrote: I'm trying to track down some VFS/BIO corruption on an NFS server being tested under heavy loads and noticed that my SCSI interrupts do not appear to be blocked by splbio(). (The adaptec's are on irq 5 and irq 12) (kgdb) print bio_imask $1 = 0x40080040 (kgdb) print cam_imask $2 = 0x400c1020 (kgdb) This doesn't sound right to me. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
:I've never heard of that. I've always found that two spaces : after end-of-sentence punctuation makes things easier to read! : :I vote for two spaces after the period before the start of a new sentence. :Even in the digital age, I've always found that the two spaces make :for better reading of text. I think that most of our formatting :tools do this too (please don't flame me if I'm wrong :-). : :-Mike :-- :Mike Pritchard :m...@freebsd.org or m...@mpp.pro-ns.net I guess they don't teach manual typewriting classes any more :-) It *had* to be two spaces or you got seriously marked down! Two spaces has been burned into my brain since high school! (I wonder if I can sue?) GRIN. For proof, just look at all the postings I've ever made to these lists. I'm not nitpicking... I couldn't care less what other people do. But I think it's an amusing generational effect. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Should cam_imask be part of bio_imask ?
Isn't all the work in CAM done at splsoftcam? Not all. There's completions done at splcam. I've had some worries and concerns about this, but (wince) I really have to admit that the ins and outs of the cam code often escape me, and they're documented only in the DNA of certain human subspecies that reside in Colorado. (or am I thinking of old code) It starts off an ISR similar to the netisr doesn't it? On Sat, 28 Aug 1999, Matthew Dillon wrote: I'm trying to track down some VFS/BIO corruption on an NFS server being tested under heavy loads and noticed that my SCSI interrupts do not appear to be blocked by splbio(). (The adaptec's are on irq 5 and irq 12) (kgdb) print bio_imask $1 = 0x40080040 (kgdb) print cam_imask $2 = 0x400c1020 (kgdb) This doesn't sound right to me. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Should cam_imask be part of bio_imask ?
: Isn't all the work in CAM done at splsoftcam? : :Not all. There's completions done at splcam. I've had some worries and :concerns about this, but (wince) I really have to admit that the ins and :outs of the cam code often escape me, and they're documented only in the :DNA of certain human subspecies that reside in Colorado. Hmm, ok. Shoot. This is what I'm getting. If I have an NFS server and client running CURRENT, and (from the client) I copy the CVS repository from the server to the client, and then diff them, I get little discrepancies. An example is included below. *** /FreeBSD/FreeBSD-CVS/src/sys/pci/ncr.c,vFri Aug 27 17:51:03 1999 --- /home/ncvs/src/sys/pci/ncr.c,v Fri Aug 27 17:51:03 1999 *** *** 12211,12217 d55 1 d1345 1 a1345 1 ! \nhis product 1.112 1997/11/07 09:20:56 phk Exp $\n; @ --- 12211,12217 d55 1 d1345 1 a1345 1 ! \n$Id: ncr.c,v 1.112 1997/11/07 09:20:56 phk Exp $\n; @ I'm still experimenting trying to focus in on where the problem is. It is a very weird problem. Sometimes the errors are small, sometimes who pages are wrong. The scary part is that they are wrong in the server's cache! If I catch the error quickly enough and cat the file on the server, the error shows up on the server! If I then, on the server, eat up memory to flush the caches and then cat the file again, the error is gone again. I'm going to try changing it over from an NFSv3 to an NFSv2 mount to see if that does anything. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Should cam_imask be part of bio_imask ?
I strongly doubt that this is a CAM isr problem- the error pattern isn't
entirely clear from what you said, but it looks more like a FIFO or CACHE
LINE sized type of problem- it looks to be 16 bytes, but not a short
count. Because this isn't one of the wacky systems I spent most of my
career on at Sun where the first and usual suspect was a system memory
cache line because IO wasn't cache coherent on Suns between the Sun
3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a
FIFO somewhere in the I/O movement path.
Justin- any changes lately where flushing a FIFO in the Adaptec at the end
of tranfer might have been spoodged?
-matt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Should cam_imask be part of bio_imask ?
:I strongly doubt that this is a CAM isr problem- the error pattern isn't
:entirely clear from what you said, but it looks more like a FIFO or CACHE
:LINE sized type of problem- it looks to be 16 bytes, but not a short
:count. Because this isn't one of the wacky systems I spent most of my
:career on at Sun where the first and usual suspect was a system memory
:cache line because IO wasn't cache coherent on Suns between the Sun
:3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a
:FIFO somewhere in the I/O movement path.
:
:Justin- any changes lately where flushing a FIFO in the Adaptec at the end
:of tranfer might have been spoodged?
:
:-matt
The problem is definitely aligned in some way. Here's a diff of
a hexdump of one error. Sometimes I lose a whole page, sometimes two
pages, sometimes 16 bytes, but the error is always page aligned.
1536c1536
0005ff0 2033 3434 3434 7c20 207c 3030 3030
---
0005ff0 7365 3d20 3120 093b 2309 6720 6f6c 6162
A cache-line problem would fit the symptoms. I know it isn't the
hardware... this 1xCPU PPro/200 system has been with me for several
years and this test didn't fail like this a month ago. When I updated
the machine last (unfortunately w/ about a month's worth of changes),
my buildworlds started failing with odd errors.
I then switched away from the failing buildworlds (which take an hour)
and started doing cp -r's and then diff -r's (takes only 20 min), and as
you can see I'm still seeing the problem.
Maybe this is DMA related. Perhaps the cache is not getting cleared?
Maybe an MMU optimization someone threw in recently?
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Should cam_imask be part of bio_imask ?
:I strongly doubt that this is a CAM isr problem- the error pattern isn't
:entirely clear from what you said, but it looks more like a FIFO or CACHE
:LINE sized type of problem- it looks to be 16 bytes, but not a short
:count. Because this isn't one of the wacky systems I spent most of my
:career on at Sun where the first and usual suspect was a system memory
:cache line because IO wasn't cache coherent on Suns between the Sun
:3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a
:FIFO somewhere in the I/O movement path.
:
:Justin- any changes lately where flushing a FIFO in the Adaptec at the end
:of tranfer might have been spoodged?
:
:-matt
The problem is definitely aligned in some way. Here's a diff of
a hexdump of one error. Sometimes I lose a whole page, sometimes two
pages, sometimes 16 bytes, but the error is always page aligned.
1536c1536
0005ff0 2033 3434 3434 7c20 207c 3030 3030
---
0005ff0 7365 3d20 3120 093b 2309 6720 6f6c 6162
A cache-line problem would fit the symptoms. I know it isn't the
hardware... this 1xCPU PPro/200 system has been with me for several
years and this test didn't fail like this a month ago. When I updated
the machine last (unfortunately w/ about a month's worth of changes),
my buildworlds started failing with odd errors.
I then switched away from the failing buildworlds (which take an hour)
and started doing cp -r's and then diff -r's (takes only 20 min), and as
you can see I'm still seeing the problem.
Maybe this is DMA related. Perhaps the cache is not getting cleared?
Maybe an MMU optimization someone threw in recently?
That's possible too- I'll admit I'm a bit hazy on i386 specifics- it's
always been a just works wrt I/O so for all I know there's a required
i/o flush command when you switch mappings. Gawd I hate these kind of
problems.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Should cam_imask be part of bio_imask ?
I strongly doubt that this is a CAM isr problem- the error pattern isn't
entirely clear from what you said, but it looks more like a FIFO or CACHE
LINE sized type of problem- it looks to be 16 bytes, but not a short
count. Because this isn't one of the wacky systems I spent most of my
career on at Sun where the first and usual suspect was a system memory
cache line because IO wasn't cache coherent on Suns between the Sun
3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a
FIFO somewhere in the I/O movement path.
Justin- any changes lately where flushing a FIFO in the Adaptec at the end
of tranfer might have been spoodged?
If you happen to be using an Adaptec SCSI controller on the server,
check your PCI bus latency setting. We've seen several reports now of
this sort of stuff getting corrupted as a side-effect of the Adaptec
parts being arbitrated off the bus too quickly. If you're doing lots
of network traffic, the chances are a lot better that you'll hit this.
32 is a value that seems to cause problems; try 80 or so.
--
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ msm...@freebsd.org
\\-- Joseph Merrick \\ msm...@cdrom.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Its about that time of year again. (FreeBSD MCA)
On Sat, 28 Aug 1999, Andy Farkas wrote: I have a truckload of MCA cards - scsi controllers (ibm, adaptec, buslogic, pro-comm), ethernet (ne2000, 3com), memory boards (ibm, other), serial controllers, XGA-2 I'll try and give 'em all a go... If you've got an adaptec 1640, please try http://www.jurai.net/~winter/mca/aha_mca.c Set your DMA channel to something under 7 though as I've not quite figured out a good way to intercept the resource manager calls for channels above 7. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: locking revisited
As a result, I argue that we should implement locking. The questions are: how? I'd suggest three methods which can be individually enabled via sysctls: - System V style. We need this for compatibility with System V. The choice of mandatory or advisory locking depends on the file permissions. - Only mandatory locking. fcntl works as before, but locks are always mandatory, not advisory. I'm sure that this won't be popular, at least initially, but if you don't like it, you don't have to use it.y - Via separate calls to fcntl. fcntl currently has the following command values: #define F_DUPFD 0 /* duplicate file descriptor */ #define F_GETFD 1 /* get file descriptor flags */ #define F_SETFD 2 /* set file descriptor flags */ #define F_GETFL 3 /* get file status flags */ #define F_SETFL 4 /* set file status flags */ #define F_GETOWN5 /* get SIGIO/SIGURG proc/pgrp */ #defineF_SETOWN 6 /* set SIGIO/SIGURG proc/pgrp */ #define F_GETLK 7 /* get record locking information */ #define F_SETLK 8 /* set record locking information */ #define F_SETLKW9 /* F_SETLK; wait if blocked */ We could add a F_SETMANDLOCK or some such. Any thoughts? (I'm following up only on -hackers because I personally hate discussions in -commit.) Yes - 1. Isn't vinum a device? Isn't this file-level locking irrelevant? Shouldn't all locking for maintenance be done at the device level? 2. I'll bet there are some standards, at least in development. Have you done a few searches? I have other opinions, some that I hold strongly, but since they have to do with lack of definition of boundary conditions then I won't bring them up until (2.) is answered. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Should cam_imask be part of bio_imask ?
Oh, Tor didn't Cc hackers. Tor suggested adding the CACHETHEN bit back in the adaptec controller, undoing part of Justin's commit on the 15th (see the commitlogs for sys and search for 'CACHETHEN'). This fixed the problem! Ah, sunshine here I come! -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Panic in pmap_remove_pages on 4.0-current
This exact problem came up last month. pmap_remove_pages is tripping over a corrupted page table entry (pte). Unfortunately, by the time the panic occurs, pmap_remove_pages has overwritten the corrupted pte with zero. Earlier this month, I added a KASSERT to detect this problem (and panic) before the corrupted pte is overwritten. This KASSERT seems to be missing from your kernel. Could you turn on assertion checking in your kernel configuration and/or update to a newer kernel. Alan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
Nik Clayton wrote: On Fri, Aug 27, 1999 at 11:23:06AM -0700, Doug wrote: On Fri, 27 Aug 1999, Nate Williams wrote: Sentences are supposed to have two spaces before you start the next sentence. Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. I did this change over on the FDP in the Handbook, thinking it didn't make any difference either. Then I got deluged with e-mail from people telling me that lots of editors use the double space as part of their heuristic to determine where sentences start and end. And I turned it back :-) Okey dokey, I can take a hint. :) Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Are the ethernet drivers time dependent?
On Sat, 28 Aug 1999, Kris Kirby wrote: Both. The problem is that you can't cram a signal moving at 10 Mbps through a radio interface designed for 256K, even if it is bandwidth limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow it down by yanking it's 20. MHz crystal oscillator and feeding it a lower speed signal. I'm going to walk them down to see just how far I can go. After all, 2 Mbps isn't bad, it just requires a little more work. What about ARCnet? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
Matthew Dillon wrote: I guess they don't teach manual typewriting classes any more :-) Actually I took that class in Jr. High School, way back in '77. It was the only good advice my Jr. High guidance counselor gave me. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
Today Doug wrote: Matthew Dillon wrote: I guess they don't teach manual typewriting classes any more :-) Actually I took that class in Jr. High School, way back in '77. It was the only good advice my Jr. High guidance counselor gave me. Doug When I was in 8th grade (1964-65) you passed typing or you didn't go on to 9th grade, it was part of the district's required curriculum. I had a friend that ended up in summer school just to take typing. A single space after a period counted as two or three incorrect characters as I recall. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
Cleaned up this post a little for the final (?) version of rc.diff. Back
by popular demand, double spaces after the periods! Well, partly by popular
demand and partly because I think it bouys my argument for a space after
the case options. :) Note the changed URL for the real file. Without
further comment this is the final verion of the rc file diff, but I will
submit it along with the rest when I'm done.
Greetings,
As previously discussed, here is a first draft of the rc* script
mods. I
consider the first step in this process to be Jordan's cleanup of the
variable syntax. This is step 2, which most notably converts test's dealing
with variables to case wherever possible. It also does the following.
1. -f - -r wherever it makes sense
2. value ) instead of value) for case statements
3. All cases of [, test, ; then, etc. converted to:
if [ blah ]; then
4. Made
# Comment
#
commands
more consistent
5. Stripped whitespace off the end of a few lines
6. Tuned up a few of the comments in the file, as well as error output. I
also was more rigorous about making whitespace consisten on this pass.
Removing double spaces, converting spaces to tabs, etc.
The attached diff is to rc, and was generated with -u. You can view
the actual file at http://gorean.org/rcfiles/rc. I would appreciate y'all
reviewing these changes for style, substance, or anything else relevant to
the matter at hand. My hope is that any modifications can be discussed
prior to my doing the rest of the work, which I plan to tackle this
weekend. There are
also a few questions sprinkled into the file, comments or suggestions on
those
are welcome.
This version of the file is tested lightly, which is to say that I
booted with it after my upgrade to the most recent sources on -current
tonight.
Obviously more rigorous testing will be necessary before this gets
committed, although the changes are extremely straightforward.
Questions:
1. Under what circumstances would $early_nfs_mounts be set? The only
mention of this variable that I could find is in /etc/rc, and I can't see
where it would be set.
2. Does the following constitute a security hole?
# Make a bounds file for msgs(1) if there isn't one already
# Delete important files with symlink security hole?
#
if [ ! -f /var/msgs/bounds ]; then
echo 0 /var/msgs/bounds
fi
3. Do we want to move to 'logger' instead of echo for the various little
statements in the rc* files during boot? I for one would highly recommend
this change, since it makes remote administration TONS easier. However the
last time it came up I seem to remember it being one of those religious
issues... I see this as step 3. of the project, and will go ahead with it
after step 2. is done if there is no objection.
3. Anything else I should be looking at in this phase of the game?
Doug--- /usr/src/etc/rc Sat Aug 28 13:51:10 1999
+++ rc Sat Aug 28 14:08:25 1999
@@ -8,24 +8,25 @@
# and the console is the controlling terminal.
# Note that almost all the user-configurable behavior is no longer in
-# this file, but rather in /etc/defaults/rc.conf. Please check this file
+# this file, but rather in /etc/defaults/rc.conf. Please check that file
# first before contemplating any changes here.
stty status '^T'
# Set shell to ignore SIGINT (2), but not children;
# shell catches SIGQUIT (3) and returns to single user after fsck.
+#
trap : 2
trap : 3 # shouldn't be needed
-HOME=/; export HOME
+HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
-export PATH
+export HOME PATH
# BOOTP diskless boot. We have to run the rc file early in order to
# retarget various config files.
#
-if [ -f /etc/rc.diskless1 ]; then
+if [ -r /etc/rc.diskless1 ]; then
dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2 /dev/null`
if [ ${dlv:=0} != 0 ]; then
. /etc/rc.diskless1
@@ -34,59 +35,68 @@
# If there is a global system configuration file, suck it in.
#
-if [ -f /etc/defaults/rc.conf ]; then
+if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
+elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
# Configure ccd devices.
-if [ -f /etc/ccd.conf ]; then
+#
+if [ -r /etc/ccd.conf ]; then
ccdconfig -C
fi
-if [ ${start_vinum} = YES ]; then
+case ${start_vinum} in
+[Yy][Ee][Ss] )
vinum start
-elif [ -n ${vinum_drives} ]; then
- vinum read ${vinum_drives}
-fi
+ ;;
+* )
+ if [ -n ${vinum_drives} ]; then
+ vinum read ${vinum_drives}
+ fi
+ ;;
+esac
swapon -a
-if [ $1 = autoboot ]; then
+case $1 in
+autoboot )
echo Automatic reboot in progress...
fsck -p
case $? in
- 0)
+ 0 )
;;
- 2)
+ 2 )
exit 1
;;
- 4)
+ 4 )
reboot
echo reboot failed... help!
exit 1
;;
- 8)
Re: Please review: rc file changes
On Sat, Aug 28, 1999, Tim Vanderhoek wrote: A sentence ends .Ar here . But this new one has a single space preceeding it. Does adding a space after the `.' at the end of your line help? Please, no trailing white space :-)! Seriously, I think that all of the current mdoc macros that allow puncuation characters to be specified screw this up and only add one space. Mdoc should be fixed to add two spaces in this case, and then if the man page author really does only want one space, they can do it with the existing Ns macro (no space). -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
Doug wrote: Okey dokey, I can take a hint. :) Can you take another one, regarding the unnecessary spaces after the values in your cases? i.e., that they should be taken out and shot? :-) -- Ben Smithurst| PGP: 0x99392F7D b...@scientia.demon.co.uk | key available from keyservers and | ben+...@scientia.demon.co.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
Doug wrote in list.freebsd-hackers: 2. value ) instead of value) for case statements Maybe I missed it, but what exactly is the reason for that change? I do not like it, it makes the case lines look strange. And I think there was a policy that style should not be changed if there's no good reason. Apart from that -- Good work! :) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:o...@dorifer.heim3.tu-clausthal.de) In jedem Stück Kohle wartet ein Diamant auf seine Geburt (Terry Pratchett) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Please review: rc file changes
Ben Smithurst wrote: Doug wrote: Okey dokey, I can take a hint. :) Can you take another one, regarding the unnecessary spaces after the values in your cases? i.e., that they should be taken out and shot? :-) *sigh* I am constantly flabbergasted by what people think of as important around here. However, yes, I really can take the hint, and having seen no words of support on this I will revert the change. Hoping I'm running out of nits, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
/usr/src/etc files without $FreeBSD tags
While we're at it: 24$ grep -RL '\$FreeBSD' /usr/src/etc/* /usr/src/etc/amd.map /usr/src/etc/fbtab /usr/src/etc/isdn/isdnd.rates.UK.BT /usr/src/etc/kerberosIV/krb.conf /usr/src/etc/kerberosIV/krb.realms /usr/src/etc/locale.alias /usr/src/etc/master.passwd /usr/src/etc/minfree /usr/src/etc/motd /usr/src/etc/namedb/named.root /usr/src/etc/rc.diskless1 /usr/src/etc/rc.diskless2 /usr/src/etc/sendmail/freebsd.mc /usr/src/etc/termcap.small Having the tags in the files helps mergemaster, if nothing else. :) Thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel Merced FreeBSD???
On Fri, 27 Aug 1999, Thomas David Rivers wrote: First - let me point out that FreeBSD already runs on the Alpha, so there's some 64-bit experience. Very good point, which ought to be brought out more than once, it's good for the rep. And - let me add - Intel has been down this path before (the i860) - and didn't see the success it wanted (although the i860 is popping up in some interesting places now...) I am going to say something controversial here, but I'm interested in the reply When I was in the computer architecture classes, I did a lot of modeling of various kinds of things that could be done to speed up a processor (the least of which is cache memory, but it stands as a good for instance thing here). One thing that impressed me, when doing modelling of multiple different things like speculative execution and the IA64's rumored ability to speculatively execute several different paths of loop, was the extreme difficulty to adequately model how all the different parts work (and mis-work) together. You end up having to really inspect many megabytes of output in detail, just to figure out if one feature worked right in one particular scenario, and I was only doing a relatively basic piece of modelling. Trying to model the IA64 would have been a Manhattan Project sized task. Honestly, I am wondering about Intel and HP's ability to really produce a reliable chip that had as many difficult-to-model features as the IA64 is supposed to have. I think that's the real reason that it's not actually being sampled. Your point on the 860 is very correct, but if they *could* have brought the IA64 out today with the features that they have been promising (at the speed they promised) it would have made the PowerPC and the Alpha look ill, and I *do* think it would have been quite a masterstroke by Intel, merely because the monstrous resources needed for a competitor to do the same would have guaranteed Intel at least a very good running start on the market. This makes me believe, more than ever, that everything that Intel has put out on the IA64 (and, at least in academic circles, that's a whole lot) has been vaporware and FUD. I can't respect them for that. I suppose what this rant is all about is that I'm not convinced Merced is the chip of the future that we all need to be worried about. I'm taking a wait-and-see attitude. [Also, since Microsoft has been working closely with Intel regarding Merced for several years now, and has yet to do anything `serious' - I believe they are taking the same wait-and-see approach. Likely while telling Intel otherwise.] That doesn't mean I think we shouldn't have a FreeBSD port; I would considering buying a Merced box if there was one (although, I don't have an Alpha box, so maybe it would never get past consider.) - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message ---+--- Chuck Robey| Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770| picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---+--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
