Interesting enough, I started having this same ages-old problem after a
recent upgrade to 2.6.28-16-server kernel. The system performed without
a single issue for three months before that, including under very heavy
load. It runs Ubuntu Server 9.04 on dual-CPU Supermicro motherboard with
Quad-Core
Amspilot, interesting that after so much idle time on this ticket, you
and I should encounter this bug within a week's time.
I too just experienced this bug while copying a large file (kvm disk
image) via rsync; 2.6.28-13-server under Ubuntu 9.04 (Jaunty).
This is more of a "me too" post. The NI
Problem still exists also on my system with kernel 2.6.28-15 with speeds up to
and over 500 Mbit/s
Single links and also with Dual bonded 802.1q uplinks
--
Random pauses when transferring data at gigabit speeds with forcedeth driver
https://bugs.launchpad.net/bugs/130075
You received this bug no
Hm, well, since the last post I had another install of Gutsy. (Don't ask
- mostly to apply the lessons learned in my first ever setting-up of a
RAID system, which I managed to learn without losing data!) Anyway, at
the time I did that I'd forgotten all about this bug and so didn't set
noapic... But
ok ... my problem seems to be a hardware issue, since there are many
people having this problem under xp as well.
see for example: http://vip.asus.com/forum/view.aspx?SLanguage=en-
us&id=20071028232147828&board_id=1&model=M2N-VM%20DVI&page=1&count=44
--
Random pauses when transferring data at gi
>From the last few sets of comments this bug appears to be resolved (or a
hardware issue for ccc1). I'm going to close this report for now.
Thanks.
** Changed in: linux (Ubuntu)
Status: Incomplete => Fix Released
** Changed in: linux-source-2.6.22 (Ubuntu)
Status: Confirmed => Fix
I can confirm this bug in gusty.
I'm using an asus m2n-vm dvi mainboard. It suffice to pull some data from a
fast ftpserver and my box locksup complety. These lockups DON'T occur using the
gusty live-cd nor using a 7.04 live-cd. So it looks like the bug got introduced
with some update.
--
Ran
I'm getting this problem too, on Athlon64 Gutsy. I get the message:
eth0: too many iterations (6) in nv_nic_irq.
And the network hangs, when a little while after I attempt a large
transfer operation across the network.
The *different* thing is, I've had this machine for months, running
Feisty, t
** Tags removed: hardy-alpha2
--
Random pauses when transferring data at gigabit speeds with forcedeth driver
https://bugs.launchpad.net/bugs/130075
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubunt
I haven't had time to verify the i386 Desktop build of alpha2, but I can
confirm that the AMD64 server build of alpha2 no longer exhibits this problem.
I copied 3TB of data over NFS at full speed with no problems.
- "Leann Ogasawara" <[EMAIL PROTECTED]> wrote:
> Hardy Heron Alpha2 was recently
Hardy Heron Alpha2 was recently released. It contains an updated
version of the kernel. You can download and try the new Hardy Heron
Alpha2 release from http://cdimage.ubuntu.com/releases/hardy/alpha-2/ .
You should be able to then test the new kernel via the LiveCD. If you
can, please verify if
The Hardy Heron Alpha2 release will be coming out soon (around Dec 20).
It will have an updated version of the kernel. It would be great if you
could test with this new release if this issue still exists. I'll be
sure to update this report when Alpha2 is available. Thanks!
** Also affects: linu
The fact that Rodrigo fixed this by using the "noapic" boot option led
me to do some more reading into APIC, and I am convinced that there is a
reasonable chance that this problem is due to poor APIC support on my
motherboard, which, if true, could also validate Miravlix' theory.
Unfortunately I
** Changed in: linux-source-2.6.22 (Ubuntu)
Assignee: (unassigned) => Ubuntu Kernel Team (ubuntu-kernel-team)
** Tags added: hardy-kernel-candidate
** Tags removed: needs-devrelease-testing
--
Random pauses when transferring data at gigabit speeds with forcedeth driver
https://bugs.launchp
I am assigning this bug to the 'ubuntu-kernel-team' per their bug
policy. For future reference you can learn more about their bug policy
at https://wiki.ubuntu.com/KernelTeamBugPolicies .
** Changed in: linux-source-2.6.20 (Ubuntu)
Assignee: (unassigned) => Ubuntu Kernel Team (ubuntu-kernel-
I have the same problem both with NFS or PVFS high usage.
Disable SMP isn't possible! Actually I have 2 solution:
1) options forcedeth max_interrupt_work=200;
2) ro quiet splash noapic apic=off in grub's menu.lst.
The second still show the message "too many iterations (6) in
nv_nic_irq" but I rea
for me the error is not occuring any more when I load the module with
options forcedeth max_interrupt_work=200
but it seems to be ignored during boot. So I have do the following in
/etc/rc.local:
rmmod forcedeth && modprobe forcedeth && /etc/init.d/networking restart
now iperf runs at full gig
I'm running Gutsy with all the latest updates (Ubuntu 2.6.22-14.46-generic) and
I experience a similar problem. When I try to transfer large files (~1GB) from
a samba share the PC will do one of two things, either completely lock up or
the nic will still work, but with a huge amount of latency (
** Attachment added: "lspci -vvn"
http://launchpadlibrarian.net/10219101/lspci.log
--
Random pauses when transferring data at gigabit speeds with forcedeth driver
https://bugs.launchpad.net/bugs/130075
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bu
The same problem here running latest Gutsy (2.6.22-14-generic fully
patched) standard config with fixed IP. While watching a HD x264 stream
(continuous stream of 1 GB in 45 minutes), the network crashed without
being able to recover (/etc/init.d/networking restart nor ifdown eth0;
ifup eth0 didn't
I have to agree that this doesn't look like a hardware problem. If it were,
then how would one explain different kernels behaving differently?
Parenthetically, I have posted some throughput benchmarks for a handful of
nics on the m0n0wall forum for any interested. And no, I have never seen the
nfo
More testing with these boards and latest Gutsy (2.6.22-14-generic x86)
yields the following observations above and beyond those previously
reported:
1. It still locks up under Gutsy latest (I can't tell any change
between 2.6.22-12 and 2.6.22-14). Someone should probably report this
as a proble
I've been testing with Gutsy latest on these boards, and some moderately
good news is that with 2.6.22-12-generic, it seems to take much longer
for the machine to lockup. Using Feisty's 2.6.20 kernel, and the
aforementioned iperf test, it would hang almost instantly. With Gutsy,
it takes 30-60 mi
I just returned one of these RMA. Now I'm wondering if my problems
with it were actually due to this bug. I suspect not entirely though,
as this card sometimes didn't work right off a fresh boot.
http://www.intel.com/network/connectivity/products/pro1000pt_desktop_adapter.htm
On 9/29/07, BullCree
> And how can Nvidia market this as their stable "Business Platform"?
> I'm feeling cheated. If Steen's post is correct, then my motherboard
> clearly doesn't do what it claims to do.
I'm ordering a couple of these to see if just disabling the nforce NICs
on these boards will result in a stable sy
Do I understand correctly that this will be an issue with my
motherboard as long as I am using more than one core of a multicore
cpu?
How in the world did my motherboard make it onto AMD's list of
recommended motherboards for a dual-core AMD cpu?
And how can Nvidia market this as their stable "Bu
I try to boot with the nosmp option to test this and 2.6.20-16-generic
just hangs shortly into the boot (no output on any of the virtual
screens). Any ideas on how to work around? I don't really see nosmp as
a viable solution, but am willing to at least validate it as an option
for some. If this
Your actually fighting two issues here.
The "to many iterations" part is harmless and can be ignored, it has
nothing to do with why the system crashes.
Your system is crashing because an IRQ gets disabled, when an IRQ get
disabled, that means anything using it stops talking with the kernel, if
th
iperf -c machine1 -d doesn't lock mine up, but adding "-p 2" (any
number of multiple threads) will do it every time, although not
necessarily right away.
And yes, this makes the forcedeth driver virtually useless on a
gigabit network. My findings were the same, only a reboot will bring
the interfa
I've played around with it a bit more, and even with the options
max_interrupt_work=20 set in /etc/modprobe.d/forcedeth, it still
happens. Only additional thing to report, is I happened upon an easy
way to reproduce the hangup every time:
1. Login to machine1 which has a gigabit ethernet card in
** Changed in: linux-source-2.6.22 (Ubuntu)
Importance: Undecided => Medium
Assignee: Brian Murray (brian-murray) => (unassigned)
Status: Incomplete => Confirmed
--
Random pauses when transferring data at gigabit speeds with forcedeth driver
https://bugs.launchpad.net/bugs/130075
Y
An hour or so into the transfer, using the gutsy forcedeth.ko - the
machine locked up and eth0 stopped responding just like it was doing
with the default feisty version of the module. This is a fairly serious
bug - so I hope someone can escalate it so it gets looked at and
minimally fixed for gut
FWIW, I downloaded the gutsy GIT kernel, built it, and replaced the
forcedeth.ko on my feisty systems with the newer one. I still get a few
of the:
eth0: too many iterations (6) in nv_nic_irq messages
but it doesn't appear to hang anymore under heavy load. I'll be stress
testing it today by cop
I just ran into this bug and it almost cost me data with feisty latest!
For some reason when the forcedeth ethernet adapter locked up, it also
locked up two out of six of my sata ports (I'm presuming because of some
PCI bus issue). Luckily it was raid6, so the array is still functional,
but it cou
** Tags added: needs-devrelease-testing
--
Random pauses when transferring data at gigabit speeds with forcedeth driver
https://bugs.launchpad.net/bugs/130075
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing
I'm getting this message in Edubuntu Feisty AMD64 while doing tests with
iperf on a gigabit link. Both iperf client and server are using the
forcedeth driver on identical nic/motherboards. While the failing driver
is running in the OS mentioned above, I've had no trouble on the second
machine runni
Thank you for taking the time to report this bug and helping to make Ubuntu
better. The issue that you reported is one that should be reproducable with
the live environment of the Desktop CD of the development release - Gutsy
Gibbon. It would help us greatly if you could test with it so we can
** Also affects: linux-source-2.6.22 (Ubuntu)
Importance: Undecided
Status: New
--
Random pauses when transferring data at gigabit speeds with forcedeth driver
https://bugs.launchpad.net/bugs/130075
You received this bug notification because you are a member of Ubuntu
Bugs, which is the
Additionally, this bug may be related to #107215.
--
Random pauses when transferring data at gigabit speeds with forcedeth driver
https://bugs.launchpad.net/bugs/130075
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bug
Please disregard the comment "more or less randomly". It should be "more
or less randomly when the NIC is heavily utilized".
--
Random pauses when transferring data at gigabit speeds with forcedeth driver
https://bugs.launchpad.net/bugs/130075
You received this bug notification because you are a
40 matches
Mail list logo
