Re: Something weird happening w/ SMP -current
It seems Matthew Dillon wrote: Here's some more info. If the dd is stuck and systat -vm 1 is showing no interrupts occuring on, for example, ahc2 (irq17), and I then do something that causes an interrupt to occur on mux (irq19), which I guess is ahc1, ahc2 then starts working... until it gets stuck again, that is. I can also get ahc2 going again by issuing another dd on ahc2. For example: dd if=/dev/rda1d bs=32k of=/dev/null ... let this one run ... ... it gets stuck ... dd if=/dev/rda1d bs=32k of=/dev/null count=1 ... this unsticks the first dd ... ... the first dd runs again ... ... the first dd gets stuck again ... repeat... All I can think of is that something is causing the system to lose an occassional interrupt. There's a race condition somewhere. Ahhh, I see this too, on an ATA only box that is, I loose my network from time to time, especially if there is lots of interrups on another source, it endeeed looks like we are loosing interrupts somewhere. Guess we have to study some of the latest changes more carefully and see went wrong, I'll try to experiment a bit with it -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fetch(1) and realms with whitespace...
On Thu, 1 Jul 1999, Dominic Mitchell wrote:
Is there any way to specify a realm with whitespace to fetch? I've
just had a fun time trying to do:
% export HTTP_AUTH="basic:SunSolve Online:x:y"
% fetch -v http://online.sunsolve.sun.co.uk/whatever
senddoc: cannot authenticate with server
Looking at the code it appears that there isn't a way to escape the
whitespace...
Try the patch I've attached. I haven't tested it except to see that it compiles.
--
Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator
"How Unix vendors can ship ancient shells with no job control and no cursor
editing by default and still wonder why people buy NT is beyond me." - Alan Cox
--
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
**
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
--- http.c.orig Fri Jul 2 04:08:04 1999
+++ http.c Fri Jul 2 04:44:10 1999
@@ -1682,6 +1682,17 @@
return EX_NOPERM;
}
+static inline char *
+unescify(register char *s) {
+ char *o = s;
+
+ for (; *s; s++)
+ if (*s 0)
+ *s = -*s;
+
+ return o;
+}
+
static void
parse_http_auth_env(const char *env, struct http_auth_head *ha_tqh)
{
@@ -1690,7 +1701,15 @@
struct http_auth_method *ham;
nenv = alloca(strlen(env) + 1);
- strcpy(nenv, env);
+ for (p = nenv; *p; env++)
+ if (!*env)
+ *p = '\0';
+ else if (*env != '\\')
+ *p++ = *env;
+ else if (*++env)
+ *p++ = -*env;
+ else
+ *p = '\0';
while ((p = strsep(nenv, " \t")) != 0) {
scheme = strsep(p, ":");
@@ -1707,9 +1726,9 @@
if (ham == 0)
continue;
ha = safe_malloc(sizeof *ha);
- ha-ha_scheme = safe_strdup(scheme);
- ha-ha_realm = safe_strdup(realm);
- ha-ha_params = params ? safe_strdup(params) : 0;
+ ha-ha_scheme = unescify(safe_strdup(scheme));
+ ha-ha_realm = unescify(safe_strdup(realm));
+ ha-ha_params = params ? unescify(safe_strdup(params)) : 0;
ha-ha_ham = ham;
TAILQ_INSERT_TAIL(ha_tqh, ha, ha_link);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
If you are still running current, please cvsup the newest sources. This problem has been solved in the past few days. It showed up on saturday evening after a commit on McKusick and most of the problem area's have been identified and tracked down. There might still be one or two remaining, but these should be very infrequent. Nick On Thu, 12 Aug 1999, Alexander Langer wrote: Thus spake Matthew Jacob ([EMAIL PROTECTED]): panic: lockmgr: pid 3344, not exclusive lock holder 3341 unlocking I got this very often the last days, too. Actually I try do downgrade to 3.2, because my machines reboots 3 times a day because of either this error or other things. -CURRENT actually is VERY unstable here. Alex -- ** I doubt, therefore I might be. ** *** Send email to [EMAIL PROTECTED] to get PGP-Key *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
interesting. i thought this was a netscape issue. In reply: If you are still running current, please cvsup the newest sources. This problem has been solved in the past few days. It showed up on saturday evening after a commit on McKusick and most of the problem area's have been identified and tracked down. There might still be one or two remaining, but these should be very infrequent. Nick On Thu, 12 Aug 1999, Alexander Langer wrote: Thus spake Matthew Jacob ([EMAIL PROTECTED]): panic: lockmgr: pid 3344, not exclusive lock holder 3341 unlocking I got this very often the last days, too. Actually I try do downgrade to 3.2, because my machines reboots 3 times a day because of either this error or other things. -CURRENT actually is VERY unstable here. Alex -- ** I doubt, therefore I might be. ** *** Send email to [EMAIL PROTECTED] to get PGP-Key *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- Inet: [EMAIL PROTECTED]AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Stuck in objtrm
I have an old 486 here that I thrash to death occasionally. Well, at least I try to get it to page to death. I started a make world last week and forgot about it. Today I noticed that it's been stuck for most of the week. Almost everything is fine, but one cc1 process is stuck in "objtrm". Oh, and I hung a "cat /proc/31624/map", too, trying to get some details (now stuck in "thrd_sleep"). So, am I just tripping over some old long-fixed bug? Or is this a new one worth investigating? The kernel is from 1999/06/16 (just before the vfs_cluster.c commit). Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
Thus spake Nick Hibma ([EMAIL PROTECTED]): Hello again! If you are still running current, please cvsup the newest sources. This problem has been solved in the past few days. It showed up on saturday evening after a commit on McKusick and most of the problem area's have been identified and tracked down. The kernel that made the problem is 2 days old. (From Wednesday). Actually, I even can´t compile a new kernel/world, cause it reboots and hangs all the time. Nice. I´ll try further Alex -- ** I doubt, therefore I might be. ** *** Send email to [EMAIL PROTECTED] to get PGP-Key *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
On 02-Jul-99 Alexander Langer wrote: Thus spake Nick Hibma ([EMAIL PROTECTED]): Hello again! If you are still running current, please cvsup the newest sources. This problem has been solved in the past few days. It showed up on saturday evening after a commit on McKusick and most of the problem area's have been identified and tracked down. The kernel that made the problem is 2 days old. (From Wednesday). Actually, I even can´t compile a new kernel/world, cause it reboots and hangs all the time. Nice. I´ll try further Alex -- ** I doubt, therefore I might be. ** *** Send email to [EMAIL PROTECTED] to get PGP-Key *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- boot with "kernel.old" and try again. Werner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
The kernel that made the problem is 2 days old. (From Wednesday). Actually, I even can´t compile a new kernel/world, cause it reboots and hangs all the time. Welcome to -current. Time to learn about keeping a working kernel around at all times. -- \\ 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-current" in the body of the message
Re: this of interest to anyone?
Mike Smith wrote: The kernel that made the problem is 2 days old. (From Wednesday). Actually, I even can´t compile a new kernel/world, cause it reboots and hangs all the time. Welcome to -current. Time to learn about keeping a working kernel around at all times. I'll reiterate that. I'm sorry you're having trouble, but this is the very reason why we scream out very loudly and clearly that current is for developers and people who are prepared to live on the bleeding edge and know how to deal with problems or back out when they run into trouble. A few key suggestions for people still along for the ride: 1: When you've got a good running kernel that you're happy with, do yourself a big favour and copy it from /kernel to /kernel.ok or something like that. So, when you manage to get a bad /kernel and /kernel.old, you've still got a fallback that doesn't mean resorting to a fixit disk boot. 2: at least try and keep tabs on the current mailing list. Even if you don't pay a lot of attention, look for 'HEADS_UP' warnings and people having trouble. It's always a good idea to to a skim before a kernel rebuild or make world. 3: Always keep tabs on your cvsup log. If you see a lot of commits to the kernel (src/sys), make *sure* you're up to date on current mail. It often pays to let the dust settle. This doesn't mean it's OK for committers to screw things up for fun, but we're only human. We do try and keep it in fairly good condition (remember, the developers depend on it working for development), but mistakes happen.. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
There might still be one or two remaining, but these should be very infrequent. The panice happened during make world with two setiathome clients. Is this a new one or one known to be fixed? Thanks PS: June 30 kernel does not have this problem so far. Tammy Stack trace and dmesg follows: poko# gdb -k kernel.3 vmcore.3 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"... (no debugging symbols found)... SMP 2 cpus IdlePTD 3223552 initial pcb at 29bac0 panicstr: from debugger panic messages: --- panic: lockmgr: pid 12933, not exclusive lock holder 12948 unlocking mp_lock = 0001; cpuid = 0; lapic.id = panic: from debugger mp_lock = 0002; cpuid = 0; lapic.id = boot() called on cpu#0 dumping to dev (4,131073), offset 262144 dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 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 25 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 0xc01538fc in boot () (kgdb) where #0 0xc01538fc in boot () #1 0xc0153b7d in panic () #2 0xc012d7c1 in db_panic () #3 0xc012d761 in db_command () #4 0xc012d826 in db_command_loop () #5 0xc012f987 in db_trap () #6 0xc0216d16 in kdb_trap () #7 0xc022c48c in trap () #8 0xc0216f9b in Debugger () #9 0xc0153b74 in panic () #10 0xc014f4d4 in lockmgr () #11 0xc0201cca in relpbuf () #12 0xc01f6a70 in swp_pager_async_iodone () #13 0xc0174633 in biodone () #14 0xc0125c9d in dadone () #15 0xc0121973 in camisr () #16 0xc0121785 in swi_cambio () #17 0xc021c61e in doreti_swi () #18 0x80828fb in ?? () #19 0x805e004 in ?? () #20 0x805bc1e in ?? () #21 0x805c492 in ?? () #22 0x805c373 in ?? () #23 0x80490ff in ?? () ---Type return to continue, or q return to quit--- #24 0x8084e3e in ?? () #25 0x80878b9 in ?? () #26 0x80480e9 in ?? () (kgdb) quit And dmesg output from a new kernel which survived make world: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #21: Wed Jun 30 21:38:50 PDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/POKO Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping=7 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 134217728 (131072K bytes) avail memory = 127401984 (124416K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc0301000. Pentium Pro MTRR support enabled, default memory type is uncacheable ccd0-3: Concatenated disk drivers Probing for PnP devices: CSN 1 Vendor ID: CSC0b35 [0x350b630e] Serial 0x Comp ID: @@@ [0x] npx0: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Intel 82440FX (Natoma) PCI and memory controller at device 0.0 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 18 at device 6.0 on pci0 fxp0: Ethernet address 00:a0:c9:55:32:47 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 ide_pci0: Intel PIIX3 Bus-master IDE controller at device 7.1 on pci0 chip1: Intel 82371SB (PIIX3) USB controller irq 10 at device 7.2 on pci0 ahc0: Adaptec aic7880 Ultra SCSI adapter irq 17 at device 9.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga-pci0: Matrox MGA 1024SG/1064SG/1164SG graphics accelerator irq 16 at device 11.0 on pci0 isa0: ISA bus on motherboard fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive at fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus 0 lpt0: generic
Re: this of interest to anyone?
Matthew Dillon wrote: :This doesn't mean it's OK for committers to screw things up for fun, but :we're only human. We do try and keep it in fairly good condition :(remember, the developers depend on it working for development), but :mistakes happen.. : :Cheers, :-Peter Hey, I just had a thought... and a question. When we are using cvsup to keep a local CVS reposity in sync, can we tag our local CVS resposity without cvsup deleting the tags? -Matt Yes... And you can even branch the local cvs repo and have cvsup work around it.. The trick is to have a non conflicting magic branch number. Try setting CVS_LOCAL_BRANCH_NUM=1000 or so in the environment and do a tag -b. If I remember correctly, you need to disable the 'delete' mode. Hmm: delete The presence of this keyword gives cvsup permission to delete files. If it is missing, no files will be deleted. The presence of the delete keyword puts cvsup into so-called exact mode. In exact mode, CVSup does its best to make the client's files correspond to those on the server. This in- cludes deleting individual deltas and symbolic tags from RCS files, as well as deleting entire files. In exact mode, CVSup verifies every edited file with a checksum, to ensure that the edits have produced a file identical to the master copy on the server. If the checksum test fails for a file, then CVSup falls back upon transferring the entire file. I recall testing this when John was first working on cvsup (that's where the CVS_LOCAL_BRANCH_NUM hack came from :-), and it worked then. I don't know how well (or if) it works now. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
What makes you think that? interesting. i thought this was a netscape issue. In reply: If you are still running current, please cvsup the newest sources. This problem has been solved in the past few days. It showed up on saturday evening after a commit on McKusick and most of the problem area's have been identified and tracked down. There might still be one or two remaining, but these should be very infrequent. Nick On Thu, 12 Aug 1999, Alexander Langer wrote: Thus spake Matthew Jacob ([EMAIL PROTECTED]): panic: lockmgr: pid 3344, not exclusive lock holder 3341 unlocking I got this very often the last days, too. Actually I try do downgrade to 3.2, because my machines reboots 3 times a day because of either this error or other things. -CURRENT actually is VERY unstable here. Alex -- ** I doubt, therefore I might be. ** *** Send email to [EMAIL PROTECTED] to get PGP-Key *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- Inet: [EMAIL PROTECTED]AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld fails in sbin/vinum
Hi When trying to build a newly updated world I get the following error, which I belive was introduced in the latest commit by grog. The case may be that vext.h did not get commited. (eg. I think "extern int stats" should be "extern int sflag" now) /K === sbin/vinum cc -O -pipe -I/usr/src/sbin/vinum/../../sys -g -Wall -DVINUMDEBUG -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sbin/vinum/v.c cc -O -pipe -I/usr/src/sbin/vinum/../../sys -g -Wall -DVINUMDEBUG -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sbin/vinum/list.c cc -O -pipe -I/usr/src/sbin/vinum/../../sys -g -Wall -DVINUMDEBUG -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sbin/vinum/../../sys/dev/vinum/v inumparser.c cc -O -pipe -I/usr/src/sbin/vinum/../../sys -g -Wall -DVINUMDEBUG -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sbin/vinum/../../sys/dev/vinum/v inumutil.c /usr/src/sbin/vinum/list.c: In function `vinum_list': /usr/src/sbin/vinum/list.c:87: `sflag' undeclared (first use in this function) /usr/src/sbin/vinum/list.c:87: (Each undeclared identifier is reported only once /usr/src/sbin/vinum/list.c:87: for each function it appears in.) /usr/src/sbin/vinum/list.c: In function `vinum_ldi': /usr/src/sbin/vinum/list.c:181: `sflag' undeclared (first use in this function) /usr/src/sbin/vinum/list.c: In function `vinum_lvi': /usr/src/sbin/vinum/list.c:273: `sflag' undeclared (first use in this function) cc -O -pipe -I/usr/src/sbin/vinum/../../sys -g -Wall -DVINUMDEBUG -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sbin/vinum/commands.c /usr/src/sbin/vinum/v.c:263: `vinum_concat' undeclared here (not in a function) /usr/src/sbin/vinum/v.c:263: initializer element for `funkeys[26].fun' is not constant /usr/src/sbin/vinum/v.c:264: `vinum_stripe' undeclared here (not in a function) /usr/src/sbin/vinum/v.c:264: initializer element for `funkeys[27].fun' is not constant /usr/src/sbin/vinum/v.c:265: `vinum_mirror' undeclared here (not in a function) /usr/src/sbin/vinum/v.c:265: initializer element for `funkeys[28].fun' is not constant gzip -cn /usr/src/sbin/vinum/vinum.8 vinum.8.gz /usr/src/sbin/vinum/list.c: In function `vinum_lpi': /usr/src/sbin/vinum/list.c:392: `sflag' undeclared (first use in this function) /usr/src/sbin/vinum/list.c: In function `vinum_lsi': /usr/src/sbin/vinum/list.c:545: `sflag' undeclared (first use in this function) /usr/src/sbin/vinum/list.c: In function `listconfig': /usr/src/sbin/vinum/list.c:627: `sflag' undeclared (first use in this function) *** Error code 1 *** Error code 1 /usr/src/sbin/vinum/commands.c: In function `genvolname': /usr/src/sbin/vinum/commands.c:1208: `objectname' undeclared (first use in this function) /usr/src/sbin/vinum/commands.c:1208: (Each undeclared identifier is reported only once /usr/src/sbin/vinum/commands.c:1208: for each function it appears in.) /usr/src/sbin/vinum/commands.c: In function `vinum_concat': /usr/src/sbin/vinum/commands.c:1292: `objectname' undeclared (first use in this function) /usr/src/sbin/vinum/commands.c:1331: warning: implicit declaration of function `find_drive_by_devname' /usr/src/sbin/vinum/commands.c:1331: warning: assignment makes pointer from integer without a cast /usr/src/sbin/vinum/commands.c: In function `vinum_stripe': /usr/src/sbin/vinum/commands.c:1406: `objectname' undeclared (first use in this function) /usr/src/sbin/vinum/commands.c:1409: warning: assignment makes pointer from integer without a cast /usr/src/sbin/vinum/commands.c:1425: warning: implicit declaration of function `min' /usr/src/sbin/vinum/commands.c:1466: warning: assignment makes pointer from integer without a cast /usr/src/sbin/vinum/commands.c: In function `vinum_mirror': /usr/src/sbin/vinum/commands.c:1541: `sflag' undeclared (first use in this function) /usr/src/sbin/vinum/commands.c:1563: `objectname' undeclared (first use in this function) /usr/src/sbin/vinum/commands.c:1566: warning: assignment makes pointer from integer without a cast /usr/src/sbin/vinum/commands.c:1635: warning: assignment makes pointer from integer without a cast *** Error code 1 3 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails in sbin/vinum
[Format recovered--see http://www.lemis.com/email/email-format.html] On Friday, 2 July 1999 at 20:04:49 +0200, Johan Karlsson wrote: Hi When trying to build a newly updated world I get the following error, which I belive was introduced in the latest commit by grog. The case may be that vext.h did not get commited. Indeed, that was the problem. Ugh. Pass me the pointy hat, please. (eg. I think "extern int stats" should be "extern int sflag" now) That's one of them. There are others. On Friday, 2 July 1999 at 11:05:16 -0700, Doug wrote: I consistently get the following during a 'make world' on the most recent -current: === sbin/vinum cc -O -pipe -I/usr/src/sbin/vinum/../../sys -g -Wall -DVINUMDEBUG -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sbin/vinum/v.c That's another. On Friday, 2 July 1999 at 15:22:27 -0400, Brian F. Feldman wrote: Here's the fix. I'm sure it's not absolutely the same as what Greg will have, but if anyone wants to commit it, it will fix world. Well, yes, but the result won't work. The sflag variable is what used to be called stats. But thanks for jumping in while I was asleep. 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-current" in the body of the message
Re: Fixing other people's code (was: world broken in vinum (PATCH))
Let me add to this: opinion: If it's really blocking folks because things don't compile, it is always acceptable to do what you need to do- the tree should always compile even if -current. If the system doesn't boot because of change, then that's an obvious one too. If things work differently or not as well, but things are more or less working, it's not an emergency, so leave it for the author to fix ...always modulo a short delay (call it a couple of hours) after reporting the problem... after all, you don't *know* that the update isn't finished and that other things are coming down the pipe... but a couple of hours leaves really the most reasonable time for an integration to complete and the author to have had lunch in between. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing other people's code (was: world broken in vinum (PATCH))
On Fri, 2 Jul 1999, Matthew Jacob wrote: Let me add to this: opinion: If it's really blocking folks because things don't compile, it is always acceptable to do what you need to do- the tree should always compile even if -current. If the system doesn't boot because of change, then that's an obvious one too. If things work differently or not as well, but things are more or less working, it's not an emergency, so leave it for the author to fix ...always modulo a short delay (call it a couple of hours) after reporting the problem... after all, you don't *know* that the update isn't finished and that other things are coming down the pipe... but a couple of hours leaves really the most reasonable time for an integration to complete and the author to have had lunch in between. I worded my original post wrong; my change did fix world. Your second point (the "wait and see" approach) wouldn't apply in this case: Greg was asleep, and world was broken. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Just for the record (was: Re: Fixing other people's code (was: worldbroken in vinum (PATCH)))
For the record, I was correct in the code. Hey, I do have a reputation, albeit not yet much of one! Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ -- Forwarded message -- Date: Sat, 3 Jul 1999 12:37:15 +0930 From: Greg Lehey [EMAIL PROTECTED] To: Brian F. Feldman [EMAIL PROTECTED] Subject: Re: Fixing other people's code (was: world broken in vinum (PATCH)) On Friday, 2 July 1999 at 23:06:17 -0400, Brian F. Feldman wrote: On Sat, 3 Jul 1999, Greg Lehey wrote: On Friday, 2 July 1999 at 22:35:16 -0400, Brian F. Feldman wrote: On Sat, 3 Jul 1999, Greg Lehey wrote: On Saturday, 3 July 1999 at 0:09:53 +, Ben Rosengart wrote: On Sat, 3 Jul 1999, Greg Lehey wrote: Was the fix that wasn't yours correct? No. 'Cause I'd rather have code that doesn't compile than code that compiles but is subtly wrong. Well, you can now have code that compiles and is correct :-) Seriously, the only problem with Brian's fix was that it added a new variable. It would have made the stats list functions not work. I Out of curiousity, what 'exactly' was wrong? I had a flag called 'stats', which was set by the -s flag. When I introduced the 'mirror' command, I used the -s flag to mean "create a striped plex". Obviously, the name 'stats' didn't fit this function, so I changed it to 'sflag'. Your fix introduced an additional flag, which wouldn't have been used. Hmmm, come to think of it, it might have worked anyway... we did have the definition after all. OK, I thought it wouldn't work. Hey, I did what I could do best: try to understand and fix it quickly! I _was_ pretty sure it was right tho :) Right. I didn't check it, since I had the tested version waiting (all night) to be checked in. The changes for min() weren't needed; vext.h had a definition. I guessed that; however, you didn't use max() in the surrounding code, you used a broken-out form of what max() is usually defined to (or MAX() for that matter.) Why be consistent when you can be confusing? Yes, maybe I should reconsider that one. 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-current" in the body of the message
Re: Just for the record (was: Re: Fixing other people's code (was:world broken in vinum (PATCH)))
Sorry about that, Greg; I didn't realize it was a personal message I forwarded. Sorry, everyone else, for that faux pas in public :( Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Just for the record (was: Re: Fixing other people's code (was: world broken in vinum (PATCH)))
On Friday, 2 July 1999 at 23:19:26 -0400, Brian F. Feldman wrote: Sorry about that, Greg; I didn't realize it was a personal message I forwarded. Sorry, everyone else, for that faux pas in public :( I'm not upset. 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-current" in the body of the message
Soft-updates feedback
About a week ago, I've posted a message here and didn't got positive replies. The problem is: when I use soft-updates on IDE disks (disk on primary master, disk on secondary master, CD on primary slave), any active disk-using program (starting Netscape, starting EXMH) causes all other programs literally to stop for several seconds (well, 20-30 seconds is quite often!). Turning soft-updates off causes this nastiness to disappear, but also slows down disk-active processess. Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing other people's code (was: world broken in vinum (PATCH))
If it's really blocking folks because things don't compile, it is always acceptable to do what you need to do- the tree should always compile even if -current. If the system doesn't boot because of change, then that's an obvious one too. If things work differently or not as well, but things are more or less working, it's not an emergency, so leave it for the author to fix ...always modulo a short delay (call it a couple of hours) after reporting the problem... after all, you don't *know* that the update isn't finished and that other things are coming down the pipe... but a couple of hours leaves really the most reasonable time for an integration to complete and the author to have had lunch in between. I worded my original post wrong; my change did fix world. Your second point (the "wait and see" approach) wouldn't apply in this case: Greg was asleep, and world was broken. You have to wait at least a little bit because with CVS there is no atomic update of a set of modules. IF make world is broken, waiting at least a certain period of time and then doing another update is important to ensure that you just simply updated only part of a an active checkin cycle. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soft-updates feedback
while this is happening, what does 'iostat 1' and 'vmstat 1' tell you? On Sat, 3 Jul 1999, Alex Povolotsky wrote: About a week ago, I've posted a message here and didn't got positive replies. The problem is: when I use soft-updates on IDE disks (disk on primary master, disk on secondary master, CD on primary slave), any active disk-using program (starting Netscape, starting EXMH) causes all other programs literally to stop for several seconds (well, 20-30 seconds is quite often!). Turning soft-updates off causes this nastiness to disappear, but also slows down disk-active processess. Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
