daily CVS update output
Updating src tree: P src/crypto/external/bsd/netpgp/bin/netpgpverify/Makefile P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/Makefile.bsd P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/Makefile.in P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/bignum.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/bn.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/bzlib.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/digest.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/digest.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/libverify.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/md5.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/md5c.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/misc.c U src/crypto/external/bsd/netpgp/dist/src/netpgpverify/noversion.asc P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/pgpsum.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/rmd160.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/rmd160.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/rsa.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/rsa.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/sha1.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/sha1.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/sha2.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/sha2.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/tiger.c P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/tiger.h P src/crypto/external/bsd/netpgp/dist/src/netpgpverify/verify.h P src/crypto/external/bsd/openssh/dist/umac.c P src/doc/HACKS P src/libexec/ld.elf_so/Makefile P src/libexec/ld.elf_so/headers.c P src/libexec/ld.elf_so/map_object.c P src/libexec/ld.elf_so/reloc.c P src/libexec/ld.elf_so/rtld.h P src/share/mk/bsd.README P src/share/mk/bsd.own.mk P src/share/mk/bsd.sys.mk P src/sys/arch/amd64/conf/GENERIC P src/sys/arch/i386/i386/cpu_in_cksum.S P src/sys/arch/x68k/x68k/machdep.c P src/sys/dev/pci/if_wm.c P src/usr.bin/make/meta.c Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Wed Jun 15 03:01:31 2016 SUP Scan for current completed at Wed Jun 15 03:01:48 2016 SUP Scan for mirror starting at Wed Jun 15 03:01:48 2016 SUP Scan for mirror completed at Wed Jun 15 03:04:42 2016 Updating release-6 src tree (netbsd-6): Updating release-6 xsrc tree (netbsd-6): Running the SUP scanner: SUP Scan for release-6 starting at Wed Jun 15 03:06:55 2016 SUP Scan for release-6 completed at Wed Jun 15 03:07:03 2016 Updating release-7 src tree (netbsd-7): U doc/CHANGES-7.1 P external/gpl3/gcc/dist/gcc/cp/Make-lang.in P external/gpl3/gcc/dist/gcc/cp/cfns.gperf P external/gpl3/gcc/dist/gcc/cp/cfns.h P external/gpl3/gcc/dist/gcc/cp/except.c P sys/dev/pci/ixgbe/README P sys/dev/pci/ixgbe/ixgbe.c P sys/dev/pci/ixgbe/ixgbe.h P sys/dev/pci/ixgbe/ixgbe_82598.c P sys/dev/pci/ixgbe/ixgbe_82599.c P sys/dev/pci/ixgbe/ixgbe_api.c P sys/dev/pci/ixgbe/ixgbe_api.h P sys/dev/pci/ixgbe/ixgbe_common.c P sys/dev/pci/ixgbe/ixgbe_common.h U sys/dev/pci/ixgbe/ixgbe_dcb.c U sys/dev/pci/ixgbe/ixgbe_dcb.h U sys/dev/pci/ixgbe/ixgbe_dcb_82598.c U sys/dev/pci/ixgbe/ixgbe_dcb_82598.h U sys/dev/pci/ixgbe/ixgbe_dcb_82599.c U sys/dev/pci/ixgbe/ixgbe_dcb_82599.h P sys/dev/pci/ixgbe/ixgbe_osdep.h P sys/dev/pci/ixgbe/ixgbe_phy.c P sys/dev/pci/ixgbe/ixgbe_phy.h P sys/dev/pci/ixgbe/ixgbe_type.h P sys/dev/pci/ixgbe/ixgbe_vf.c P sys/dev/pci/ixgbe/ixgbe_x540.c P sys/dev/pci/ixgbe/ixgbe_x540.h P sys/dev/pci/ixgbe/ixv.c P sys/dev/pci/ixgbe/ixv.h Updating release-7 xsrc tree (netbsd-7): Running the SUP scanner: SUP Scan for release-7 starting at Wed Jun 15 03:09:17 2016 SUP Scan for release-7 completed at Wed Jun 15 03:09:24 2016 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 53596203 Jun 15 03:11 ls-lRA.gz
Re: nfs client kernel crash
On Jun 14, 2:07pm, 6b...@6bone.informatik.uni-leipzig.de (6b...@6bone.informatik.uni-leipzig.de) wrote: -- Subject: Re: nfs client kernel crash | On Tue, 14 Jun 2016, Christos Zoulas wrote: | | > Yes, that helps. No crash though? | | So far, no crash. But this often takes several days. Ok. Let's take a look at the EINTR issue then. christos
Re: nfs client kernel crash
On Tue, 14 Jun 2016, Christos Zoulas wrote: Yes, that helps. No crash though? So far, no crash. But this often takes several days. Uwe
Re: nfs client kernel crash
On Jun 14, 12:41pm, 6b...@6bone.informatik.uni-leipzig.de
(6b...@6bone.informatik.uni-leipzig.de) wrote:
-- Subject: Re: nfs client kernel crash
| On Tue, 14 Jun 2016, 6b...@6bone.informatik.uni-leipzig.de wrote:
|
| > I applied the patch. For testing I have started a "rm -rf" on a large
| > directory tree. dmesg reports:
| >
| > nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again
| > nfs server 172.18.86.13:/vol/vol_bsd_2: not responding
| > nfs server 172.18.86.13:/vol/vol_bsd_2: not responding
| > nfs server 172.18.86.13:/vol/vol_bsd_2: not responding
| > nfs server 172.18.86.13:/vol/vol_bsd_2: not responding
| > nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again
| > nfs server 172.18.86.13:/vol/vol_bsd_2: not responding
| > nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again
| > ...
| >
|
| If it helps: 'rm -rf' reports randomly "Interrupted system call"
I think it is this:
while ((error = nfs_connect(nmp, rep, &lwp0)) != 0) {
if (error == EINTR || error == ERESTART)
return (EINTR);
kpause("nfscn2", false, hz, NULL);
}
Can you put a printf to verify?
christos
Re: nfs client kernel crash
On Jun 14, 12:41pm, 6b...@6bone.informatik.uni-leipzig.de (6b...@6bone.informatik.uni-leipzig.de) wrote: -- Subject: Re: nfs client kernel crash | If it helps: 'rm -rf' reports randomly "Interrupted system call" Yes, that helps. No crash though? christos
Re: nfs client kernel crash
On Jun 14, 8:32am, 6b...@6bone.informatik.uni-leipzig.de (6b...@6bone.informatik.uni-leipzig.de) wrote: -- Subject: Re: nfs client kernel crash | On Mon, 13 Jun 2016, Christos Zoulas wrote: | | > Can you try this? The first one might not apply cleanly since I changed | > the loop, but it should work just the same if you put the spl stuff around | > the old loop. | | I applied the patch. For testing I have started a "rm -rf" on a large | directory tree. dmesg reports: | | nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again | nfs server 172.18.86.13:/vol/vol_bsd_2: not responding | nfs server 172.18.86.13:/vol/vol_bsd_2: not responding | nfs server 172.18.86.13:/vol/vol_bsd_2: not responding | nfs server 172.18.86.13:/vol/vol_bsd_2: not responding | nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again | nfs server 172.18.86.13:/vol/vol_bsd_2: not responding | nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again | ... I've seen that too... | The behavior already exists prior apply the patch. I think that the | crash will also reoccur. | | The storage is a netapp nfs volume. The volume is only mounted at my | server. On the storage there are no load problems. Did it crash? christos
Re: nfs client kernel crash
On Tue, 14 Jun 2016, 6b...@6bone.informatik.uni-leipzig.de wrote: I applied the patch. For testing I have started a "rm -rf" on a large directory tree. dmesg reports: nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again nfs server 172.18.86.13:/vol/vol_bsd_2: not responding nfs server 172.18.86.13:/vol/vol_bsd_2: not responding nfs server 172.18.86.13:/vol/vol_bsd_2: not responding nfs server 172.18.86.13:/vol/vol_bsd_2: not responding nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again nfs server 172.18.86.13:/vol/vol_bsd_2: not responding nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again ... If it helps: 'rm -rf' reports randomly "Interrupted system call" Regards Uwe
Re: needbuf ?
On Sun, Jun 12, 2016 at 11:11:08PM +0100, Patrick Welche wrote: > I manage to repeatably freeze (100% idle) a -current/amd64 box with > (sysutils/diskscrub) > > # scrub /dev/raid0a You may find rraid0a works better. At this point the block devices are useful only for mounting and they should probably all be folded together. Writing to the block device *shouldn't* deadlock, but it's not really expected to work... -- David A. Holland dholl...@netbsd.org
