L F wrote:
Aha. This doesn't seem to be in mr. Romieu's patch above: should it go
in on top of that?
His newer
0002-r8169-workaround-against-ignored-TxPoll-writes-8168.patch
does the same thing as the older quoted version, and is also
included in the roll-up patch he pointed you to.
I
Bruce Cole [EMAIL PROTECTED] :
If you look for it on the Realtek cards, there had been sporadic
Nissues up to late 2005. The solution posted universally was 'change
card'.
Yes, that *was* the common recommendation.
There was no such thing as a universal solution to sporadic issues.
[...]
Francois Romieu wrote:
Bruce Cole [EMAIL PROTECTED] :
If you look for it on the Realtek cards, there had been sporadic
Nissues up to late 2005. The solution posted universally was 'change
card'.
Yes, that *was* the common recommendation.
There was no such thing as a universal
Bruce Cole [EMAIL PROTECTED] :
Francois Romieu wrote:
[...]
Can you be more specific ?
Yes per the reference I gave:
http://www.spinics.net/lists/netdev/msg40384.html
[...]
Ok, I wondered if you had found something between the start_xmit and the
Tx completion code.
[...]
I could
If you look for it on the Realtek cards, there had been sporadic
Nissues up to late 2005. The solution posted universally was 'change
card'.
Yes, that *was* the common recommendation. But recently I narrowed down the
realtek performance problem most commonly seen with samba (but also
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
On Wed, 19 Sep 2007, L F wrote:
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.
Just my personal opinion,
On Wed, 19 Sep 2007, L F wrote:
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.
On Mon, 17 Sep 2007, Brandeburg, Jesse wrote:
L F wrote:
On 9/17/07, Kok, Auke [EMAIL PROTECTED] wrote:
The statistic we were looking at _will_ increase when running in
half duplex, but if it increases when running in full duplex might
indicate a hardware failure. Probably you have fixed
Bill Fink [EMAIL PROTECTED] writes:
It may also be a useful test to disable hardware TSO support
via ethtool -K ethX tso off.
All suggestions here on the list, i.e. checking for flow control,
duplex, cable problems, etc. don't explain (at least to me) why LF
sees file corruption. How can a
On 18 Sep 2007, Urs Thuermann wrote:
Bill Fink [EMAIL PROTECTED] writes:
It may also be a useful test to disable hardware TSO support
via ethtool -K ethX tso off.
All suggestions here on the list, i.e. checking for flow control,
duplex, cable problems, etc. don't explain (at least to
* Urs Thuermann:
How can a corrupted frame pass the TCP checksum check?
The TCP/IP checksums are extremely weak. If the corruption is due to
defective SRAM or something like that, it's likely that it causes an
error pattern which is 16-bit-aligned. And an even number of
16-bit-aligned bit
This is the latest ethtool -S :
beehive:~# ethtool -S eth4
NIC statistics:
rx_packets: 33491526
tx_packets: 41410384
rx_bytes: 28384277429
tx_bytes: 46178788616
rx_broadcast: 3144
tx_broadcast: 2068
rx_multicast: 79
tx_multicast: 0
rx_errors: 0
On Tue, 18 Sep 2007, Florian Weimer wrote:
* Urs Thuermann:
How can a corrupted frame pass the TCP checksum check?
The TCP/IP checksums are extremely weak. If the corruption is due to
defective SRAM or something like that, it's likely that it causes an
error pattern which is
: e1000 driver and samba
This is the latest ethtool -S :
beehive:~# ethtool -S eth4
NIC statistics:
rx_packets: 33491526
tx_packets: 41410384
rx_bytes: 28384277429
tx_bytes: 46178788616
rx_broadcast: 3144
tx_broadcast: 2068
rx_multicast: 79
tx_multicast: 0
To me it suggests that your speed is not full-duplex. Check `ethtool eth0`
output
and see if your link is full duplex or not. also check previous kernel
messages
and see what the e1000 driver posted there for link speed messages (as in
e1000:
Link is UP speed XXX duplex YYY)
from dmesg:
L F wrote:
To me it suggests that your speed is not full-duplex. Check `ethtool eth0`
output
and see if your link is full duplex or not. also check previous kernel
messages
and see what the e1000 driver posted there for link speed messages (as in
e1000:
Link is UP speed XXX duplex YYY)
Kok, Auke wrote:
L F wrote:
tx_deferred_ok: 486
this one I wonder about, and might cause delays, I'll have to look
up what it exactly could implicate though.
Please do and let me know. samba 3.0.26 helped, but the issue is
still there.
ok, from the spec: tx_deferred_ok is what is in the
Rick Jones wrote:
Kok, Auke wrote:
L F wrote:
tx_deferred_ok: 486
this one I wonder about, and might cause delays, I'll have to look
up what it exactly could implicate though.
Please do and let me know. samba 3.0.26 helped, but the issue is
still there.
ok, from the spec:
On 9/17/07, Kok, Auke [EMAIL PROTECTED] wrote:
The statistic we were looking at _will_ increase when running in half duplex,
but if it increases when running in full duplex might indicate a hardware
failure. Probably you have fixed the issue with the CAT6 cable.
Uhm, 'fixed' may be premature: I
L F wrote:
On 9/17/07, Kok, Auke [EMAIL PROTECTED] wrote:
The statistic we were looking at _will_ increase when running in
half duplex, but if it increases when running in full duplex might
indicate a hardware failure. Probably you have fixed the issue with
the CAT6 cable.
Uhm, 'fixed' may
James Chapman wrote:
Kok, Auke wrote:
James Chapman wrote:
Kok, Auke wrote:
rx_long_byte_count: 34124849453
Are these long frames expected in your network? What is the MTU of
the transmitting clients? Perhaps this might explain why reads work
(because data is coming from the Linux
On 9/15/07, Bill Fink [EMAIL PROTECTED] wrote:
Would it be worth a shot to try disabling the receiver hardware
checksumming (ethtool -K ethX rx off)?
I just did, unfortunately it doesn't seem to change much.
In the various attempts, however, I seem to have improved something,
maybe. As I
I also upgraded to samba-3.0.26-1 and so far the problem seems
significantly less frequent and limited, unfortunately, to the
'silent' corruption. I am still running with HW checksumming off, with
a new cable (cat6, even though it's 50cm long, so I could probably be
running chicken wire), on the
Kok, Auke wrote:
L F wrote:
On 9/14/07, Kok, Auke [EMAIL PROTECTED] wrote:
this slowness might have been masking the issue
That is possible. However, it worked for upwards of twelve months
without an error.
I have not yet seen other reports of this issue, and it would be
interesting to
see
James Chapman wrote:
Kok, Auke wrote:
L F wrote:
On 9/14/07, Kok, Auke [EMAIL PROTECTED] wrote:
this slowness might have been masking the issue
That is possible. However, it worked for upwards of twelve months
without an error.
I have not yet seen other reports of this issue, and it would
tx_deferred_ok: 486
this one I wonder about, and might cause delays, I'll have to look up what it
exactly could implicate though.
Please do and let me know. samba 3.0.26 helped, but the issue is still there.
those are not long frames but the number of bytes the hardware counted in
On 9/15/07, James Chapman [EMAIL PROTECTED] wrote:
Are these long frames expected in your network? What is the MTU of the
transmitting clients? Perhaps this might explain why reads work (because
data is coming from the Linux box so the packets have smaller MTU) while
writes cause delays or
L F wrote:
tx_deferred_ok: 486
this one I wonder about, and might cause delays, I'll have to look
up what it exactly could implicate though.
Please do and let me know. samba 3.0.26 helped, but the issue is
still there.
ok, from the spec: tx_deferred_ok is what is in the DC stats register. DC
On 9/14/07, Francois Romieu [EMAIL PROTECTED] wrote:
For the 8169 or the 8110, try 2.6.23-rc6 +
http://www.fr.zoreil.com/people/francois/misc/20070903-2.6.23-rc5-r8169-test.patch
Thank you, I will give that a whirl also, because there are some
machine builds which will not have Intel boards in
L F [EMAIL PROTECTED] :
[...]
Now, the machine worked when it was using an onboard Realtek 8169
chipset on a 945G board from ASUS, but it worked slowly. I upgraded to
a P965 chipset, started using the realtek driver for the 8110B on that
board.. and started getting consistent samba errors. I
On 9/14/07, Kok, Auke [EMAIL PROTECTED] wrote:
this slowness might have been masking the issue
That is possible. However, it worked for upwards of twelve months
without an error.
I have not yet seen other reports of this issue, and it would be interesting
to
see if the stack or driver is
L F wrote:
On 9/14/07, Kok, Auke [EMAIL PROTECTED] wrote:
this slowness might have been masking the issue
That is possible. However, it worked for upwards of twelve months
without an error.
I have not yet seen other reports of this issue, and it would be interesting to
see if the stack or
can you describe your setup a bit more in detail? you're writing from a linux
client to a windows smb server? or even to a linux server? which end sees the
connection drop? the samba server? the samba linux client?
Certainly.
I have a LAN, with two switches in a stack. There currently are 7
On Fri, 14 Sep 2007, L F wrote:
can you describe your setup a bit more in detail? you're writing from a
linux
client to a windows smb server? or even to a linux server? which end sees
the
connection drop? the samba server? the samba linux client?
Certainly.
I have a LAN, with two
Folks,
I've been playing with multiple gigabit ethernet drivers to get samba
3.0.25+ to work reliably. The situation is as follows.
I have a network, one of the machines on the network is a
server/firewall. It contains an Intel PRO1000 dual port PCI Express
card and runs Debian-testing.
The
36 matches
Mail list logo
