Well, the issue seems to have gone away as of this morning, but I am somewhat unsure as to why. Placement of some things were modified so as to allow shorter cables. Now there are 3' CAT6 cables everywhere except for the 15' cable between the two switches. All the cables are new, high quality 'tested' cables from a company nearby. The server is now running 2.6.22.6 with the 7.6.5 e1000 driver from intel.com and samba 3.0.26-1 ... and it seems to work. Samba will not disconnect, even with all 8 clients running unreasonable read/write loads and CRC and MD5 checksums of the transferred files all match. The issue therefore seems to have gone away, but the reason why still escapes me. I cannot believe that CAT5 cables under 10' in length were causing it, because if that were the case 1) it would've shown itself, I presume, from the beginning 2) I could name dozens of different locations which would be having the same problems Samba 3.0.25 was definitely part of the problem and I sent a nice nastygram to the debian maintainers, because -testing is not -unstable, last I checked. As to samba having any sort of data integrity capability, to the best of my knowledge that has never been the case. To answer further questions: I checked for file integrity with CRC/CRC32/MD5 checksum utilities. They used to fail fairly consistently, they have been fine all this morning. Here is my samba config, for reference, comments etc. stripped.
[global] workgroup = WORKGROUP server string = %h server wins support = yes dns proxy = yes name resolve order = host wins bcast log level = 1 max log size = 1000 syslog = 0 panic action = /usr/share/samba/panic-action %d encrypt passwords = true passdb backend = tdbsam obey pam restrictions = yes invalid users = root passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n . socket options = TCP_NODELAY IPTOS_LOWDELAY domain master = yes [backups] comment = Backup Share path = /var/archive/backups browseable = yes writeable = no guest ok = no write list = samba force user = samba [downloads] comment = Downloads Share path = /var/archive/downloads browseable = yes writeable = no guest ok = no read list = samba write list = samba force user = samba There is nothing there that I would deem unusual. Since the transition to 2.6 kernels I have been omitting the buffer statements in the socket options. I have one further question: what should I be doing with the TSO and flow control? As of now, TSO is on but flow control is off. I'd like to thank everyone who helped and I'll be trying to see if the realtek integrated NIC works next. Luigi Fabio - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
