Closing this out, it hasn't been commented on in 3 years, is far older
than that, and tg3 has been pretty heavily tested across many server
makes in the years since.
** Changed in: linux (Ubuntu)
Status: Triaged => Incomplete
** Changed in: dell-poweredge
Status: Triaged => Won't F
I was able to consistently reproduce this issue in Debian Wheezy by setting up
two Dell PowerEdge R620 servers directly connected and doing constant scp
transfer of large files back and forth while also setting the interface up &
down in a loop until it breaks (while [ true ]; do ip link set ${D
I forgot to mention, I don't experience this bug using CentOS only
Ubuntu and other Debian based distribution.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331513
Title:
14e4:165f tg3 eth1: transm
I am experiencing network issues with my Dell 12 Gen system as well. My
issues are with ssh. I have not tested for Toan's bug. Anyhow, every
time I connect via ssh I get random "Connection reset by peer" errors. I
have tried all the suggestion and fixes mention in this Bug report, but
nothing seem
@Wonko,
I've updated the driver to the latest version from broadcom.com, version
3.137h; and I am still experiencing a similar issue. However, when the driver
crashes, sometimes (70%) chance that the machine is useable, and another 30%
the machine is totally locked up.
The NIC i am using i
** Tags removed: bios-outdated-2.1.3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331513
Title:
14e4:165f tg3 eth1: transmit timed out, resetting on BCM5720
To manage notifications about this bug
All,
it's been a while since i've investigated this a bit further, but I have
just tried the same with the mainline 3.18 kernel. Result stays, machine
hangs within a couple of minutes if I do the exact same steps...
--
You received this bug notification because you are a member of Ubuntu
Bugs, w
Bernard,
We still haven't been able to reproduce the bug, but if you have time,
please see if the following patches applied to your kernel help:
[PATCH net v5 1/4] tg3: Limit minimum tx queue wakeup threshold
http://marc.info/?l=linux-netdev&m=140934527707734&w=2
[PATCH net v5 2/4] tg3: Fix tx_p
** No longer affects: linux-lts-saucy (Ubuntu)
** Tags added: bios-outdated-2.1.3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331513
Title:
14e4:165f tg3 eth1: transmit timed out, resetting on B
We tried the above patch, and ran the test again, but we got still get a
crash/reboot at approx the same time...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331513
Title:
14e4:165f tg3 eth1: tran
It was suggested to me that this may be relevant:
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=4d8fdc95c60e90d84c8257a0067ff4b1729a3757
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net
Just a small update, but without any good news. I never got a single
reply or inquiry from the kernel.org developers, neither the mailinglist
nor from the tg3 driver developers. It seems I've hit a dead end, as I'm
out of options (except for asking Dell for Intel NIC's for all my
servers until this
@christopher: I've mailed the maintainers.
@kent: Your setups looks okay. I have made a similar setup, and wasn't
able to reproduce the problem myself, even loading the exact database
dump. Even more, as the failing VM was a member of a two way mysql
master-master setup, we've installed a third ma
@wonko,
If there's any more specific information about the Xen VM, please let me
know. What I'm looking for are any special storage or network drivers
that the VM is using outside of what the standard Xen VM would use. If
there's nothing special about the VM in that respect, then I'll continue
w
Working on a reproducer. I've been able to set up the following:
A Xen HVM guest booting off of an iscsi-attached LVM LUN.
Guest is running Wheezy.
Dom0 is 12.04 on a PowerEdge R620, running the 3.11-based LTS kernels.
The eth1 NIC is being used for the iscsi traffic. This is one of the tg3-b
wonko, as advised in https://wiki.ubuntu.com/Bugs/Upstream/kernel did
you CC the maintainer and the last person to submit commits to tg3?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331513
Title:
The dump itselfs creates about 50 tables, spread over 3 databases, and
sums up in datasize to about 2.5 GB. So, it isn't the smallest one, but
neither a big one. We import the data in about 7 to 10 minutes.
The VM is a setup we have running many times. It is the second node of a
mysql master-maste
Understood. I didn't realize it was *that* specific. How big is the
database you are importing and is there anything special about the VM
itself? I'll try and get this as close as possible.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ub
Kent,
I've been search for a long time for a case to trigger this. I have no
idea why loading that specific sqldump into that specific mysql server,
on that specific VM is triggering the bug. We tried to rebuild the
situation ourself, and the only way to reproduce this, is by doing it on
the runni
Bernard,
I may also want to go ahead and get a soup-to-nuts list of how to set up
a machine to reproduce this. I've got an R620 and access to an iscsi
volume in my lab. I'm trying currently to reproduce on a simpler scale,
but, not having much luck at this time (which is no surprise).
--
You
Either one disabled doesn't make a difference, I can still crash the
system. It seems only SG is affecting the bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331513
Title:
14e4:165f tg3 eth1: t
No worries, i'm running the TSO and GSO tests now (tso disabled first,
gso still on). Just mentioned it in case you missed it, as it sits
hidden away a bit in between the other stuff.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
htt
Whoops, even if you hadn't updated the firmware, I gave you the wrong
link anyway.
I did see that the bug is fixed if you disable SG. I'm trying to isolate
the cause, and my colleague gave those suggestions. The goal is to fix
the bug, not leave you permanently without offloading capabilities.
Ye
Hey Daniel,
Thanks for the input.
The bug is "fixed" when disabling SG. Haven't tried disabling only GSO
or TSO, will do that next. However, we would like to use the device to
the full capacity; and use the offloading capabilities.
De firmware is listed below, I updated through the Lifecycle too
Bernard,
I've some quick suggestions from my colleague Narendra here at Dell to
pass on. First try disabling TSO. If that doesn't work, disable both GSO
and TSO. ethtool can be used to disable both GSO and TSO.
Also, I can't see what firmware version you have on the NIC. Can you
verify that it's
Mail sent, this is the tread
http://marc.info/?l=linux-netdev&m=140318618603899&w=2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331513
Title:
14e4:165f tg3 eth1: transmit timed out, resetting on
wonko, the issue you are reporting is an upstream one. Could you please
report this problem through the appropriate channel by following the
instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel
?
Please provide a direct URL to your e-mail to the mailing list once you
have made i
Installed
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc1-utopic/linux-
image-3.16.0-031600rc1-generic_3.16.0-031600rc1.201406160035_amd64.deb
which gives me ...
root@hostname:~# uname -a
Linux hostname 3.16.0-031600rc1-generic #201406160035 SMP Mon Jun 16 04:36:15
UTC 2014 x86_64 x86_6
A little in-between info.
I saw you added the bios-outdated tag. As this is a quick fix, I've
updated the bios first to 2.1.3 (latest as to my info), and re-ran the
test. It still crashes (this was with the 3.13.0-29-generic kernel). I
guess this would remove the bios-outdated-tag.
The tests with
29 matches
Mail list logo
