Panic in SCSI subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


First of all, a little information on my current system:

  Distro: Fedora Core 3 (fully updated)
  Kernel: 2.6.12-1.1381_FC3 (the bug also occurs on the latest 2.6.14 kernel
          from Fedora Core 4)
  Motherboard: Asus K8V SE Deluxe (Socket 754, VIA K8T800)
  CPU: Sempron 3000+
  Memory: 2 x TwinMOS 256 MB DDR400 (CL2.5)
  PATA disk: Maxtor 6Y160P0
  SATA disks: 4 x 250 GB Seagate Barracuda 7200.8 SATA NCQ
  SATA controller: Promise SATA-II 150 TX4 PCI

The system boots from the PATA disk, which among other things
contains the OS.  The four SATA disks are set up in a software
RAID5 array using mdadm, and this is where I store all my important

Until recently, this file server contained a 650 MHz Pentium III
CPU and an Asus P3B-F motherboard.  This configuration worked

After upgrading the motherboard/CPU/memory on my file server to
the configuration listed on top, I started getting kernel panics
in the SCSI subsystem.  Once it happens, the machine freezes
completely, so I only have the logs that appear on screen.
The following is copied down by hand, so I left out the full
memory adresses preceeding each line in the stack trace:

  ata7: called with no error (51)!
  Kernel panic - not syncing: drivers/scsi/scsi.c:297: spin_is_locked
   on uninitialized spinlock deadc014. (Not tainted)

  scsi_put_command+0x19c/0x2bf [scsi_mod]
  scsi_next_command+0xc/0x14 [scsi_mod]
  scsi_end_request+0xed/0x200 [scsi_mod]
  scsi_io_completion+0x151/0x4d4 [scsi_mod]
  sd_rw_intr+0x156/0x30f [sd_mod]
  scsi_finish_command+0x8e/0xc1 [scsi_mod]
  scsi_softirq+0x9d/0xcd [scsi_mod]

The above log isn't the same every time, but it always includes
SCSI related stuff like scsi_finish_command.  I upgraded around
a month ago, and until yesterday, it only crashed three or four
times.  Now, after the last crash, the time between crashes has
been reduced from about a week to about five minutes -- the system
is completely unusable!  I noticed that every time I boot the
system, the RAID array starts the resyncing process.  It always
crashes before finishing, forcing it to start from scratch on
every boot.  I'm guessing that the stress from the resync operation
is what's causing it to crash within five minutes.  I don't know
what prompted it to start resyncing in the first place, though.
(Btw, how dangerous is a crash in the resync process?  Is there
a high risk of data corruption?)

Until I know more, I have downgraded to my old CPU/motherboard.
It's still resyncing, so I don't know if the problem has gone away,
but it's been up for almost 100 minutes, and I still haven't seen a
single "ataN: called with no error (51)!" that usually preceeds the
kernel panic, so I think it's still working with my old hardware.

One last thing:  The new motherboard actually has four SATA
connectors (two that connects to an onboard Promise TX2 controller,
and two that connects to an onboard VIA controller), so I tried
taking out my Promise TX4 card, and connecting the disks to the
onboard connectors.  This didn't make any difference -- the system
panics in exactly the same way as before.

Any help is greatly appreciated!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux