Guys,
one of our boxes just died with the following error:
kernel panic - not syncing: fs/block_dev.c:396: spin_lock (fs/block_dev.c:c0361c0) already locked by fs/block_dev.c/287.
The system's an LVS running CentOS 4.3:
centos-release-4-3.2 kernel-2.6.9-34.EL ipvsadm-1.24-6 heartbeat-1.2.3.cvs.20050927-1.centos4
I note that there's a bug report filed related to CentOS 4.2:
http://bugs.centos.org/view.php?id=1201&nbn=7
I was just wondering, would you like a bug report filed for this?
Will.
On Fri, 2006-04-28 at 16:41 +0100, Will McDonald wrote:
Guys,
one of our boxes just died with the following error:
kernel panic - not syncing: fs/block_dev.c:396: spin_lock (fs/block_dev.c:c0361c0) already locked by fs/block_dev.c/287.
The system's an LVS running CentOS 4.3:
centos-release-4-3.2 kernel-2.6.9-34.EL ipvsadm-1.24-6 heartbeat-1.2.3.cvs.20050927-1.centos4
I note that there's a bug report filed related to CentOS 4.2:
http://bugs.centos.org/view.php?id=1201&nbn=7
I was just wondering, would you like a bug report filed for this?
Will.
There are lots of spinlock issues fixed with a kernel that is in our testing repo ...
THIS IS A TESTING KERNEL !!!!
:)
You can get it like this:
place the testing repo file in /etc/yum.repos.d/ ... the repo file is here:
http://dev.centos.org/centos/4/CentOS-Testing.repo
Then you can get the testing kernel (or kernel-smp, kernel-hugemem. etc) with the command:
yum --enable-repo=c4-testing install kernel
(or kernel-smp, kernel-hugemem, etc.)
(did I mention this was a testing kernel ... :)
On 28/04/06, Johnny Hughes mailing-lists@hughesjr.com wrote:
On Fri, 2006-04-28 at 16:41 +0100, Will McDonald wrote:
Guys,
one of our boxes just died with the following error:
kernel panic - not syncing: fs/block_dev.c:396: spin_lock (fs/block_dev.c:c0361c0) already locked by fs/block_dev.c/287.
There are lots of spinlock issues fixed with a kernel that is in our testing repo ...
THIS IS A TESTING KERNEL !!!!
(did I mention this was a testing kernel ... :)
So, this testing kernel, it'll be fine and if there are any problems I can blame you guys for not telling me, right? :)
I may give that a pop if the problem becomes more frequent but so far I think I've seen spin_lock panics twice in 6 months, so I may bide my time.
Cheers.
Will.
On Fri, 2006-04-28 at 17:04 +0100, Will McDonald wrote:
On 28/04/06, Johnny Hughes mailing-lists@hughesjr.com wrote:
On Fri, 2006-04-28 at 16:41 +0100, Will McDonald wrote:
Guys,
one of our boxes just died with the following error:
kernel panic - not syncing: fs/block_dev.c:396: spin_lock (fs/block_dev.c:c0361c0) already locked by fs/block_dev.c/287.
There are lots of spinlock issues fixed with a kernel that is in our testing repo ...
THIS IS A TESTING KERNEL !!!!
(did I mention this was a testing kernel ... :)
So, this testing kernel, it'll be fine and if there are any problems I can blame you guys for not telling me, right? :)
I may give that a pop if the problem becomes more frequent but so far I think I've seen spin_lock panics twice in 6 months, so I may bide my time.
Cheers.
Will.
:)
Just for the record, I am running the testing kernel on my main workstation (an smp i686 machine) and it has been working fine for me since built on 20 April. It is 2.6.9-34.19.EL and was based on a kernel from here:
On 28/04/06, Johnny Hughes mailing-lists@hughesjr.com wrote:
On Fri, 2006-04-28 at 17:04 +0100, Will McDonald wrote:
On 28/04/06, Johnny Hughes mailing-lists@hughesjr.com wrote:
On Fri, 2006-04-28 at 16:41 +0100, Will McDonald wrote:
Guys,
one of our boxes just died with the following error:
kernel panic - not syncing: fs/block_dev.c:396: spin_lock (fs/block_dev.c:c0361c0) already locked by fs/block_dev.c/287.
There are lots of spinlock issues fixed with a kernel that is in our testing repo ...
I may give that a pop if the problem becomes more frequent but so far I think I've seen spin_lock panics twice in 6 months, so I may bide my time.
Cheers.
Will.
:)
Just for the record, I am running the testing kernel on my main workstation (an smp i686 machine) and it has been working fine for me since built on 20 April.
Bit of an update, that system died again with the same error. I've installed the testing kernel but now the box doesn't boot. It gets as far as:
Mounted /proc Mounting sysfs Creating /dev Starting udev Loading scsi_mod.ko module SCSI subsystem initialized Loading de_mod.ko module Loading aic7xxx.ko module ACPI: PCI interrupt 000:00:0a:0[A]: no GSI - using IRQ 11 scsi0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 <Adaptec 29160 B Ultra160 SCSI adapter> aic 7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs.
Then just hangs there. CTRL-ALT-DEL does properly reset the system, stopping md devices (not that there are any).
I tried booting with pci=noapic to see if that helped, same thing. I've booted back into the old kernel for now. I'll have If it's if any use this system is an IBM eServer 300.
Having a root around through the init nash script out of the initrd...
echo Starting udev /sbin/udevstart echo -n "/sbin/hotplug" > /proc/sys/kernel/hotplug echo "Loading scsi_mod.ko module" insmod /lib/scsi_mod.ko echo "Loading sd_mod.ko module" insmod /lib/sd_mod.ko echo "Loading aic7xxx.ko module" insmod /lib/aic7xxx.ko echo "Loading dm-mod.ko module" insmod /lib/dm-mod.ko
I guess init's not completing "Loading aic7xxx.ko module".
Will.
-
Johnny Hughes -
Will McDonald