> > we use hightly loaded nfsv3/udp server with 5 fbsd nfs client > > all with 3.2-stable > > The most typical cause for these crashes is hardware-induced memory > corruption, caused by bad memory, a faulty or misconfigured motherboard > or an overclocked CPU. Are you performing any computational work on > the server? Does it see processes dying with signals 6, 10 or 11?
no and no ... this is typical panics of this server for different hardware (we upgrade hardware by changing system block once 1/1.5 years) last upgrade was in May, and nothing change with panics, then we regulary upgrade src's and kernel ... 3.2-stable nfs clients is more stable now (panics after 30-45 days) but nfs server still panics as general (with SMP it panics once/several hours) another feature of nfs server - increasing mbufs number: (this is with vfs.ffs.doreallocblks=0, when server works 8 days without panic) 8:15 up 3 days, 23:07, 5 users, load averages: 0.30, 0.36, 0.46 11083/11744 mbufs in use: 10827 mbufs allocated to data 142 mbufs allocated to packet headers 114 mbufs allocated to socket names and addresses 328/1078/12288 mbuf clusters in use (current/peak/max) 3624 Kbytes allocated to network (56% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines 9:12 up 4 days, 12:03, 5 users, load averages: 0.44, 0.45, 0.44 14092/14848 mbufs in use: 13822 mbufs allocated to data 156 mbufs allocated to packet headers 114 mbufs allocated to socket names and addresses 369/1078/12288 mbuf clusters in use (current/peak/max) 4012 Kbytes allocated to network (62% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines 6:04 up 5 days, 8:55, 11 users, load averages: 1.73, 1.56, 1.34 17391/17984 mbufs in use: 16925 mbufs allocated to data 352 mbufs allocated to packet headers 114 mbufs allocated to socket names and addresses 615/1116/12288 mbuf clusters in use (current/peak/max) 4480 Kbytes allocated to network (75% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines > > > server panics one/two time a day with: > > > > panic: ufs_dirbad: bad dir > > > > then reboot ... > > another panic: > > > > panic: vm_fault: fault on nofault entry, addr: ce4c9000 > > > > in this case server write: > > > > syncing disks... > > > > and hangs ... after seting vfs.ffs.doreallocblks=0 server works without > > panic about 8 days, and then reboot with: > > > > Fatal trap 12: page fault while in kernel mode > > ... > -- > \\ 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