Re: 4.2-STABLE broken build? (Recent commit)
Hi I'm on the case. I went to bed straight after the commit. Duncan On 03-Jan-01 Warner Losh wrote: ray was MFC'd earlier today. Looks like a problem. Duncan, I'm sure, will fix it when he realizes what is going on (if he hasn't done so alread). Warner --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: RAID costs (was: Vinum safe to use for raid 0?)
On Tuesday, 2 January 2001 at 23:58:26 -0800, Matt Dillon wrote: Like everything, topologies have their strengths and weaknesses. RAID-5 is excellent for read-centric operations (which large data stores tend to be, I will note) and, as Poul reminded me a few days ago... stripe-sized block-write operations can be made optimal. Well, they can be optimized, which isn't quite the same thing. That's a wish list item for Vinum. Of course, it has to be reliable to be useable, which is really the crux of the current thread. Someone needs to buy Greg some faster machines to play with :-), as the current vinum issues appear to be related to timing. I'm not sure about that, though it's possible. The real issue with my test setup is that the disks I have are all ancient. I'm getting some more modern ones Real Soon Now, but of course the optimum way to solve this particular problem would be if somebody sent me exactly the machine that was having trouble. There are other big differences between software and black-box RAID solutions. For example, what happens when the machine crashes right smack in the middle of a write? Hardware RAID (e.g. RAID-5) solutions have NVRAM to hold the log. Software RAID either has to be extremely careful in the sequencing of the data, play serial number tricks (which is why you sometimes see disks with weird physical sector sizes), or write a separate log and delay the actual disk updates until the log write has been confirmed. Indeed. Vinum cheats a little here, but even then it seem to be too finicky for many people. Theoretically, after a crash you need to synchronize the volumes. I'm thinking of a volume manager logging facility which will keep track of the last n operations. This would enable recovery code to confirm that they had been performed. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
can't build kernel
Hello! Make world pass normal, but then i try build kernel i got this error: === bktr/bktr_mem === coff === fpu === gnufpu === ibcs2 === linprocfs === mly === ray rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include /usr/src/sys/modules/ray/../../dev/ray/if_ray.c /usr/src/sys/modules/ray/../../dev/ray/if_ray.c:268: dev/ray/if_raymib.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/ray. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 -- Yuri Vorobyev [EMAIL PROTECTED] www.yamalinfo.ru+7-34922-47791 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: can't build kernel - if_raymib.h missing
Hi all, I've just added the missing header file to the CVS repository. Please cvsup. Duncan On 03-Jan-01 Yuri Vorobyev wrote: Hello! Make world pass normal, but then i try build kernel i got this error: === bktr/bktr_mem === coff === fpu === gnufpu === ibcs2 === linprocfs === mly === ray rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include /usr/src/sys/modules/ray/../../dev/ray/if_ray.c /usr/src/sys/modules/ray/../../dev/ray/if_ray.c:268: dev/ray/if_raymib.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/ray. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 -- Yuri Vorobyev [EMAIL PROTECTED] www.yamalinfo.ru+7-34922-47791 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Help Update
Hi, Odhiambo Washington wrote: n 2 20:36:57 alouette /kernel: pid 56184 (troff), uid 0: exited on signal 11 (core dumped) Signal 11 usually indicates a hardware problem. Have you added any memory or changed (or overclocked?) your processor since you last did a make world? another possibility would be that something is wrong with your troff binary. You could try to rebuild troff and see if this fixes your problem; to rebuild troff something like cd /usr/src/gnu/usr.bin/groff/troff ; make install should probably work. Wolfgang To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Vinum safe to use for raid 0?
On Tue, Jan 02, 2001 at 11:01:07PM +0100, Thomas Seck wrote: Hi all, sorry if this is OT for -stable, but I followed the discussion about vinum in here and got a bit worried. I am currently deploying a proxy server for our company. It shall use squid on 4.2-STABLE. I would like to put the cache data on a vinum RAID 0, made of three U160 disks. As I understood the discussion so far, there are some unresolved problems with the raid 5 code. Could someone tell me whether I can safely use vinum for building a raid 0 system (despite the fact that the HW may be a point of failure of course)? As far as I'm aware there are no problems using vinum for raid 0. As far as I understand from Greg he's not aware of many people who are having problems with raid 5. As one of the small minority who was having problems I'd advice you to soaktest any vinum raid 5 installation before committing important data to it. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Vinum safe to use for raid 0?
On Wednesday, 3 January 2001 at 10:29:44 +, Josef Karthauser wrote: On Tue, Jan 02, 2001 at 11:01:07PM +0100, Thomas Seck wrote: Hi all, sorry if this is OT for -stable, but I followed the discussion about vinum in here and got a bit worried. I am currently deploying a proxy server for our company. It shall use squid on 4.2-STABLE. I would like to put the cache data on a vinum RAID 0, made of three U160 disks. As I understood the discussion so far, there are some unresolved problems with the raid 5 code. Could someone tell me whether I can safely use vinum for building a raid 0 system (despite the fact that the HW may be a point of failure of course)? As far as I'm aware there are no problems using vinum for raid 0. As far as I understand from Greg he's not aware of many people who are having problems with raid 5. Probably. If you know of somebody I don't know of, please let me know. As one of the small minority who was having problems I'd advice you to soaktest any vinum raid 5 installation before committing important data to it. That's what vinum(4) says. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
3.1 - 4-S via NFS
Hi ! I have two boxes running FreeBSD 3.1-RELEASE and 4.X-STABLE. I want to build world on 4.X system and then install it over NFS to 3.1 system. Is there any pitfalls in this process ? Caveats ? -- Best regards, Andrey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Vinum saga continues
Hi, Attached is the most valuable information that was in my pr 22103. I've read the vinumdebug and the other guy's PR. I'm still not getting what is missing. You told the other guy to submit the backtrace, but it was in fact submitted! It's as well in my PR as well. Your responses are very brief - "please read vinumdebug", but in fact, if there's something that is missing, you can be more specific. Alfred Perlstein looked it my PR once and he thinks that it's due to stack smashing. However, he wasn't able to find where it happends. It may be in fact interaction with some other driver, like you said, for example - fxp. This is why I submitted the dmesg output. --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] Script started on Sun Oct 22 10:00:33 2000 matrix#gdb -k /usr/src/sys/compile/MATRIX/kernel.debug 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 3219456 initial pcb at 29a720 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x54 fault code = supervisor write, page not present instruction pointer= 0x8:0xc150fc67 stack pointer = 0x10:0xc0277394 frame pointer = 0x10:0xc02773b0 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= Idle interrupt mask = bio trap number= 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer= 0x8:0xc01e2e50 stack pointer = 0x10:0xc02771cc frame pointer = 0x10:0xc02771d0 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= Idle interrupt mask = bio trap number= 12 panic: page fault Uptime: 6m22s Fatal trap 12: page fault while in kernel mode fault virtual address = 0x54 fault code = supervisor write, page not present instruction pointer= 0x8:0xc150fc67 stack pointer = 0x10:0xc0276ab0 frame pointer = 0x10:0xc0276acc 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= Idle interrupt mask = bio cam trap number= 12 panic: page fault Uptime: 6m22s Fatal trap 12: page fault while in kernel mode fault virtual address = 0x54 fault code = supervisor write, page not present instruction pointer= 0x8:0xc150fc67 stack pointer = 0x10:0xc0276394 frame pointer = 0x10:0xc02763b0 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= Idle interrupt mask = bio cam trap number= 12 panic: page fault Uptime: 6m22s Fatal trap 12: page fault while in kernel mode fault virtual address = 0x54 fault code = supervisor write, page not present instruction pointer= 0x8:0xc150fc67 stack pointer = 0x10:0xc0275c78 frame pointer = 0x10:0xc0275c94 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= Idle interrupt mask = bio cam trap number= 12 panic: page fault Uptime: 6m22s Fatal trap 12: page fault while in kernel mode fault virtual address = 0x54 fault code = supervisor write, page not present instruction pointer= 0x8:0xc150fc67 stack pointer = 0x10:0xc027555c frame pointer = 0x10:0xc0275578 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= Idle interrupt mask = bio cam trap number= 12 panic: page fault Uptime: 6m22s dumping to dev #da/0x20001, offset 774 dump 511 510 509 508 507 506 505 504 503 502 501
Re: Vinum safe to use for raid 0?
Quoting Thomas Seck [EMAIL PROTECTED]: Hi all, sorry if this is OT for -stable, but I followed the discussion about vinum in here and got a bit worried. I am currently deploying a proxy server for our company. It shall use squid on 4.2-STABLE. I would like to put the cache data on a vinum RAID 0, made of three U160 disks. As I understood the discussion so far, there are some unresolved problems with the raid 5 code. Could someone tell me whether I can safely use vinum for building a raid 0 system (despite the fact that the HW may be a point of failure of course)? Thanks in advance and best regards from Germany -Thomas Seck But why would you want to use it for squid? Just define multiple cachedirs. It's surely more simple to deploy and maintain, and it may even be better in performance. --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: wi0 or isab0 trouble?
Hi, I've comited a little mistake. I've got a script install and its was changed one line: wicontrol -i wi0 -t 6 to wicontrol -t wi0 -t 6 Our suggestion is "wicontrol" report "invalid option" in cases like this. Excuse-me, Paulo. On Tue, 2 Jan 2001, Paulo Fragoso wrote: Hi, We was using FreeBSD and WaveLAN without problems. But now we are trying to use 4.2-20001219-STABLE and we are found some problems. We have got one PII 350MHz (chiset 440 BX motherboard) working fine, but using some old motherboards we get this error: wi0: device timeout wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: failed to alloacte 1594 bytes on NIC wi0: mgmt. buffer allocation failed That old motherboard has got the chipset VIA VT82C576M with a Pentium 100MHz. Looking at result from dmesg there is a little difference: work-there are isab0 and isa0 at motherboard that works: isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 don't work- there isn't isab0!!!: isa0: ISA bus on isab0 We've got another older motherboard (chipset intel TX) working fine with FreeBSD 4.2-RELEASE, and we can found isab0 on dmesg: isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 Likely the wi0 require a isab0 (I think). Why when are we using FreeBSD 4.2-STABLE we can't found a isab0 on old motherboard? Why don't wi0 works? We've installed FreeBSD 4.1-RELEASE on same VIA motherboard to test and all works fine. But on that motherboard we can't found a isab0 with dmesg, too. Are we thinking wrong? When we are using same motherboard (VIA VT82C576M) with FBSD 4.1-RELEASE are all working fine? We've tested FBSD 4.2-RELEASE and 4.2-20001219-STABLE and both don't work on this motherboard. Finally: Why are all versions tested of FreeBSD working fine using a 440BX motherboard? Thanks, Paulo Fragoso. -- __O _-\,_ Why drive when you can bike? (_)/ (_) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message -- __O _-\,_ Why drive when you can bike? (_)/ (_) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kern/21148: multiple crashes while using vinum
Dear Greg, Andy, Roman, [EMAIL PROTECTED] wrote on Mon, Jan 01, 2001 at 11:41:19PM +: Synopsis: multiple crashes while using vinum [..] State-Changed-Why: No feedback from submitter. http://www.freebsd.org/cgi/query-pr.cgi?pr=21148 Well, I've sent you stack-traces, with (and alas as well without) debugging symbols, I am perfectly aware of your instruction page about debugging vinum, and not an ignorant moron, who complains without reading. Unfortunately you don't seem to trust me or other people in this matter. If you look at my stack-traces again you will notice, that no stack-frame is part of the vinum module, so your .gdb-debugging scripts cannot apply. The reason is, that _some code_ writes into unallocated memory, in my case overwriting a data-structure of an ata-request with a few zero bytes, causing the panic. The stack trace allows me to trace the problem back to this point, but not further. I later experienced a similar problem on a scsi-only system. The reason, why I filed this pr unter 'vinum' is, that it only occured on boxes using vinum, and perfectly reproducable via simple operations like a 'find /vinum/file/system -print' on a larger and moderately filled vinum-filesystem. Perfectly reproducable means: each night, periodic daily caused the panic (traceable to the find call in /etc/security, finding files with setuid bits). As far as I know, the only way to trace this writing into unallocated/otherallocated memory resp. buffer overrun would be to set a watchpoint to the overwritten data-structure within the kernel-debugger. My stack-traces showed that this memory region stays the same on the same machine with the same kernel (although I can't tell how reliable this is). My experiences with kernel code and kernel-debugging with ddb are very limited. So is my time (I know this applies to anyone). Therefore I ceased spending time to set up remote-gdb sessions and sending you stack traces trying to be helpful, since you obviously didn't seem to be interested. I further decided not to use vinum any more. We spent some cash on a few hardware RAIDs, and the boxes run smooth now, since. I am just writing this to state: a) I did respond to your requests, trying to be as helpful as I could. You could blame me for not knowing or willing to learn how to set up a ddb/gdb session using watchpoints and waiting for the next crash in an environmen that should be productive (and now is). b) I still believe, that there is a problem somewhere in the vinum code (probably within raid5 routines, since a mirror setup worked fine). And in fact, I wouldn't have bothered if there weren't any other people like Roman Shterenzon and Andy Newman, who seem to have the same problems. Best regards, Daniel Lang P.S.: I don't use vinum anymore, nor can I take my boxes out of production. The debugging kernels and crash-dumps are no longer present, sorry. -- IRCnet: Mr-Spock - Der Schatten von Hasenfuss ist ziemlich dunkel - *Daniel Lang * [EMAIL PROTECTED] * +49 89 289 25735 * http://www.leo.org/~dl/* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kldload: Exec format error, is 4.2 problem?
In article by Daniel O'Connor: On 03-Jan-01 Warren Toomey wrote: # kldload /usr/local/modules/rtc.ko kldload: can't load /usr/local/modules/rtc.ko: Exec format error Is this a 4.2-thing, or have I just done something wrong? I've searched the FreeBSD mail lists for clues, with no luck. Ok, I've found the answer. The rtc and vmware2 ports both turn this flag on in the appropriate Makefiles: KMODDEPS= linux This creates a binary file called `linux' which is linked in (?) to the the module at compile time, e.g: ld -Bshareable -o vmmon_up.ko setdef0.o vmmon_up.kld setdef1.o linux By commenting out this flag, the file `linux' isn't used, and the module can then be loaded by kldload. Also, vmware appears to work fine. Hope this helps someone else! Cheers, Warren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kldload: Exec format error, is 4.2 problem?
On 04-Jan-01 Warren Toomey wrote: In article by Daniel O'Connor: On 03-Jan-01 Warren Toomey wrote: # kldload /usr/local/modules/rtc.ko kldload: can't load /usr/local/modules/rtc.ko: Exec format error Is this a 4.2-thing, or have I just done something wrong? I've searched the FreeBSD mail lists for clues, with no luck. Ok, I've found the answer. The rtc and vmware2 ports both turn this flag on in the appropriate Makefiles: KMODDEPS= linux This creates a binary file called `linux' which is linked in (?) to the the module at compile time, e.g: ld -Bshareable -o vmmon_up.ko setdef0.o vmmon_up.kld setdef1.o linux By commenting out this flag, the file `linux' isn't used, and the module can then be loaded by kldload. Also, vmware appears to work fine. The reason it has the KMODDEPS line is to add a dependancy on the linux kld. This means that if the vmware kld is loaded the linux one will be loaded if necessary. I think you should send this directly to the vmware maintainer though :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
4.2-STABLE build fails
Hi I've seen much of this discussed here but mine seems to break at this point: /usr/obj/usr/src/share/doc/usd/13.viref/troff.core ..and with this msg on the console... Jan 3 18:54:07 alouette /kernel: pid 54505 (troff), uid 0: exited on signal 11 (core dumped) Jan 3 18:54:07 alouette /kernel: pid 54523 (troff), uid 0: exited on signal 11 (core dumped) Even a fresh cvsup (after rm-ing all my srcs and usr/obj) does not help. Any pointer what this 13.viref thing is and how I can sort that out will be highly appreciated. -Wash -- Odhiambo Washington Inter-Connect Ltd., [EMAIL PROTECTED] 5th Flr Furaha Plaza Tel: 254 11 222604 Nkrumah Rd., Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Blessed are they who can laugh at themselves, for they shall never cease to be amused. (contributed by Chris Johnston) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problem with Syslog and Stable
* Lawrence Farr [EMAIL PROTECTED] [20010103 19:10]: writing on the subject 'Problem with Syslog and Stable' =I am getting a lot of: = =Jan 3 16:04:55 frogger syslogd: '/' in "/dev//dev/tty" = =in /var/log/messages, and my daily run output has: = =Local system status: =uptime: /dev//dev/tty: No such file or directory = 2:36AM up 12 days, 9:55, 5 users, load averages: 0.03, 0.01, 0.00 = =In it. = =Issuing the w command gives me: = =w: /dev//dev/tty: No such file or directory = 4:07PM up 12 days, 23:26, 6 users, load averages: 0.00, 0.00, 0.00 =etc. = =Im getting this on multiple machines that I have, and all have been built =from there own sources to stable on different days/weeks, and a =mergemaster -a run. = =Anyone got any ideas where to start looking? Sounds quite a rare situation, unless there is a file that you've moved around while adapting it to each machine - and that file could be having a small issue within. I'm thinking of a situation where you do not want to manually edit your syslog.conf for every individual machine and so just copy one syslog.conf from machine A into machines B and C, which then end up inheriting the small typo in syslog.conf. You could start from there but that's a guess. -Wash -- Odhiambo Washington Inter-Connect Ltd., [EMAIL PROTECTED] 5th Flr Furaha Plaza Tel: 254 11 222604 Nkrumah Rd., Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Cloquet hated reality but realized it was still the only place to get a good steak. -Woody Allen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
NFSv3 O_EXCL file create - protocol spec solution (was Re: Bug in NFSv3 client)
The RFC (1813) says that the exclusive-file-create NFS op passes a
verifier. It says, and I quote:
"One aspect of the NFS version 3 protocol CREATE procedure
warrants particularly careful consideration: the mechanism
introduced to support the reliable exclusive creation of
regular files. The mechanism comes into play when how.mode
is EXCLUSIVE. In this case, how.verf contains a verifier
that can reasonably be expected to be unique. A
combination of a client identifier, perhaps the client
network address, and a unique number generated by the
client, perhaps the RPC transaction identifier, may be
appropriate."
What that means is that the verifier can be anything.
Here's why the FreeBSD server was storing the verifier as the
file access time:
"verifier must be stored in stable storage to prevent
erroneous failure on retransmission of the request. It is
assumed that an exclusive create is being performed
because exclusive semantics are critical to the
application. Because of the expected usage, exclusive
CREATE does not rely solely on the normally volatile
duplicate request cache for storage of the verifier. The
duplicate request cache in volatile storage does not
survive a crash and may actually flush on a long network
partition, opening failure windows. In the UNIX local
file system environment, the expected storage location for
the verifier on creation is the metadata (time stamps) of
the file. For this reason, an exclusive file create may
not include initial attributes because the server would
have nowhere to store the verifier."
Ahhh, so now we know why FreeBSD is passing the IP address of
the interface plus a 'unique' number! Or trying anyway.
And also:
"Once the client has performed a successful exclusive
create, it must issue a SETATTR to set the correct file
attributes. Until it does so, it should not rely upon any
of the file attributes, since the server implementation
may need to overload file metadata to store the verifier."
What this means is that the FreeBSD client is supposed to call
SETATTR to set the correct file attributes after the O_EXCL open
succeeds. It is in fact doing this, but the 'atime' attribute
in the 'vap' structure is not initialized, so the SETATTR call
never actually fixes up the access time.
Solaris probably shouldn't be generating an error for the 'bogus'
time specification, as that can race with an O_EXCL create, but
I think fixing the FreeBSD clients to do the proper SETATTR
should solve the problem.
I've included the patch below. The patch will fix FreeBSD
clients. I will commit it to -current now and to -stable in
two days if there aren't any problems. (Throw away any previous
patches you might have applied).
-Matt
Index: nfs_vnops.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.150
diff -u -r1.150 nfs_vnops.c
--- nfs_vnops.c 2000/01/05 00:32:18 1.150
+++ nfs_vnops.c 2001/01/04 07:48:37
@@ -1436,8 +1436,21 @@
}
if (newvp)
vput(newvp);
- } else if (v3 (fmode O_EXCL))
+ } else if (v3 (fmode O_EXCL)) {
+ /*
+* We are normally called with only a partially initialized
+* VAP. Since the NFSv3 spec says that server may use the
+* file attributes to store the verifier, the spec requires
+* us to do a SETATTR RPC. FreeBSD servers store the verifier
+* in atime, but we can't really assume that all servers will
+* so we ensure that our SETATTR sets both atime and mtime.
+*/
+ if (vap-va_mtime.tv_sec == VNOVAL)
+ vfs_timestamp(vap-va_mtime);
+ if (vap-va_atime.tv_sec == VNOVAL)
+ vap-va_atime = vap-va_mtime;
error = nfs_setattrrpc(newvp, vap, cnp-cn_cred, cnp-cn_proc);
+ }
if (!error) {
if (cnp-cn_flags MAKEENTRY)
cache_enter(dvp, newvp, cnp);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
