Description of problem:
It appears that there is a problem with the networking subsystem. After what
could very well be heavy network activity I get:
"Kernel panic - not suncing: net/ipv4/tcp_timer.c:213: spin_lock (net/core/sock.
c:C9E41060) already locked by net/ipv4/tcp_ipv4.c/1793"
The machine, in addition to my workstation, is also an iptables firewall with
forwarding for several machines on my net.
Version-Release number of selected component (if applicable):
however, due to missing support for eata drivers I have added that from the .src
package and also done some more minor changes:
[ft@leia linux-2.6.10]$ diff .config configs/kernel-2.6.10-i686.config |grep ^\<
< # Linux kernel version: 2.6.10-prep
< # Sun Feb 6 01:25:19 2005
< # CONFIG_M686 is not set
< # CONFIG_PM is not set
< # CONFIG_ACPI is not set
< # CONFIG_CPU_FREQ is not set
< # CONFIG_HOTPLUG_PCI_SHPC_PHPRM_LEGACY is not set
Steps to Reproduce:
1. It happens in about 25% of apt-get update/upgrade tries, but also on some
no kernel panic
*** Bug 147898 has been marked as a duplicate of this bug. ***
*** Bug 147867 has been marked as a duplicate of this bug. ***
Just a "me too".
I've got exactly the same error with an unmodified kernel. It only happens when
working interactively over ssh on the machine. This machine has never heavy
iptables is enabled with my personal ruleset.
Just wanted to say me too, but I have RHEL4 and a bit different line number:
Kernel panic - not syncing: net/ipv4/tcp_timer.c:422:
locked by net/ipv4/tcp_ipv4.c/1790
I'm running kernel 2.6.9-5.0.3.EL.
I should note that I am using iptables as well and passing packets to a
userspace program via QUEUE.
I am running kernel 2.6.11-1.14_FC3. I want to throw in another "me too" on
this one. I have almost the exact same kernel panic... for me it occurs once or
twice a day... the system receives hourly backups from several sources, so
network load is high at times.
... This bug has been in the database for a few months now-- any progress?
... it's me again.. wanted to also mention that I am ALSO using a userspace
queuing program with packets sent from iptables via the QUEUE target.
As the OP, let me say "me too" to the me-toos. I also use a userspace queuing
program, dsl_qos_queue (which worked fine with the FC1 kernels - I asume that's
the one you use as well, Dan? :-). After disabling it I no longer have this type
of crash situation, but a much worse bandwith situation. :/
I also switch to NTP with FC3. Could there be a dead-lock due to NTP setting the
clock at some critical point in the execution-path, either internally in the
kernel or in the userspace program? I have been unable to test this part of my
theory since I need this particular system to be stable system.
In fact... not only am I using dsl_qos_queue... I wrote it =)
Is everyone here using a user-space QUEUE? Perhaps there is a problem with the
2.6.10+ kernels related to user space queuing.
The reason that I didn't notice this problem until recently is because of a
power outage that caused me to have to shut down and reboot, thus loading up a
newer kernel that had been previously installed by yum. For the past four
months prior to this recent reboot, I was running a 2.6.9 kernel.... I have
since reverted to the 2.6.9 kernel and I have observed stable operation so far.
Also, FWIW, I have been running NTP for a long time now, so there is no problem
with NTP and dsl_qos_queue, at least with 2.6.9 and earlier kernels.
How should we go about debugging this problem?
I think we should take a look at what changes were made between the .9 and the
.10 kernel. This might help us narrow down the search... especially if we find
changes that were made to the code were the panic is being reported in...
(In reply to comment #9)
> Also, FWIW, I have been running NTP for a long time now, so there is no problem
> with NTP and dsl_qos_queue, at least with 2.6.9 and earlier kernels.
Exactly which 2.6.9 kernel? Is it an upstream one or a Red Hat one (if so, which?)
This bug is still present on 2.6.11-1.27_FC3, which is the latest Red Hat Fedora
Core 3 kernel.
(In reply to comment #10)
> (In reply to comment #9)
> > Also, FWIW, I have been running NTP for a long time now, so there is no problem
> > with NTP and dsl_qos_queue, at least with 2.6.9 and earlier kernels.
> Exactly which 2.6.9 kernel? Is it an upstream one or a Red Hat one (if so,
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
I just upgraded to the 2.6.12-1.1372_FC3 kernel, and I turned the QUEUE-using
program back on. Generally, the system will not remain stable for more than 24
hours if the bug is still present. I will report back as soon as I have a
problem, or in a few days if trouble-free.
Still running 2.6.12-1.1.1372_FC3 here with the QUEUE program back in use and
system is stable once again. Looks like whatever was done for this kernel
release fixed the problem I was having with the past few releases. Normally
running the QUEUE program would cause the system to panic within 24 hours-- it's
been almost a week now and system is still solid.
I just want to say that I have also been running a QUEUE program for a few days
and it seems to be stable. I'm running kernel-2.6.12-1.1398_FC4 (recompilled for
my needs tho').