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 coul
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]> :
> >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.
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 agree
On 9/20/07, Bruce Cole <[EMAIL PROTECTED]> wrote:
> Yes, that *was* the common recommendation. But recently I narrowed down the
> realtek performance problem most commonly seen with samba (but also applicable
> to other TCP applications), and I also narrowed down the fix as well.
>
> The current f
On 9/19/07, Bill Fink <[EMAIL PROTECTED]> wrote:
> Just my personal opinion, but unless you want to do more testing,
> since you now seem to have a working setup, I would tend to leave
> it the way it is.
Quite sensible, yes. Performance even seems to be good - I am getting
40-40MBps reads and 24-2
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 applicable
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 switche
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 opini
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
'test
t: Re: 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_multica
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 16-
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
tx_e
* 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 fli
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 (a
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
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 y
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, '
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 prematur
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.
>>
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
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 XX
> 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")
fro
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
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 box so the packets have
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 re
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 o
> >>> 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 counte
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
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
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 or
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 ment
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,
> 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
W
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 d
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
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 i
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
L F wrote:
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
39 matches
Mail list logo
