On Thu, Mar 13, 2003 at 01:40:03PM -0600, [EMAIL PROTECTED] wrote: > TEST: > ===== > SAMBA STRESS OVER GIGABIT NETWORK: This is a simple > Read/Write/Compare/Delete kind of test over the network via Samba. Multiple > clients with multiple threads try to read/write/compare/delete(in a loop) a > finite sized file (64K block size) over samba for a prolonged period of time > in an effort to stress test the server. > > SERVER SIDE CONFIG: > =================== > ARCH: x86 > OS: RHL AS 2.1 > KERNEL: 2.4.9-e.3smp > SAMBA: 2.2.7-1.21as.i386.rpm (also tried RH AS2.1 stock version: > 2.2.1a-4.i386.rpm) > NIC: 2 ONBOARD GIG BCM5703(COPPER)ON A STATIC GEC TRUNK > RAM: 512 MB > CPU: Dual 2.66GHz CPU with HT ON (tried several different speed CPU's: 2.2, > 2.4, 3.06 etc) > SWAP: 2 GB > SCSI/RAID: Able to reproduce this on SCSI as well as RAID 0 (not tried other > RAID configs) > > CLIENT SIDE CONFIG: > =================== > SAMBA CLIENTS: Windows only (tried both NT4 and W2K). Please note that there > are *no* Linux clients trying to access the samba share. The clients are all > Windows and are all installed from one common image. > > DESCRIPTION OF FAILURES: > ======================== > The Stress Test Controller starts to show some Read/Write/Compare failures > anywhere from a 30 mins up to a 24 hour period into the test. These failures > continue to occur and eventually the server "locks up". Tried to enable > "nmi_watchdog" with serial console. No OOPS capture yet. I also tried > raising the samba debug level (went up to 3) , printk level raised to "7 4 1 > 7", SysRq enabled etc. None of the information I have captured so far gives > me any definite theory on why this is happening. What I do notice is that in > almost all the failures, the samba logs have references to "oplocks". Any > body has any ideas why this could be happening ? Any ideas for what I can do > further to troubleshoot. I have tried various other things that I have not > posted with this message to try and keep this post readable. Posted below > are a sample smbd.log, <samba_client_name>.log and my smb.conf file from one > of the recent failures. Any suggestions would be helpful.
Server 'locks up' represents a Linux kernel bug. No other option. Samba as a user level process should not be able to cause the kernel to freeze. On a 'perfect' network (no lost packets) oplock break failures are due to bugs in Windows clients not responding to asynchronous 'break' messages sent back to them over a TCP stream. What *exact* config are the Windows clients ? What service pack ? Jeremy Allison, Samba Team. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
