Re: build failure in libz
On Wed, Apr 22, 2020 at 03:48:30PM +0900, Rin Okuyama wrote: > I don't understand why commits to phil-wifi affected to -HEAD... ARGH - I hate cvs. Will fix... Martin
Re: Aquantia AQC100 issues
Hi!
>> Recently I received Asus XG-C100F SFP+ network controller based on
>> Aquantia AQC100. Though, it's currently supported by aq(4) driver, I
>> believe it should be relatively easy to add. I tried to blindly add
>> the device to the list and even made it work, unfortunately with some
>> caveats. To make work I need to boot into the system first and
>> physically reattach the cable (I am using DAC). Even if cable is
>> attached and system boots, media type is not recognized and reports as
>> if link is missing, unless I physically reattach it. After that it
>> properly configures and dhcpcd assigns IP address. I can successfully
>> access the network. Any ideas why I need to reattach the cable?
I'm not sure, but in the case of FIBRE, the behavior around link status
may be different from TP.
As a workaround, following patch to force polling linkstat. Will this
solve the problem?
cvs -q diff -U8 -a -p if_aq.c
Index: if_aq.c
===
RCS file: /cvsroot/src/sys/dev/pci/if_aq.c,v
retrieving revision 1.11
diff -U 8 -a -p -r1.11 if_aq.c
--- if_aq.c 15 Feb 2020 12:20:35 - 1.11
+++ if_aq.c 22 Apr 2020 08:02:02 -
@@ -1301,16 +1301,21 @@ aq_attach(device_t parent, device_t self
sc->sc_use_txrx_independent_intr = false;
sc->sc_poll_linkstat = true;
sc->sc_msix = true;
} else {
/* giving up using MSI-X */
sc->sc_msix = false;
}
+#define FORCE_POLL_LINKSTAT
+#ifdef FORCE_POLL_LINKSTAT
+ sc->sc_poll_linkstat = true;
+#endif
+
aprint_debug_dev(sc->sc_dev,
"ncpu=%d, pci_msix_count=%d."
" allocate %d interrupts for %d%s queues%s\n",
ncpu, msixcount,
(sc->sc_use_txrx_independent_intr ?
(sc->sc_nqueues * 2) : sc->sc_nqueues) +
(sc->sc_poll_linkstat ? 0 : 1),
sc->sc_nqueues,
Thanks,
--
ryo shimizu
Re: build failure in libz
On 2020/04/22 16:01, Martin Husemann wrote: On Wed, Apr 22, 2020 at 03:48:30PM +0900, Rin Okuyama wrote: I don't understand why commits to phil-wifi affected to -HEAD... ARGH - I hate cvs. Will fix... Seems fixed now. Thank you! rin
Re: build failure in libz
On Wed, Apr 22, 2020 at 09:27:44PM +0900, Rin Okuyama wrote: > Seems fixed now. Thank you! No quite sure what happened, but every file affected by the re-adding that was from a vendor branch and unchanged on the wifi branch got its default branch set to trunk (instead of the vendor branch). spz fixed it (as I don't have "cvs admin -b" access), thanks a lot! (I am not sure I want to know what stupid thing I did to trigger it, or whether it is a generic cvs bug...) Moving to hg-trial now. Martin
Re: build failure in libz
Martin Husemann wrote: >On Wed, Apr 22, 2020 at 09:27:44PM +0900, Rin Okuyama wrote: >> Seems fixed now. Thank you! > >No quite sure what happened, but every file affected by the re-adding >that was from a vendor branch and unchanged on the wifi branch got >its default branch set to trunk (instead of the vendor branch). Do we need to do anything special to fix it in our checked out trees, or will just a 'cvs update' do it ?
Re: build failure in libz
On Wed, Apr 22, 2020 at 01:45:25PM +0100, Robert Swindells wrote: > Do we need to do anything special to fix it in our checked out trees, or > will just a 'cvs update' do it ? I think a cvs up should do. Martin
Re: panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin lock held
Hi Paul, On Wed, Apr 22, 2020 at 12:06:41PM +1000, Paul Ripke wrote: > On -current as of ~yesterday, in a 1CPU amd64 qemu boot, I'm seeing: > > Waiting for duplicate address detection to finish... > Starting dhcpcd. > dhcpcd-9.0.1 starting > unknown option: > [ 17.0102686] wm0: link state UP (was UNKNOWN) > wm0: carrier acquired > unknown option: > [ 17.1710186] pid 122 (dhcpcd), uid 35: exited on signal 11 (core not > dumped, err = 1) > dhcpcd_fork_cb: truncated read 0 (expected 4) > /etc/rc.d/dhcpcd exited with code 1 > Building databases: dev[ 19.2211655] Mutex error: mutex_vector_enter,514: > spin lock held > > [ 19.2211655] lock address : 0x81765a40 type : spin > [ 19.2211655] initialized : 0x80a2690f > [ 19.2211655] shared holds : 0 exclusive: 1 > [ 19.2211655] shares wanted: 0 exclusive: 0 > [ 19.2211655] relevant cpu : 0 last held: 0 > [ 19.2211655] relevant lwp : 0x80a57f71c2c0 last held: 0x80a57f71c2c0 > [ 19.2211655] last locked* : 0x80a24843 unlocked : 0x80a268e7 > [ 19.2211655] owner field : 0x00010600 wait/spin:0/1 > > [ 19.2211655] panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin > lock held > [ 19.2211655] cpu0: Begin traceback... > [ 19.2211655] vpanic() at netbsd:vpanic+0x178 > [ 19.2211655] snprintf() at netbsd:snprintf > [ 19.2211655] lockdebug_more() at netbsd:lockdebug_more > [ 19.2211655] mutex_enter() at netbsd:mutex_enter+0x3c7 > [ 19.2211655] vmem_rehash_all() at netbsd:vmem_rehash_all+0x13a > [ 19.2211655] workqueue_worker() at netbsd:workqueue_worker+0xe1 > [ 19.2211655] cpu0: End traceback... > > Seems consistent between attempts. > > Known? Meanwhile, I'll re-sync and try again. This one was fixed with src/sys/kern/subr_vmem.c 1.103. Cheers, Andrew
Re: build failure in libz
Hi, It seems that files in the following directories are rolled back to rev 1.x after removing & re-adding to phil-wifi branch: src/common/dist/zlib src/crypto/external/bsd/heimdal src/crypto/dist/ipsec-tools For example for src/common/dist/zlib/inflate.h, 1.1 is checked out whereas 1.1.1.2 should be. I don't understand why commits to phil-wifi affected to -HEAD... Thanks, rin On 2020/04/22 7:41, Thomas Klausner wrote: Hi! I'm running a userland from 2020-04-12/amd64 when NetBSD built fine for me. When I try building NetBSD-current now, it fails in libz with: # compile libz/infback.o gcc -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror -fPIE -fstack-protector -Wstack-protector --param ssp-buffer-size=1 -I/usr/src/common/dist/zlib -D_FORTIFY_SOURCE=2 -c - Wno-error=implicit-fallthrough /usr/src/common/dist/zlib/infback.c -o infback.o /usr/src/common/dist/zlib/infback.c: In function ‘inflateBackInit_’: /usr/src/common/dist/zlib/infback.c:69:12: error: ‘struct inflate_state’ has no member named ‘wnext’; did you mean ‘next’? state->wnext = 0; ^ next /usr/src/common/dist/zlib/infback.c: In function ‘inflateBack’: /usr/src/common/dist/zlib/infback.c:481:25: warning: this statement may fall through [-Wimplicit-fallthrough=] state->mode = LEN; ^ /usr/src/common/dist/zlib/infback.c:483:9: note: here case LEN: ^~~~ *** Error code 1 And /usr/src/common/dist/zlib/inflate.c: In function 'inflateMark': /usr/src/common/dist/zlib/inflate.c:1559:47: error: 'struct inflate_state' has no member named 'back' return (long)(((unsigned long)((long)state->back)) << 16) + ^~ /usr/src/common/dist/zlib/inflate.c:1561:44: error: 'struct inflate_state' has no member named 'was'; did you mean 'last'? (state->mode == MATCH ? state->was - state->length : 0)); ^~~ last I don't see a mail about this from the build bots, and I don't see any relevant changes between April 12 and today (about an hour ago) that'd explain it. Any ideas? Thomas
Re: Aquantia AQC100 issues
Hi,
Yes, the patch solves the problem. Linked is up immediately after the boot.
On Wed, Apr 22, 2020, 11:26 Ryo Shimizu wrote:
>
> Hi!
>
> >> Recently I received Asus XG-C100F SFP+ network controller based on
> >> Aquantia AQC100. Though, it's currently supported by aq(4) driver, I
> >> believe it should be relatively easy to add. I tried to blindly add
> >> the device to the list and even made it work, unfortunately with some
> >> caveats. To make work I need to boot into the system first and
> >> physically reattach the cable (I am using DAC). Even if cable is
> >> attached and system boots, media type is not recognized and reports as
> >> if link is missing, unless I physically reattach it. After that it
> >> properly configures and dhcpcd assigns IP address. I can successfully
> >> access the network. Any ideas why I need to reattach the cable?
>
> I'm not sure, but in the case of FIBRE, the behavior around link status
> may be different from TP.
> As a workaround, following patch to force polling linkstat. Will this
> solve the problem?
>
> cvs -q diff -U8 -a -p if_aq.c
> Index: if_aq.c
> ===
> RCS file: /cvsroot/src/sys/dev/pci/if_aq.c,v
> retrieving revision 1.11
> diff -U 8 -a -p -r1.11 if_aq.c
> --- if_aq.c 15 Feb 2020 12:20:35 - 1.11
> +++ if_aq.c 22 Apr 2020 08:02:02 -
> @@ -1301,16 +1301,21 @@ aq_attach(device_t parent, device_t self
> sc->sc_use_txrx_independent_intr = false;
> sc->sc_poll_linkstat = true;
> sc->sc_msix = true;
> } else {
> /* giving up using MSI-X */
> sc->sc_msix = false;
> }
>
> +#define FORCE_POLL_LINKSTAT
> +#ifdef FORCE_POLL_LINKSTAT
> + sc->sc_poll_linkstat = true;
> +#endif
> +
> aprint_debug_dev(sc->sc_dev,
> "ncpu=%d, pci_msix_count=%d."
> " allocate %d interrupts for %d%s queues%s\n",
> ncpu, msixcount,
> (sc->sc_use_txrx_independent_intr ?
> (sc->sc_nqueues * 2) : sc->sc_nqueues) +
> (sc->sc_poll_linkstat ? 0 : 1),
> sc->sc_nqueues,
>
>
> Thanks,
> --
> ryo shimizu
>
Re: panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin lock held
On Wed, Apr 22, 2020 at 09:44:56PM +, Andrew Doran wrote: > Hi Paul, > > On Wed, Apr 22, 2020 at 12:06:41PM +1000, Paul Ripke wrote: > > On -current as of ~yesterday, in a 1CPU amd64 qemu boot, I'm seeing: > > > > Waiting for duplicate address detection to finish... > > Starting dhcpcd. > > dhcpcd-9.0.1 starting > > unknown option: > > [ 17.0102686] wm0: link state UP (was UNKNOWN) > > wm0: carrier acquired > > unknown option: > > [ 17.1710186] pid 122 (dhcpcd), uid 35: exited on signal 11 (core not > > dumped, err = 1) > > dhcpcd_fork_cb: truncated read 0 (expected 4) > > /etc/rc.d/dhcpcd exited with code 1 > > Building databases: dev[ 19.2211655] Mutex error: mutex_vector_enter,514: > > spin lock held > > > > [ 19.2211655] lock address : 0x81765a40 type : > > spin > > [ 19.2211655] initialized : 0x80a2690f > > [ 19.2211655] shared holds : 0 exclusive: > > 1 > > [ 19.2211655] shares wanted: 0 exclusive: > > 0 > > [ 19.2211655] relevant cpu : 0 last held: > > 0 > > [ 19.2211655] relevant lwp : 0x80a57f71c2c0 last held: > > 0x80a57f71c2c0 > > [ 19.2211655] last locked* : 0x80a24843 unlocked : > > 0x80a268e7 > > [ 19.2211655] owner field : 0x00010600 wait/spin: > > 0/1 > > > > [ 19.2211655] panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin > > lock held > > [ 19.2211655] cpu0: Begin traceback... > > [ 19.2211655] vpanic() at netbsd:vpanic+0x178 > > [ 19.2211655] snprintf() at netbsd:snprintf > > [ 19.2211655] lockdebug_more() at netbsd:lockdebug_more > > [ 19.2211655] mutex_enter() at netbsd:mutex_enter+0x3c7 > > [ 19.2211655] vmem_rehash_all() at netbsd:vmem_rehash_all+0x13a > > [ 19.2211655] workqueue_worker() at netbsd:workqueue_worker+0xe1 > > [ 19.2211655] cpu0: End traceback... > > > > Seems consistent between attempts. > > > > Known? Meanwhile, I'll re-sync and try again. > > This one was fixed with src/sys/kern/subr_vmem.c 1.103. Thanks, I'll wait for the github mirror to catch up - it seems to erratically lag. Unfortunately(?) I switched away from cvsup some time ago... -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
daily CVS update output
Updating src tree: P src/common/dist/zlib/CMakeLists.txt P src/common/dist/zlib/ChangeLog P src/common/dist/zlib/FAQ P src/common/dist/zlib/INDEX U src/common/dist/zlib/Makefile P src/common/dist/zlib/Makefile.in P src/common/dist/zlib/README P src/common/dist/zlib/adler32.c P src/common/dist/zlib/configure P src/common/dist/zlib/crc32.h P src/common/dist/zlib/gzclose.c P src/common/dist/zlib/gzlib.c P src/common/dist/zlib/gzread.c P src/common/dist/zlib/inffast.h P src/common/dist/zlib/inffixed.h P src/common/dist/zlib/inflate.h P src/common/dist/zlib/inftrees.h P src/common/dist/zlib/make_vms.com P src/common/dist/zlib/treebuild.xml P src/common/dist/zlib/trees.h P src/common/dist/zlib/zconf.h.cmakein P src/common/dist/zlib/zconf.h.in P src/common/dist/zlib/zlib.3 P src/common/dist/zlib/zlib.3.pdf P src/common/dist/zlib/zlib.map P src/common/dist/zlib/zlib.pc.cmakein P src/common/dist/zlib/zlib.pc.in P src/common/dist/zlib/zlib2ansi P src/common/dist/zlib/amiga/Makefile.pup P src/common/dist/zlib/amiga/Makefile.sas P src/common/dist/zlib/contrib/README.contrib P src/common/dist/zlib/contrib/ada/buffer_demo.adb P src/common/dist/zlib/contrib/ada/mtest.adb P src/common/dist/zlib/contrib/ada/read.adb P src/common/dist/zlib/contrib/ada/readme.txt P src/common/dist/zlib/contrib/ada/test.adb P src/common/dist/zlib/contrib/ada/zlib-streams.adb P src/common/dist/zlib/contrib/ada/zlib-streams.ads P src/common/dist/zlib/contrib/ada/zlib-thin.adb P src/common/dist/zlib/contrib/ada/zlib-thin.ads P src/common/dist/zlib/contrib/ada/zlib.adb P src/common/dist/zlib/contrib/ada/zlib.ads P src/common/dist/zlib/contrib/ada/zlib.gpr P src/common/dist/zlib/contrib/amd64/amd64-match.S P src/common/dist/zlib/contrib/asm686/README.686 P src/common/dist/zlib/contrib/asm686/match.S P src/common/dist/zlib/contrib/blast/Makefile P src/common/dist/zlib/contrib/blast/README P src/common/dist/zlib/contrib/blast/blast.c P src/common/dist/zlib/contrib/blast/blast.h U src/common/dist/zlib/contrib/blast/test.pk U src/common/dist/zlib/contrib/blast/test.txt P src/common/dist/zlib/contrib/delphi/ZLib.pas P src/common/dist/zlib/contrib/delphi/ZLibConst.pas P src/common/dist/zlib/contrib/delphi/readme.txt P src/common/dist/zlib/contrib/delphi/zlibd32.mak U src/common/dist/zlib/contrib/dotzlib/DotZLib.build U src/common/dist/zlib/contrib/dotzlib/DotZLib.chm P src/common/dist/zlib/contrib/dotzlib/DotZLib.sln U src/common/dist/zlib/contrib/dotzlib/LICENSE_1_0.txt P src/common/dist/zlib/contrib/dotzlib/readme.txt P src/common/dist/zlib/contrib/gcc_gvmat64/gvmat64.S P src/common/dist/zlib/contrib/infback9/README P src/common/dist/zlib/contrib/infback9/infback9.c P src/common/dist/zlib/contrib/infback9/infback9.h P src/common/dist/zlib/contrib/infback9/inffix9.h P src/common/dist/zlib/contrib/infback9/inflate9.h P src/common/dist/zlib/contrib/infback9/inftree9.c P src/common/dist/zlib/contrib/infback9/inftree9.h P src/common/dist/zlib/contrib/inflate86/inffas86.c P src/common/dist/zlib/contrib/inflate86/inffast.S P src/common/dist/zlib/contrib/iostream/test.cpp P src/common/dist/zlib/contrib/iostream/zfstream.cpp P src/common/dist/zlib/contrib/iostream/zfstream.h P src/common/dist/zlib/contrib/iostream2/zstream.h P src/common/dist/zlib/contrib/iostream3/README P src/common/dist/zlib/contrib/iostream3/TODO P src/common/dist/zlib/contrib/iostream3/test.cc P src/common/dist/zlib/contrib/iostream3/zfstream.cc P src/common/dist/zlib/contrib/iostream3/zfstream.h P src/common/dist/zlib/contrib/masmx64/bld_ml64.bat P src/common/dist/zlib/contrib/masmx64/gvmat64.asm P src/common/dist/zlib/contrib/masmx64/inffas8664.c P src/common/dist/zlib/contrib/masmx64/inffasx64.asm P src/common/dist/zlib/contrib/masmx64/readme.txt U src/common/dist/zlib/contrib/masmx86/bld_ml32.bat P src/common/dist/zlib/contrib/masmx86/inffas32.asm P src/common/dist/zlib/contrib/masmx86/match686.asm U src/common/dist/zlib/contrib/masmx86/readme.txt P src/common/dist/zlib/contrib/minizip/Makefile P src/common/dist/zlib/contrib/minizip/Makefile.am P src/common/dist/zlib/contrib/minizip/MiniZip64_Changes.txt P src/common/dist/zlib/contrib/minizip/MiniZip64_info.txt P src/common/dist/zlib/contrib/minizip/configure.ac P src/common/dist/zlib/contrib/minizip/crypt.h P src/common/dist/zlib/contrib/minizip/ioapi.c P src/common/dist/zlib/contrib/minizip/ioapi.h P src/common/dist/zlib/contrib/minizip/iowin32.c P src/common/dist/zlib/contrib/minizip/iowin32.h P src/common/dist/zlib/contrib/minizip/make_vms.com P src/common/dist/zlib/contrib/minizip/miniunz.c P src/common/dist/zlib/contrib/minizip/miniunzip.1 P src/common/dist/zlib/contrib/minizip/minizip.1 P src/common/dist/zlib/contrib/minizip/minizip.c P src/common/dist/zlib/contrib/minizip/minizip.pc.in P src/common/dist/zlib/contrib/minizip/mztools.c P src/common/dist/zlib/contrib/minizip/mztools.h P src/common/dist/zlib/contrib/minizip/unzip.c P src/common/dist/zlib/contrib/minizip/unzip.h P src/common/dist/zlib/contrib/minizip/zip.c P src/
odd behaviour of some programs on i386 cross-built from amd64
I decided to try upgrading some little Soekris boxes recently.
At the moment I only have amd64 build machines, so I did a cross-build
targeting i386.
Note that my source tree is somewhat dated, at about 8.99.32, but I've
been running this code without problem on a number of amd64 machines
(mostly Xen servers in both dom0 and domU).
This however is the first time I've upgraded any i386 machine. The most
recently installed were some 5.1_STABLE systems (which were also
cross-built from amd64, but with similarly old host releases).
However when I finished the upgrade on the first Soekris system there
were some odd looking messages on the console from syslogd when I first
logged in, e.g.:
Feb?12?10:12:39?lilbit?login:?ROOT^`LOGIN^`(root)^`ON^`constty
Syslog messages appear slightly better, but still odd, in the log files:
Feb 12 10:30:00 lilbit cron[2759]:
(root)^`CMD^`START^`(/usr/libexec/atrun)
Feb 12 10:30:00 lilbit cron[3058]:
(root)^`CMD^`FINISH^`(/usr/libexec/atrun)
Then I found that some things just didn't quite work properly at all,
while others didn't work quite correctly.
Since this also happens with the same build running under Xen, so here
are some examples from that environment:
# uname -a
NetBSD 8.99.32 NetBSD 8.99.32 (XEN3PAE_DOMU) #4: Thu Apr 16 17:48:40
PDT 2020
woods@future:/build/woods/future/current-amd64-i386-ppro-obj/more/work/woods/m-NetBSD-current/sys/arch/i386/compile/XEN3PAE_DOMU
i386
So, the good news is recent i386 XEN3PAE_DOMU kernels do run fine in Xen!
but awk does weird things:
# echo "1 2" | awk '{n=$2} END {print n}'
# echo "1 2" | awk '{print $2}'
# echo "1 2" | awk '{print}'
1 2
# echo "1 2" | awk '{n=$2} END {printf("n=%s\n", n)}'
# echo "1 2" | awk '{printf("$2=%s\n", $2)}'
$2=2
also od (and hexdump) fail completely with a very odd message:
# od
od: "8/2 " %06o " "\n"": bad format
# file /usr/bin/od
/usr/bin/od: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically linked, for NetBSD 8.99.32, stripped
and ksh also seems to echo spaces as "^`" (just like syslogd did partly)
(it's not the tty driver though -- it's ksh itself, turning off echoctl
has no effect):
# ksh
# echo^`hello
hello
# echo^`"'^`^`^`^`'"
''
Most things seem to work though, including the kernel, with networking,
NFS, etc. I.e. multiuser boot worked A-OK.
Does any of this look even remotely familiar to anyone else?
Oh, and note also that my build was done with:
CPUFLAGS = -march=i586 -mtune=pentiumpro
I'll try another build with no CPUFLAGS, and if that similarly fails
I'll try a stock official i386 install and cross-build with that.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpthODnDFH8x.pgp
Description: OpenPGP Digital Signature
Re: build failure in libz
rokuyama...@gmail.com (Rin Okuyama) writes: >It seems that files in the following directories are rolled back to >rev 1.x after removing & re-adding to phil-wifi branch: >src/common/dist/zlib >src/crypto/external/bsd/heimdal >src/crypto/dist/ipsec-tools >For example for src/common/dist/zlib/inflate.h, 1.1 is checked out >whereas 1.1.1.2 should be. The default branch information (which was the vendor branch for these files) was removed and cvs would return the trunk version instead. This is usually an admin operation, but it also happens when removing a file and temporarily in a commit. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Aquantia AQC100 issues
>Yes, the patch solves the problem. Linked is up immediately after the boot. I'm relieved. In the interim, I'll commit a fix that always polling linkstat when FIBRE. thanks, -- ryo shimizu
Re: build failure in libz
Hi, # This problem had already been fixed. My previous message was # stalled somehow and delivered after preceding ones... On 2020/04/23 13:57, Michael van Elst wrote: rokuyama...@gmail.com (Rin Okuyama) writes: It seems that files in the following directories are rolled back to rev 1.x after removing & re-adding to phil-wifi branch: src/common/dist/zlib src/crypto/external/bsd/heimdal src/crypto/dist/ipsec-tools For example for src/common/dist/zlib/inflate.h, 1.1 is checked out whereas 1.1.1.2 should be. The default branch information (which was the vendor branch for these files) was removed and cvs would return the trunk version instead. This is usually an admin operation, but it also happens when removing a file and temporarily in a commit. Thank you for your message. What a confusing feature! I could not imagine such a behavior without your explanation... rin
