From: "L F" <lfabio.linux@gmail.com>
To: "Tantilov, Emil S" <emil.s.tantilov@intel.com>
Cc: "Florian Weimer" <fweimer@bfk.de>,
"Urs Thuermann" <urs@isnogud.escape.de>,
"Bill Fink" <billfink@mindspring.com>,
"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
"Kok, Auke-jan H" <auke-jan.h.kok@intel.com>,
"James Chapman" <jchapman@katalix.com>,
netdev@vger.kernel.org
Subject: Re: e1000 driver and samba
Date: Wed, 19 Sep 2007 10:53:01 -0400 [thread overview]
Message-ID: <780b6f780709190753qd52d099id937a6c75e5d560e@mail.gmail.com> (raw)
In-Reply-To: <08FE5CC30C9A3F41BF819A502CF7BF6E02045257@fmsmsx411.amr.corp.intel.com>
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
next prev parent reply other threads:[~2007-09-19 14:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-14 2:04 e1000 driver and samba L F
2007-09-14 17:18 ` Kok, Auke
2007-09-14 18:40 ` L F
2007-09-14 20:59 ` Kok, Auke
2007-09-15 0:37 ` L F
2007-09-15 5:09 ` Bill Fink
2007-09-15 12:27 ` L F
2007-09-15 12:44 ` L F
2007-09-15 17:44 ` James Chapman
2007-09-15 19:07 ` Kok, Auke
2007-09-16 4:06 ` L F
2007-09-16 5:04 ` Kok, Auke
2007-09-17 16:42 ` L F
2007-09-17 17:02 ` Kok, Auke
2007-09-17 18:58 ` L F
2007-09-17 21:01 ` Brandeburg, Jesse
2007-09-18 6:03 ` Bill Fink
2007-09-18 7:45 ` Urs Thuermann
2007-09-18 8:47 ` Bill Fink
2007-09-18 13:39 ` Florian Weimer
2007-09-18 16:32 ` L F
2007-09-18 17:04 ` Tantilov, Emil S
2007-09-19 14:53 ` L F [this message]
2007-09-20 2:51 ` Bill Fink
2007-09-21 14:08 ` L F
2007-09-20 4:53 ` Bill Fink
2007-09-18 16:44 ` Bill Fink
2007-09-17 18:02 ` Rick Jones
2007-09-17 18:51 ` Kok, Auke
2007-09-16 16:24 ` James Chapman
2007-09-16 20:03 ` Kok, Auke
2007-09-16 4:07 ` L F
2007-09-14 18:26 ` Francois Romieu
2007-09-14 18:41 ` L F
-- strict thread matches above, loose matches on Subject: below --
2007-09-20 23:30 Bruce Cole
2007-09-21 14:13 ` L F
2007-09-21 18:21 ` Bruce Cole
2007-09-21 21:49 ` Francois Romieu
2007-09-21 22:01 ` Bruce Cole
2007-09-21 22:41 ` Francois Romieu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=780b6f780709190753qd52d099id937a6c75e5d560e@mail.gmail.com \
--to=lfabio.linux@gmail.com \
--cc=auke-jan.h.kok@intel.com \
--cc=billfink@mindspring.com \
--cc=emil.s.tantilov@intel.com \
--cc=fweimer@bfk.de \
--cc=jchapman@katalix.com \
--cc=jesse.brandeburg@intel.com \
--cc=netdev@vger.kernel.org \
--cc=urs@isnogud.escape.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).